summaryrefslogtreecommitdiff
path: root/info/digests/uktex/93/uktex.12
diff options
context:
space:
mode:
authorNorbert Preining <norbert@preining.info>2019-09-02 13:46:59 +0900
committerNorbert Preining <norbert@preining.info>2019-09-02 13:46:59 +0900
commite0c6872cf40896c7be36b11dcc744620f10adf1d (patch)
tree60335e10d2f4354b0674ec22d7b53f0f8abee672 /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.121078
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]
+****************************************