diff options
author | Norbert Preining <norbert@preining.info> | 2019-09-02 13:46:59 +0900 |
---|---|---|
committer | Norbert Preining <norbert@preining.info> | 2019-09-02 13:46:59 +0900 |
commit | e0c6872cf40896c7be36b11dcc744620f10adf1d (patch) | |
tree | 60335e10d2f4354b0674ec22d7b53f0f8abee672 /info/digests/uktex/93/uktex.12 |
Initial commit
Diffstat (limited to 'info/digests/uktex/93/uktex.12')
-rw-r--r-- | info/digests/uktex/93/uktex.12 | 1078 |
1 files changed, 1078 insertions, 0 deletions
diff --git a/info/digests/uktex/93/uktex.12 b/info/digests/uktex/93/uktex.12 new file mode 100644 index 0000000000..80959106f1 --- /dev/null +++ b/info/digests/uktex/93/uktex.12 @@ -0,0 +1,1078 @@ +UKTeX Digest Friday, 26 Mar 1993 Volume 93 : Issue 12 + + ``The UKTeX Digest is brought to you as a free, unfunded and voluntary + service of the UK TeX Users Group and the UK TeX Archive.'' + +Today's Topics: + {Q&A}: + Re: Side-by-Side Setting + need help on input to patgen + Metafont question + LaTeX/Minipage/Footnotemark + marginal inserts + RE: How to achieve user control of the DVI filename + RE: C to TeX, anyone? + RE: Side-by-Side Setting : Help Wanted + Ragged right text in LaTeX tabular environment + Re: Ragged right text in LaTeX tabular environment + Fixed record formats + RE: Fixed record formats + {Archive News}: + dviwin version 2.5 in uk tex archive + Archive directory listings on Dad (Uk.Ac.TeX) + {Announcements}: + Re: Side-by-Side Setting (No. 10 and 11) + + +Administrivia: + Moderators: Peter Abbott (Aston University) and + David Osborne (University of Nottingham) + Contributions: UKTeX@uk.ac.tex + Administration, subscription and unsubscription requests: + UKTeX-request@uk.ac.tex + +---------------------------------------------------------------------- + +Date: Mon, 22 Mar 1993 10:32:29 +0000 +From: ccsrar <R.A.Reese@uk.ac.hull.cc> +Subject: Re: Side-by-Side Setting + +Zdenek Wagner writes (Wed, 17 Mar 1993 13:27) +>Subject: Re: Side-by-Side Setting +> +>Side-by-side setting of original text and translation even into more +>languages is quite easy in LaTeX. This problem is solved by "multicolpar.sty". +>The "multicolpar" environment defined in this style takes the number of columns +>as the parameter (it will be the number of languages). + +I recorded last weekend an OU programme about Plantin, who typeset +a bible in five languages (4 columns per double spread with the fifth +as a footnote). As it is relevant, of general interest and pleasantly +watchable, I'll bring the tape to the RHBNC meeting and hope that some +viewing facility can be provided. + +(R.) Allan Reese Janet: r.a.reese@uk.ac.hull +Head of Applications Direct voice: +44 482 465296 +Computer Centre Voice messages: +44 482 465685 +Hull University Fax: +44 482 466441 +Hull HU6 7RX, U.K. + +------------------------------ + +Date: 22 Mar 1993 15:40:51 +0000 +From: spqr@uk.ac.york.minster +Subject: need help on input to patgen + +I am trying to create a rather specialized set of hyphenation +patterns (for ancient Greek names). The files to be typeset use +letters for encoding of accents, so `alpha acute' is a1, `alphatilde' +is a3 and so on; that's all OK, I have a virtual font with appropriate +ligatures which does what is needed. Now I need hyphenation; I got the +authors to hyphenate about 1000 names by hand and I thought I would +feed that to patgen and see what the result was like. However, patgen +will not accept the input with things like A1 and A3 in, and even if +it did, it appears that numbers are used for other purposes in the +final hyphenation patterns. + +But this reveals my ignorance of hyphenation in TeX: if I have a name +like "omero1s" [yes, i know it doesnt have an accent there..], and o1 +is a ligature in the font pointing at, say, character 216, does the +hyphenation happen *after* the ligature substitution, or before? Do I +need char 216 in my original hyphenation set for input to patgen? + +I'd appreciate words of advice from anyone who has followed a similar +route + +sebastian + +------------------------------ + +Date: Mon, 22 Mar 1993 22:11:05 +0100 +From: woerz%de.gueldener@uk.ac.nsfnet-relay +Subject: Metafont question + +I have a question concerning metafont. I want to generate some fonts for +dot-matrix-printer. But I don't know, what resolution for the printer to use. +So I came up with the idea to test some of these resolutions. +So here are my questions: + Am I right that the modes.mf file is dumped into the cmmf file? + How can I get cmmf to read an additional input file, created in a loop, + to generate the fonts I would like to try? + +FYI: We are running Metafont Version 2.71 + +Thanks in advance + +Dieter Woerz + +Zahnaerztliches Rechenzentrum Dr. Gueldener GmbH +Dieter Woerz INTERNET: woerz@gueldener.de +Marienstr. 10 UUCP: unido!zahn!woerz +D-7000 Stuttgart-1 BITNET/EARN: woerz%gueldener.de@unido.bitnet + +------------------------------ + +Date: Tue, 23 Mar 1993 16:03:16 +0000 +From: ccsrar <R.A.Reese@uk.ac.hull.cc> +Subject: LaTeX/Minipage/Footnotemark + +Just as an exercise and for a class demo, I chose an arbitrary table +to set in LaTeX. When I'd started, I realised the column headings +had footnote references. LaTeX (2.09 18 March 1992) handles this +superbly, with a tabular in a table in a minipage. It even changes +the footnote marks automatically from 1,2,3... used in the body +text to a,b,c... in the minipage. Then I noticed some footnote marks +are repeated. \footnotemark looks the job, but if you call +\footnotemark{\value{mpfootnote}} inside the minipage, it outputs +the numeric value, not the letter as the superscript. + +Options seem to be: +1) extract \footnote and \footnote mark and patch in the test for +minipage environment to make a personal copy +2) do the extra footnotemarks as explicit superscripts +3) point out to the class what a lousy way this was of indicating +to the reader where the data came from. + +Allan Reese + +------------------------------ + +Date: Tue, 23 Mar 1993 18:54:29 +0000 +From: Nigel Chapman <N.Chapman@uk.ac.ucl.cs> +Subject: marginal inserts + +Does anyone have macros for inserting notes in the margin of a draft +document? I know that the TeXbook has something of the sort, but (with +all respect to DEK) it's pretty hacky, with mysterious constants wired +into the code. Before I try to untangle this, I wanted to make sure +nobody has done it before. I couldn't find anything in any obvious +place in the archive (unless the changebars stuff generalizes?). I'm a +confirmed plain TeX user, so LaTeX styles aren't a lot of use to me. + +Thanks for any assistance. + +------------------------------ + +Date: Wed, 24 Mar 1993 12:43:00 +0000 +From: Jonathan Fine <J.Fine@pmms.cam.ac.uk> +Subject: RE: How to achieve user control of the DVI filename + +In a posting to TeXhax of Tue, 16 Feb 1993 08:37:48 -0800, +wagman%zephyr.hepnet@LBL.EARN wrote: + +> We create a big book with long articles and a little book with portions of the +> long articles so our TeX file looks something like: +> +> \ifnum\BigBookOrLittleBook = 1 +> This stuff is for the long article and goes into great detail. +> \else +> See our Big Book for details and formulae on this principle. +> \fi +> And this stuff goes in both books. +> +> +> We run TeX twice on the file querying the user for \BigBookOrLittleBook, but +> this results in two DVI files with the same name. Is there some way to +> manually open the DVI file specifying a name? For our needs, they would be +> named: +> \jobname_Big.DVI and \jobname_Little.DVI +> +> Gary S. Wagman +> Lawrence Berkeley Lab +> Berkeley, CA + +It will not help to redefine \jobname, because \jobname is like a +read-only token register. TeX is in rather a subtle state when the +command line is read, and it is then, or rather soon after, that the +name of the DVI file is determined. + +Briefly, here are the rules +1. If TeX believes it needs a value for \jobname, and it hasn't got +one yet, it will use "texput". +2. If TeX hasn't yet assigned a value for \jobname, and the command +|\input xyz| or |\input xyz.anyext| is executed, then the \jobname is +|xyz|. +3. The jobname determines the name of the log file as well as that +of the DVI file. + +Rule 1 is subtle, and I don't know all nuances. However, if +|bigfile.dvi| is created, then there is a file |bigfile.something| +somewhere on the system. It need not be in the current directory - +just in the |\input| search path will do. The trick then is to get +this file |\input| at the right time. You may find \everyjob useful. + +(I'm not sure, but I believe that it will not do to create it on the +fly, by means of an |\immediate\write|, because of rule 1). + +If you are willing to have lots of dummy files about, or if your +operating system supports something like |bigfile.nul| is a null +file, then there is a solution. Otherwise, why not have TeX \write a +small script file, to be run at the end of the job, that will change +the name of the DVI file for you. Or even embed the calling of TeX +in a script? + +I learnt what I know about this, while developing code that would +allow the user to specify command line parameters, like so + C:\MSDOS> tex &plain -iopt1 -iopt2 document +without getting |texput| as the \jobname. + +Jonathan Fine, 203 Coldhams Lane, Cambridge, CB1 3HY + +------------------------------ + +Date: Wed, 24 Mar 1993 12:43:00 +0000 +From: Jonathan Fine <J.Fine@pmms.cam.ac.uk> +Subject: RE: C to TeX, anyone? + +> Date: Fri, 05 Mar 1993 15:04:40 +> From: anoop@parcom.ernet.in (Anoop Sarkar) +> Subject: C to TeX, anyone? +> +> Is there a program available which will allow me to convert C source +> code into a TeX file. There are C beautifiers which format C source +> for troff; but is a C to TeX formatter available in the public domain? + +It is a great shame that such code has not been written, for it would +be very useful. I am writing TeX macros which will convert something +like + This line begins with a letter 'T'. It is a comment + continued + #input <stdio.h> + \int main () + { + + } + and more comment +into something like + This line begins with a letter 'T'. It is a comment + continued + \begin{verb} + #input <stdio.h> + \int main () + { + + } + \end{verb} + and more comment +or even (comments stripped for compilation, but keep the same line +numbers, for error and warning messages from the compiler + + #input <stdio.h> + \int main () + { + + } + +which can then be typeset using the macros of your choice. I don't +suppose this will be ready for release before May. In the meantime, +perhaps you could write a program or script to do this or something +similar using the usual 'C' tools. + +Jonathan Fine, 203 Coldhams Lane, Cambridge, CB1 3HY + +------------------------------ + +Date: Wed, 24 Mar 1993 12:43:00 +0000 +From: Jonathan Fine <J.Fine@uk.ac.cambridge.dpmms> +Subject: RE: Side-by-Side Setting : Help Wanted + +> Date: Thu, 18 Feb 1993 18:22:31 +0000 +> From: Stephen Miller <stephen@uk.ac.oxford.vax> +> Subject: Side-by-Side Setting : Help Wanted +> +> A colleague wants to be able to set folksongs side by side ie the +> original on the left and a translation on the right (his translation +> is line-by-line so the number of lines do match). Can anyone advise +> on the easiest way to do this? + +This is a good question. The problem divides into two parts, input +syntax and typesetting commands. + +Assume that \textA and \textB are macros which expand to give the +text for a single line of the folksong in each language. Then the +command + \def\setline + {% + \line{\hsize0.5\hsize\leftline{\textA}\leftline{\textB}}% + } +will set a line like so + here is the surrounding blurb right mnargin. + Frere Jacque Brother Jack +but if the text exceeds the size allocated one will want to use \vbox +with appropiate \hangindent and so forth. + +To get values for \textA and \textB, why not \read them from text +files. + \newread\fileA \newread\fileB + \def\@getline + {% + \global\read\fileA to \textA + \global\read\fileB to \textB + } + + \def\getline + {% + % test for unmatched end of file + \if \ifeof\fileA A\else B\fi + \ifeof\fileA A\else B\fi + \else + \ddt + \fi + + % read the file + \ifeof\fileA\else\@getline\fi + } + +To use these macros, please first open the input streams \fileA and +\fileB, and then a succession of calls + \getline \setline + \getline \setline + \getline \setline + \getline \setline +will set (in this case) four lines of side by side folk songs. + +These macros are a bit rough, written off the cuff, and unwrapped. + +I hope that these will be useful. + +Jonathan Fine, 203 Coldhams Lane, Cambridge, CB1 3HY + +------------------------------ + +Date: Thu, 25 Mar 1993 13:53:04 +0000 +From: Jack Levy <ccaajrl@uk.ac.ucl> +Subject: Ragged right text in LaTeX tabular environment + + +Try as I can, I can't find a way of setting a table that looks like +the following. The `p' format spec produces text justified both +left and right, which looks pretty naff in a narrow column. +Also, I don't want lots of `underfull hbox' warnings. + ++---------+--------------+--------------+-------------------------+ +| blah | blah blah | rhubarb | I want the text in this | +| | | | column to be ragged | +| | | | right, and because of | +| | | | the narrowness of the | +| | | | column, hyphenation | +| | | | should be off. | ++---------+--------------+--------------+-------------------------+ +| etc | etc | etc | Other blocks of ragged | +| | | | right text. | +| | | | | + +Another question: is there a way of setting a table that spans several +pages, with the column headers being automatically repeated on each page? + +Jack Levy, +UCL Computer Centre, +e-mail: j.levy@ucl.ac.uk + +------------------------------ + +Date: 25 Mar 1993 14:43:54 +0000 +From: spqr@uk.ac.york.minster +Subject: Re: Ragged right text in LaTeX tabular environment + + > Try as I can, I can't find a way of setting a table that looks like + > the following. The `p' format spec produces text justified both + > left and right, which looks pretty naff in a narrow column. + > Also, I don't want lots of `underfull hbox' warnings. + ..... + > Another question: is there a way of setting a table that spans several + > pages, with the column headers being automatically repeated on each page? + +get the complete contents of the current version of `array' +(ftp.tex.ac.uk:pub/archive/macros/latex/styles/base/array), and you'll +see there is discussion of problem 1 in there, and `longtable' will +solve problem 2. so will supertabular, but longtable is more general. + +Sebastian + +------------------------------ + +Date: 23 Mar 1993 15:59:13 -0000 +From: Mike Piff <M.Piff@uk.ac.sheffield> +Subject: Fixed record formats + +Let me get this straight. + +(a) UNIX and DOS know nothing of fixed record format. + +(b) FTP from other sites to TeX preserves the fixed record format of files, + and this is why some of them acquire this characteristic. + +(c) It is difficult/time consuming to convert fixed to variable format. + +(d) Coloured book users in the UK cannot access fixed record/other funny files. + +(e) VAX and IBM3083, etc, cannot use variable record binary files. + +(f) tex and tex.ftp are separate machines. One is a VAX and the other Unix. + + +So, on tex.ftp, being Unix, all files are character streams, but that can +only be accessed by FTP. Any VAXes would not be able to handle its +variable format files. + +This is where I begin to get confused. If tex.ftp can update itself and +convert ALL files to character streams, cannot tex update itself afterwards +from tex.ftp, and thus acquire all its files as character streams, rather +than as fixed record files? +Or is it that the updating of tex cannot be automated? However, if it requires +manual intervention, then there is no need to create these fixed record files +is there? except that VAXes like tex can't work with anything else as +programs? but programs for VAXes must be a very small part of tex. +So why not transfer everything from tex.ftp to tex, and thus un-fix all +those records, apart from the tiddly bits of VAX programs, which will not +be on tex.ftp anyway as anything there is a character stream and thus +unusable on VAXes? + +Then, in a minute little corner of tex, you bung all those VAX binaries, +and to hell with them. THEN I can transfer files to my PC. + +Dr M J Piff e-mail: +Department of Pure Mathematics +University of Sheffield M.Piff@sheffield.ac.uk +Hicks Building PM1MJP@derwent.shef.ac.uk +Hounsfield Road +SHEFFIELD S3 7RH Telephone: SHEFFIELD (0742) 824431 +England + +------------------------------ + +Date: Tue, 23 Mar 1993 17:29:31 +0000 +From: Brian {Hamilton Kelly} <TeX@uk.ac.cranfield.rmcs> +Subject: RE: Fixed record formats + +NON-Disclaimer: This message slags off DEC/UWIST regarding their +Coloured Books Software; it's long overdue that this should be +publicised. I have something like thirty outstanding SPRs relating to +this software, most dating back to 1990 (or even 1989) and DEC seem to +do *nothing* about them. I'd be delighted if all readers of UKTeX (even +or perhaps especially those outside the UK, which is the only country +that has to suffer CBS) would forward a copy of this message to their +DEC account representative --- it would be nice to think that Ken Olsen +or someone of equal venerability might bring pressure to bear :-) + +In message 1586 of 23 Mar 93 15:59:13 BST, +Mike Piff <M.Piff@uk.ac.sheffield> wrote: + +> Let me get this straight. +> +> (a) UNIX and DOS know nothing of fixed record format. + +Well, not quite. Under Unix, every file *is* a pure stream of bytes. +For DOS, however, there is a distinction between text and binary mode +files: in the former, every 0x0A character is preceded by a 0x0D +character. One can sometimes "get away" with files that have been +copied verbatim from Unix; some C compilers, for example, are prepared +to swallow this. But others aren't, and the MS-DOS TYPE command +displays the files' deficiency in spectacular fashion. + +> (b) FTP from other sites to TeX preserves the fixed record format of files, +> and this is why some of them acquire this characteristic. + +No: it's just that when ftp is told to create a binary file on the VAX, +the MultiNet ftp server does it in what it thinks is the most sensible +fashion, namely as fixed 512-byte records. If it wasn't for the heap of +junk provided by DEC (YES I'M SAYING THIS IN PUBLIC; I'M FED UP WAITING +FOR ACTION FROM DEC AFTER OVER THREE YEARS) to implement coloured books +file transfers, there wouldn't be any difficulty with such files, +because the other end of the transfer should be happy to create a simple +byte stream or what-you-will. + +> (c) It is difficult/time consuming to convert fixed to variable format. + +Not difficult, but it *is* time-consuming (extremely:-) + +> (d) Coloured book users in the UK cannot access fixed record/other funny file +s. + +See above. From long and arduous investigation, we found that the only +formats that could reliably be transferred by CBS, to VAXen and +non-VAXen alike, were variable-length records, with or without (for text +and binary respectively) carriage-control. SO although they are +variable-length on TeX.ac.uk, the other end of the NIFTP creates the +file in some appropriate local format. + +> (e) VAX and IBM3083, etc, cannot use variable record binary files. + +Actually, there are some VAX implementations of some TeXware programs +that *are* happy to handle binary files in stream form, or even as +variable-length, no carriage-control. Originally, we stored the VLNOCC +files (for binary) with a maximum record size of 510 bytes, so this was +the predominant flavour of files (there are some binary files that are +truly variable-length; these are completely VAX-specific, usually .OBJ +files). We thought that this would be an efficient representation, +since, with the addition of the 16-bit record length indicator, each +record would occupy exactly one disk block. + +However, this format caused problems for VAX users, because they needed +to convert the files back into fixed 512-byte records (for most +TeXware). Such conversion couldn't be performed by standard VMS +software; most people either wrote the necessary six line C program, or +used Kermit with file type binary at one end, and file type fixed/image +at the other. But some folks couldn't manage this conversion, so we +cast around for another acceptable representation. + +We discovered that the RMS system is very efficient (and much more +intelligent than any Unix filesystem) and that there was no noticeable +overhead in storing the files with records of a maximum length of 512 +bytes, which is how the files are held nowadays. These files can be +transferred quite happily to a non-VAX, creating whatever that machine +finds useful as a "binary" file. In the case of a VAX, the standard +CONVERT utility can readily be used to generate fixed 512-byte records. + +> (f) tex and tex.ftp are separate machines. One is a VAX and the other Unix. + +At last something with which I cannot argue. (Well, that's what I wrote +at first, but now realize that you're using big-endian format names: +ftp.tex.ac.uk, being connected *only* to JIPS, has no equivalent on +Janet, so can't really be referred to as uk.ac.tex.ftp) + +> So, on tex.ftp, being Unix, all files are character streams, but that can +> only be accessed by FTP. Any VAXes would not be able to handle its +> variable format files. + +I'm not sure what you mean here. Remember that for a VAX to be +accessing ftp.tex.ac.uk, it needs some form of ftp program. I believe +I'm right in saying that the ftp client under most (all?) +implementations of TCP/IP under VMS can be instructed to perform binary +file transfers, and the resultant file is fixed-512 --- just what's +wanted. Many can also preserve the original file structure if the ftp +server is also running under VMS; certainly this is true of the MultiNet +and CMUTek implementations. The DEC (UCX) version can also do this, +albeit in an incompatible fashion. + +> This is where I begin to get confused. If tex.ftp can update itself and +> convert ALL files to character streams, cannot tex update itself afterwards +> from tex.ftp, and thus acquire all its files as character streams, rather +> than as fixed record files? + +Yes, it could, and in fact one of the archivists has recently updated +TeX.ac.uk using ftp transfers from ftp.tex.ac.uk --- this is the point +at which yourself (and others) started to notice files that had become +untransferrable. + +It is indeed possible for files to be created under RMS that are simple +streams of bytes. This facility had to be provided by DEC to support +C-programs written in the blas\'e, cavalier fashion that Unix users are +used to using character streams, albeit that it can make the underlying +use of the filesystem extremely inefficient at run-time. Going back +3--4 years or so, many binary files were indeed held in the archive in +that format. + +They could even be transferred, to non-VAXen (I hope everyone +appreciates that *every* file can be transferred to another VAX, if +that's also running CBS, using the /CODE=FAST qualifier, which results +in an exact copy of the file's original structure). So why didn't we +stick to stream format? Simple really: it's down to a deficiency (YES, +DEC, ANOTHER BIG HOLE IN THE SOFTWARE) in the Coloured Books Software. +Like the majority of VMS programs, buffer areas are preallocated to hold +part of the file being transferred; it would have been possible simply +to read a fixed number of bytes from the file into this buffer, but that +would lose detail of the underlying record structure (if any), so CBS +reads all files a record at a time. In the case of Stream_LF files, a +``record'' is everything up to and including the next 0x0A byte in the +stream. Depending upon whether the file's header indicates that it's +with or without carriage-control, then the resultant transfer of that +section of the file will either not include the terminating 0x0A +(saying that it constitutes one ``line'' of the file), or *will* include +that byte in the (binary) stream. + +Unfortunately, some binary files may not have many 0x0A bytes; some have +none at all. But the way CBS was written, RMS is instructed to try to +read everything up-to-and-including the next 0x0A byte into the buffer: +this might be the whole file; certainly, there are many binary files in +which that implies the reading of more than 2048 bytes --- but the +latter is the size of the buffer preallocated by the program, so such +files cannot be transferred. The solution would be for the CBS transfer +to read one record, or 2048 bytes, whichever is the smaller. Niel +Kempson's VVencode adopts this approach, as do the programs of all other +sensible programmers: seemingly DEC/UWIST never thought of such an +eventuality. + +> Or is it that the updating of tex cannot be automated? However, if it require +s +> manual intervention, then there is no need to create these fixed record files +> is there? except that VAXes like tex can't work with anything else as +> programs? but programs for VAXes must be a very small part of tex. + +But it's not just *programs* but all ``binary'' files. Anyway, the +automation is being put in place, so whatever stratagem we adopt has got +to determine file type automatically, and make appropriate actions. + +> So why not transfer everything from tex.ftp to tex, and thus un-fix all +> those records, apart from the tiddly bits of VAX programs, which will not +> be on tex.ftp anyway as anything there is a character stream and thus +> unusable on VAXes? + +Actually, I've found a technique that will permit ftp.tex.ac.uk to store +files, in a simple stream, that can be transferred back to a VAX by ftp +and reconstitute the original VMS/RMS file structure: if we ever lose +the VAX, we'll have to adopt this method. + +> Then, in a minute little corner of tex, you bung all those VAX binaries, +> and to hell with them. THEN I can transfer files to my PC. + +How about using the TeXserver? The /ENCODE qualifier can be used with +the FILES command to have each binary file encoded before transmission. +It will shortly be moving over to using VVcode for this encoding; those +who are already ``converted'' to VVcode, can specify /ENCODE=VV instead +pending this change. + +Brian {Hamilton Kelly} + +JANET: tex@uk.ac.cranfield.rmcs (or System@uk.ac.tex) +BITNET: tex%uk.ac.cranfield.rmcs@ac.uk +INTERNET: tex%uk.ac.cranfield.rmcs@nsfnet-relay.ac.uk +UUCP: {mcsun,uknet,uunet}!rmcs.cranfield.ac.uk!tex +Smail: School of Electrical Engineering & Science, Royal Military + College of Science, Shrivenham, SWINDON SN6 8LA, U.K. +Phone: Swindon (0793) 785252 (UK), +44-793-785252 (International) + +------------------------------ + +Date: 22 Mar 1993 10:03:58 +0000 +From: spqr@uk.ac.york.minster +Subject: dviwin version 2.5 in uk tex archive + +tex.ac.uk:[tex-archive.dviware.dviwin] +ftp.tex.ac.uk:pub/archive/dviware/dviwin/ + + From: sendouk@SCF.USC.EDU + + I just completed a new version of my DVI previewer and printer for MS- + Windows. Here is a brief description of the program: + + DVIWIN 2.5 is a screen and printer driver for TeX DVI files under Windows + 3.1. Its main features are: + + * Fast previewing (uses 386-specific code if it finds a 386/486) + * Painless support for graphics in TeX documents + * Uses any standard PK font files or FLI font libraries + * Can use many paper sizes including the metric standard sizes + * Works with virtually all displays and printers supported by Windows + * Automatically detects changes in the dvi file and reloads it quickly + by avoiding to reread fonts unnecessarily + + New features include support for FLI files, custom resolutions, a font + cache, automatic refresh of dvi files, reduction in memory requirements, + a workaround to avoid common bugs in video drivers (which was NOT a bug + in dviwin 2.0), a magnifying glass, etc. The required memory depends on + the resolution that you use. It needs about 1.5M free RAM to print on a + 300dpi printer without swapping. + + The program is completely free for any individual or non-commercial + organization. Please contact me for any comments, suggestions, bug + reports, etc. + + .... + I hope that you find it useful, + + Hippocrates Sendoukas (sendouk@scf.usc.edu)\ +------------------------------ + +Date: Thu, 25 Mar 1993 22:35:02 +0000 +From: Niel Kempson <kempson@uk.ac.tex> +Subject: Archive directory listings on Dad (Uk.Ac.TeX) + +Following requests from archive users, I am about to change the format of +the listing files generated every night on the Dad archive (UK.AC.TEX). +The files currently genereated are: + +In the top level [TEX-ARCHIVE] directory: + + 00DIRECTORY.LIST listing of all files in VMS directory format + 00DIRECTORY.SIZE as above, plus date and size of each file + 00LAST7DAYS.FILES listing of all files added to the archive in the + last 30 days; most recent file listed first + 00LAST30DAYS.FILES listing of all files added to the archive in the + last 7 days; most recent file listed first + +In every sub-directory: + + 00FILES.TXT listing of all files in the subdirectory + + +The 00DIRECTORY.* files in the [TEX-ARCHIVE] directory will be abandoned +and replaced with a single 00INDEX.FILES listing. There is now a +common format for all of the 00* listing files in the archive. Here's an +extract from 00INDEX.FILES: + +> Files matching DISK$TEX:[TEX-ARCHIVE...]*.* +> (listing updated: 4-Mar-93 09:03). +> +> Last change Size Type File specification +> ----------------------------------------------------------------------------- +> 21-Sep-90 16:37 1606 txt [tex-archive]00aston.readme +> 28-Oct-92 16:13 1496 txt [tex-archive]00contributions.txt +> 4-Mar-93 01:30 664000 txt [tex-archive]00directory.list +> 4-Mar-93 01:35 1807748 txt [tex-archive]00directory.size +> 3-Mar-93 03:09 4036 txt [tex-archive]00files.txt +> 3-Mar-93 02:35 300450 txt [tex-archive]00last30days.files +> 3-Mar-93 02:36 32768 bin [tex-archive]00last30days.files_zip +>... +> ----------------------------------------------------------------------------- + + +All of the 00* files will be in this common format. The 00LAST* files in +the [TEX-ARCHIVE] directory and the 00FILES.TXT files in each +subdirectory are very much as they always have been, except that there is +no longer a "disk$tex:" before the "[tex-archive" component of the file +specification. + +In addition, each of the files in the [TEX-ARCHIVE] directory will be +available in ZIP format. You will need Info-unZIP or PKUNZIP v2.x to +unpack the file (PKZIP v1.1 will *not* work). The ZIP versions are +only 10-15% of the original size - a useful compression ratio :-) + +So to recap, the following listing files will be generated every night on +TEX.AC.UK: + +In the top level [TEX-ARCHIVE] directory: + + 00INDEX.FILES listing of all files in the archive + 00LAST7DAYS.FILES listing of all files ad ed to the archive in the + last 30 days; most recent file listed first + 00LAST30DAYS.FILES listing of all files added to the archive in the + last 7 days; most recent file listed first + + 00INDEX.FILES_ZIP + 00LAST7DAYS.FILES_ZIP + 00LAST30DAYS.FILES_ZIP Info-ZIP compressed versions of the above + files + +In every sub-directory: + + 00FILES.TXT listing of all files in the subdirectory + + +The changes will be implemented over the weekend of 3-4 April 1993. + +Niel Kempson +Aston TeX Archive Group + +Dr C Niel Kempson +25 Whitethorn Drive, Cheltenham GL52 5LL, England +Telephone: 0242-579105 (UK), +44-242-579105 (International) +E-mail: kempson@tex.ac.uk (Internet) + +------------------------------ + +Date: Tue, 23 Mar 1993 10:26:18 -0500 +From: Peter Schmitt + <A8131DAL%at.ac.univie.edvz.awiuni11@uk.ac.earn-relay> +Subject: Re: Side-by-Side Setting (No. 10 and 11) + +Some time ago I wrote the following macros which might help: + +%% macro for plain TeX for 3 parallel columns: it allows *one* page break +%% occurring in the 3columnmode: each of the columns is broken seperately +%% usage can be deduced from the example below +%% for 2 columns: set the width of the middle column to zero +%% It has not yet been tested thoroughly! +%% +%% Peter Schmitt a8131dal@awiuni11.bitnet, schmitt@awirap.bitnet +%% +\newbox\partialpage +\newbox\leftcolumn \newbox\leftrest +\newbox\middlecolumn \newbox\middlerest +\newbox\rightcolumn \newbox\rightrest +\newdimen\pagerest \newif\ifpagefull +\def\columns#1-#2-#3 {\def\hleft{#1}\def\hmiddle{#2}\def\hright{#3}} +\def\beginthreecolumns{ + \begingroup\topskip10ptplus10pt\global\pagefullfalse + \output={\global\setbox\partialpage=\vbox{\unvbox255\bigskip} + \splitmaxdepth=\maxdepth + \global\pagerest=\vsize + \global\advance\pagerest by-\ht\partialpage}} +\def\left{\vfil\eject\hsize=\hleft\advance\vsize by\pagerest + \output={\global\setbox\leftcolumn=\vsplit255 to\pagerest + \ifvoid255\else\global\pagefulltrue + \global\setbox\leftrest=\vbox{\unvbox255\vfil}\fi}} +\def\middle{\vfil\eject\hsize=\hmiddle + \output={\global\setbox\middlecolumn=\vsplit255 to \pagerest + \ifvoid255\else\global\pagefulltrue + \global\setbox\middlerest=\vbox{\unvbox255\vfil}\fi}} +\def\right{\vfil\eject\hsize=\hright + \output={\global\setbox\rightcolumn=\vsplit255 to \pagerest + \ifvoid255\else\global\pagefulltrue + \global\setbox\rightrest=\vbox{\unvbox255\vfil}\fi}} +\def\endthreecolumns{\vfil\eject\endgroup + \vbox{\unvbox\partialpage + \line{\vtop{\unvbox\leftcolumn}\hfill + \vtop{\unvbox\middlecolumn}\hfill + \vtop{\unvbox\rightcolumn}}} + \ifpagefull\vfil\eject + \line{\ifvoid\leftrest\hskip\hleft\else\vtop{\unvbox\leftrest\vfil}\fi + \hfill + \ifvoid\middlerest\hskip\hmiddle\else\vtop{\unvbox\middlerest\vfil}\fi + \hfill + \ifvoid\rightrest\hskip\hright\else\vtop{\unvbox\rightrest\vfil}\fi} + \fi\bigskip} + +%%% Example for usage: + +\vsize7cm\overfullrule0pt\parindent0pt +\hsize15cm + +Beginn: Text zu Beginn + +\columns4cm-4cm-4.5cm +\beginthreecolumns +\left Links: Das ist nur ein kleiner Text zur Probe. + Ein zweiter Satz. + +Und gar ein Absatz! +Das ist nur ein kleiner Text zur Probe. + Ein zweiter Satz. + +Und gar ein Absatz! +Das ist nur ein kleiner Text zur Probe. + Ein zweiter Satz. + +Und gar ein Absatz! +Das ist nur ein kleiner Text zur Probe. + Ein zweiter Satz. + +Und gar ein Absatz! +Das ist nur ein kleiner Text zur Probe. + Ein zweiter Satz. + +Und gar ein Absatz! + +\middle Mitte: Das ist ein kleiner Text zur Probe. +Das ist nur ein kleiner Text zur Probe. + Ein zweiter Satz. + +Und gar ein Absatz! +cDas ist nur ein kleiner Text zur Probe. + Ein zweiter Satz. + +Und gar ein Absatz! +Das ist nur ein kleiner Text zur Probe. + Ein zweiter Satz. + +Und gar ein Absatz! +Das ist nur ein kleiner Text zur Probe. + Ein zweiter Satz. + +Und gar ein Absatz! +Das ist nur ein kleiner Text zur Probe. + Ein zweiter Satz. + +Und gar ein Absatz! +\right Rechts: Das ist ein kleiner Text zur Probe. +Das ist nur ein kleiner Text zur Probe. + Ein zweiter Satz. + +Und gar ein Absatz! +cDas ist nur ein kleiner Text zur Probe. + Ein zweiter Satz. + +Und gar ein Absatz! +Das ist nur ein kleiner Text zur Probe. + Ein zweiter Satz. + +Und gar ein Absatz! +\endthreecolumns + +Ende: Anschliessender Text + +Beginn: Text zu Beginn + +\columns5cm-4cm-3.5cm +\beginthreecolumns +\left Links: Das ist nur ein kleiner Text zur Probe. + Ein zweiter Satz. + +Und gar ein Absatz! +Das ist nur ein kleiner Text zur Probe. + Ein zweiter Satz. + +Und gar ein Absatz! +Das ist nur ein kleiner Text zur Probe. + Ein zweiter Satz. + +Und gar ein Absatz! +Das ist nur ein kleiner Text zur Probe. + Ein zweiter Satz. + +Und gar ein Absatz! +Das ist nur ein kleiner Text zur Probe. + Ein zweiter Satz. + +Und gar ein Absatz! + +\middle Mitte: Das ist ein kleiner Text zur Probe. +Das ist nur ein kleiner Text zur Probe. + Ein zweiter Satz. + +Und gar ein Absatz! +cDas ist nur ein kleiner Text zur Probe. + Ein zweiter Satz. + +Und gar ein Absatz! +Das ist nur ein kleiner Text zur Probe. + Ein zweiter Satz. + +Und gar ein Absatz! +Das ist nur ein kleiner Text zur Probe. + Ein zweiter Satz. + +Und gar ein Absatz! +Das ist nur ein kleiner Text zur Probe. + Ein zweiter Satz. + +Und gar ein Absatz! +\right Rechts: Das ist ein kleiner Text zur Probe. +Das ist nur ein kleiner Text zur Probe. + Ein zweiter Satz. + +Und gar ein Absatz! +cDas ist nur ein kleiner Text zur Probe. + Ein zweiter Satz. + +Und gar ein Absatz! +Das ist nur ein kleiner Text zur Probe. + Ein zweiter Satz. + +Und gar ein Absatz! +\endthreecolumns + +Ende: Anschliessender Text + +\end + +Peter Schmitt a8131dal@awiuni11.edvz.univie.ac.at + schmitt@awirap.bitnet +Institute of Mathematics Strudlhofgasse 4 +University of Vienna A-1090 Wien + Austria + +------------------------------ + + UK TeX ARCHIVE at ASTON UNIVERSITY + >>> UK.AC.TEX <<< + + *** Interactive and file transfer access *** + JANET: + uk.ac.tex (DTE 000020120091) + Username: public, Password: public + Internet: + tex.ac.uk [134.151.40.18] -- telnet/rlogin, anonymous ftp + ftp.tex.ac.uk [134.151.44.19] -- anonymous ftp, gopher + For telnet access, login: public, password: public + For anonymous ftp, login: anonymous, password: <your-e-mail-address> + + *** Mail server *** + Send mail to TeXserver@uk.ac.tex (JANET) + or TeXserver@tex.ac.uk (rest of the world) + with message body containing the word HELP + +\section FILES OF INTEREST + + [tex-archive]00readme.txt + [tex-archive]00directory.list [tex-archive]00directory.size + [tex-archive]00directory_dates.list [tex-archive]00last30days.files + [tex-archive.doc]TeX-FAQ.txt (Frequently Asked Questions list) + [tex-archive.doc]FAQ-Supplement-*.txt (FAQ supplement) + +\section DIGESTS + + This year's UKTeX back issues are stored in the archive in directory + [tex-archive.digests.uktex.93] + This year's TeXhax back issues are stored in the archive in directory + [tex-archive.digests.texhax.93] + Latest TeXhax: V93 #05 + +\section MEDIA DISTRIBUTIONS + Postal addresses are given below. + +\subsection Washington Unix TeX distribution tape + Latest copy of May/June 1991 contains: + TeX 3.14, LaTeX 2.09, Metafont 2.7, plus many utilities + suitable for Unix 4.2/4.3BSD & System V + tar format, 1600bpi, blockfactor 20, 1 file (36Mb) + + Copies available on: + One 2400ft 0.5" tape sent to Aston with return labels AND return postage + OR + One Quarter-Inch Cartridge, QIC-120 or QIC-150 format (DC600A or DC6150) + sent with envelope AND stamps for return postage to Nottingham + (Due to currency exchange, this service is offered only within the UK) + +\subsection VMS tapes + VMS backup of the archive requires three 2400ft tapes at 6250bpi. + VMS backup of TeX 2.991 plus PSprint requires one 2400ft tape. + +\subsection Exabyte 8mm tapes + Same contents available as 0.5" tapes. + Following tape types available: SONY Video 8 cassette P5 90MP, + MAXELL Video 8 cassette P5-90, TDK Video 8 cassette P5-90MPB + +\section TeX IMPLEMENTATIONS FOR SMALL COMPUTERS + +\subsection OzTeX V1.4 (for Macintosh) + Send 7 UNFORMATTED 800K disks to Aston with return postage. + +\subsection emTeX (for OS/2, PC-DOS and MS-DOS) + The complete package (3.5" High density disk format ONLY) + is available from Aston at a cost of 15 pounds sterling, + including documentation, disks, post and packing (DO NOT SEND DISKS): + specify Set A. + Additional utilities including DVIPS, 5 pounds sterling: specify Set B. + FLI files for FX, 5 pounds sterling: specify Set C. + FLI files for P6M, 5 pounds sterling: specify Set D. + + For general enquiries, and a free catalogue detailing other disk + formats, precompiled fonts and lots of other goodies, contact: + Eigen PD Software, P.O. Box 722, Swindon SN2 6YB (tel: 0793-611270) + (JANET e-mail address: kellett@uk.ac.cran.rmcs) + +\subsection TeX for the Atari ST + All enquiries for disks etc. should be directed to: + The South West Software Library, P.O. Box 562, Wimborne, Dorset BH21 2YD + (JANET e-mail address: mdryden@uk.co.compulink.cix) + +\section POSTAGE RATES + All prices in Pounds Sterling. + For Aston orders, make cheques payable to Aston University. + + 0.5" tapes: UK: 2.50 (one tape), 5.00 (two tapes). + Europe: 5.00 (one tape), 9.00 (two tapes). + Outside Europe please enquire. + 8mm tapes: + UK: 1.00, Europe: 2.00. + Quarter-inch cartridges: + UK: 1.00, Europe: 2.00. + Diskettes: + Quantity/Size Europe World UK 1st UK 2nd + 18/3.5" 3.10 5.10 1.40 1.10 + 11/3.5" 1.80 2.90 0.80 0.65 + 18/5.25" 1.20 2.00 0.60 0.50 + 11/5.25" 0.80 1.30 0.50 0.35 + +\section POSTAL ADDRESSES + Please include SELF-ADDRESSED ADHESIVE LABELS for return postage. + + Peter Abbott + Information Systems, Aston University, Aston Triangle, Birmingham B4 7ET + + David Osborne + Cripps Computing Centre, University of Nottingham, Nottingham NG7 2RD + (for Quarter-inch cartridges ONLY -- must include stamps for return postage) + +\section UK TeX USERS GROUP + Details available + By E-mail: UKTuG-Enquiries@uk.ac.tex + Post or phone: + David Penfold, Edgerton Publishing Services, + 30 Edgerton Road, Edgerton, Huddersfield HD3 3AD (Tel: 0484 519462) + Fax: E McNeil-Sinclair 0272 236169 +\bye + +End of UKTeX Digest [Volume 93 Issue 12] +**************************************** |