UKTeX Digest Friday, 7 Dec 1990
Volume 90 : Issue 43
Today's Topics:
Thesis Regulations
Inputting (postscript) diagrams into LaTeX documents
Epson LQ500, and other things
TeX archive at ymir.claremont.edu?
TeX for Archimedes?
RE: TeX Info wanted
Reasons for having a new 7-bit encoding scheme
TEX for Atari ST
Moderator: Peter Abbott (Aston University)
Editor: David Osborne (University of Nottingham)
Contributions: UKTeX@uk.ac.aston
Administration, subscription and unsubscription requests:
UKTeX-request@uk.ac.aston
UKTeX back issues: stored in the Aston archive, in the directory
DISK$TEX:[TEX-ARCHIVE.DIGESTS.UKTEX.90]
TeXhax back issues:stored in the Aston archive, in the directory
DISK$TEX:[TEX-ARCHIVE.DIGESTS.TEXHAX.90]
Latest TeXhax: #73
TeXMaG back issues: stored in the Aston archive, in the directory
DISK$TEX:[TEX-ARCHIVE.DIGESTS.TEX-MAG]
Latest TeXMaG: V4 N6
------------------------------------------------------------
Date: Mon, 03 Dec 90 10:11:00 +0000
From: A055@UK.AC.EAST-ANGLIA.CPC865
Subject: Thesis Regulations
Several theses have been accepted at UEA, using a modified xxxthesis.sty
(from the distribution tape, but with UEA instead of MIT or whatever).
At least some polytechnics (CNAA) also accept similarly prepared theses.
Dan Smith
------------------------------
Date: Mon, 03 Dec 90 14:05:17 +0000
From: MIKE@UK.AC.SHEFFIELD.AIVRU
Subject: Inputting (postscript) diagrams into LaTeX documents
Can anybody out there help me ?
This is probably an often asked question, but is there anyway
of inputting (postscript) diagrams into LaTeX (on a SUN) ? We have
a variety of graphical tools (FIG, sundraw, framemaker etc.)
but there does not seem to be a way of including these
into a latex document. I guess such a fix would involve
having dvitps read in the diagram postscript files but I can't
see how to pass this information through from LaTeX.
Many thanks in advance,
Michael Rygol
------------------------------
Date: Mon, 03 Dec 90 15:36:00 +0000
From: S121@UK.AC.EAST-ANGLIA.CPC865
Subject: Epson LQ500, and other things
I saw the query about printing on Epson LQ500 printers, which prompted
a couple of things -
1) the problme COULD be something to do with the 'skip over perforations'
setting on the printer - it confuses MS Word on my PC. Its one of the
DIP switches at the side. Just a guess though.
2) What driver are you using, and is it at Aston? If so could you tell
me where? And what is the quality like?
On another track completely - is there any recommended way to actually
find things in the archive? The reason I ask, is that I am trying to find
a dvi -> postscript driver, which will run on a PC. Now I got
[tex-archive.drivers]00files.txt
which lead me to
[ " . " .dvi2ps]00files.txt
However I am then prsented with a choice of 9 directories, which I presume
all contain diferent peoples implementations of a driver. But how can I
then tell which I want?
Unless I mail Uktex and ask, I cannot find any way to decide which files
I should start transfering, and since file transfer is slow, I dont
particularly want to try to get everything.
And if everyone mailed UkTeX to ask this type of question, not only would
the Digest become an archive question board, but no doubt the same
questions would come up with depressing frequency.
I realise the ideal is to have lots of lovely help/readme files
but equally realise that the Archivists do not have the time to put
a help file in every directory.
Any thoughts from anyone else on this?
Yours
Ian Ellery
------------------------------
Date: Tue, 04 Dec 90 12:33:47 +0000
From: MD2RJH@UK.AC.SHEFFIELD.IBM
Subject: TeX archive at ymir.claremont.edu?
Does anyone know much about the ymir archive at claremont.edu? There are some
TeX files there I should like to download, I can obtain the text files easily
using the mailer, but I can't get the binary files. There does not appear to
be any way of instructing the mailer to encode the files before sending and I
don't know any contact I can ask at ymir. Any ideas?
Yours Richard Hillier
R.Hillier@UK.AC.SHEF.IBM
------------------------------
Date: Tue, 04 Dec 90 16:54:09 +0000
From: SUQSUMNR@UK.AC.READING.CC.AM.CMS
Subject: TeX for Archimedes?
I had an enquiry for TeX to run on an Archimedes. The caller thought
it is maybe available from Nijmegen but was not sure. Does anyone
know anything about it?
Tony Sumner
A.Sumner@uk.ac.reading
------------------------------
Date: Tue, 04 Dec 90 19:47:59 +0000
From: TEX@UK.AC.CRANFIELD.RMCS
Subject: RE: TeX Info wanted
In a message (110) to UKTeX of Fri, 30 NOV 90 13:15:24 GMT,
VIRANTHA1@UK.AC.MIDDLESEX.VAXA wrote:
> Could u please send me some info on how to get the TeX sources
> to implement on VAX/VMS? I am interseted in Tex 3.0, Metafont 2.0
> and related programs.
>
> Thanx for your time,
>
> virantha
>
>
> -----------------------------------------------------------------------------
> JANET :v.mendis@uk.ac.mx.cluster snail mail :
> INTERNET :v.mendis%cluster.mx.ac.uk@cunyvm.cuny.edu Middlesex Polytechnic
> EARN/BITNET:v.mendis%cluster.mx.ac.uk@ukacrl Bounds Green Road
> UUCP :v.mendis%cluster.mx.ac.uk@ukc.uucp London N11 2NQ
> T.Phone +01 081 368 1299 United Kingdom.
> -----------------------------------------------------------------------------
Since this is a recurrent enquiry, I thought it might be useful to
publish your enquiry and my reply in UKTeX.
The UK TeX Archive at Aston contains the canonical sources for TeX 3.1
and MF V2.7, along with VMS-specific change files and other files
required to get a working implementation under VMS.
Furthermore, the binary .OBJ files are also stored in the archive; these
are only suitable for sites that are able to do a Coloured Book
TRANSFER/CODE=FAST directly between VAXen.
Files may be found as follows:
BINARY FILES:
~~~~~~~~~~~~~
Last change Size Type File specification
- -----------------------------------------------------------------------------
4-Dec-90 17:46 2590 TXT [tex-archive.binary.vms]00readme.txt
4-Dec-90 17:38 634 TXT [tex-archive.binary.vms]glib_index.dat
4-Dec-90 17:29 102 TXT [tex-archive.binary.vms]grlib-options.opt
4-Dec-90 13:09 16548 BIN [tex-archive.binary.vms]pktype.obj
4-Dec-90 13:08 29418 BIN [tex-archive.binary.vms]gftype.obj
4-Dec-90 13:06 29098 BIN [tex-archive.binary.vms]gftopxl.obj
4-Dec-90 12:48 116736 BIN [tex-archive.binary.vms]cmplain.base
4-Dec-90 12:48 914 TXT [tex-archive.binary.vms]cmplain.inimf_lis
4-Dec-90 12:47 69632 BIN [tex-archive.binary.vms]plain.base
4-Dec-90 12:47 812 TXT [tex-archive.binary.vms]plain.inimf_lis
4-Dec-90 12:21 299290 BIN [tex-archive.binary.vms]mf.obj
4-Dec-90 11:39 23926 TXT [tex-archive.binary.vms]mf.pool
3-Dec-90 20:03 6848 BIN [tex-archive.binary.vms]vis550.obj
3-Dec-90 20:03 6290 BIN [tex-archive.binary.vms]go140.obj
3-Dec-90 19:55 20148 BIN [tex-archive.binary.vms]gftopk.obj
3-Dec-90 19:54 42280 BIN [tex-archive.binary.vms]gftodvi.obj
3-Dec-90 19:40 562334 BIN [tex-archive.binary.vms]trap_inimf.obj
3-Dec-90 19:36 726 BIN [tex-archive.binary.vms]mf-extra.obj
3-Dec-90 18:31 386560 BIN [tex-archive.binary.vms]splain.fmt
3-Dec-90 18:28 9728 TXT [tex-archive.binary.vms]splain.initex_lis
3-Dec-90 18:28 366080 BIN [tex-archive.binary.vms]mzlplain.fmt
3-Dec-90 18:26 9568 TXT [tex-archive.binary.vms]mzlplain.initex_lis
3-Dec-90 18:14 353280 BIN [tex-archive.binary.vms]lplain.fmt
3-Dec-90 18:13 7640 TXT [tex-archive.binary.vms]lplain.initex_lis
3-Dec-90 17:45 209920 BIN [tex-archive.binary.vms]plain.fmt
3-Dec-90 17:44 2600 TXT [tex-archive.binary.vms]plain.initex_lis
3-Dec-90 16:57 7472 BIN [tex-archive.binary.vms]pooltype.obj
3-Dec-90 16:47 54438 BIN [tex-archive.binary.vms]tftopl.obj
3-Dec-90 16:44 60684 BIN [tex-archive.binary.vms]pltotf.obj
3-Dec-90 15:38 57430 BIN [tex-archive.binary.vms]dvitype.obj
3-Dec-90 15:32 88126 BIN [tex-archive.binary.vms]weave.obj
3-Dec-90 14:59 420634 BIN [tex-archive.binary.vms]trip_initex.obj
3-Dec-90 12:41 370324 BIN [tex-archive.binary.vms]tex.obj
3-Dec-90 12:39 27768 TXT [tex-archive.binary.vms]tex.pool
3-Dec-90 12:28 51888 BIN [tex-archive.binary.vms]tangle.obj
18-May-90 10:30 7172 BIN [tex-archive.binary.vms]wmerge.obj
17-Aug-89 16:51 16538 BIN [tex-archive.binary.vms]pktopx.obj
17-Aug-89 09:51 187158 BIN [tex-archive.binary.vms]bibtex.obj
23-Mar-88 16:59 13816 BIN [tex-archive.binary.vms]pxtopk.obj
- -----------------------------------------------------------------------------
CANONICAL SOURCES for TeX V3.1
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Last change Size File specification
- -----------------------------------------------------------------------------
24-Sep-90 12:29 1061056 [tex-archive.tex.v3]tex.web
24-Sep-90 12:16 10378 [tex-archive.tex.v3]webmac.tex
24-Sep-90 12:15 45562 [tex-archive.tex.v3]plain.tex
20-Apr-90 11:38 9504 [tex-archive.tex.v3]testfont.tex
16-Nov-89 18:30 2712 [tex-archive.tex.v3]tex.v3_readme
8-Jun-89 22:47 34492 [tex-archive.tex.v3]hyphen.tex
- -----------------------------------------------------------------------------
Change and other files for TeX V3.1 under VMS
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(Use either the files with `$' or `_' in the file names, depending upon
whether your site uses local logical names that contain `$' or not: DEC
recommend that sites should *not* use locally generated logical names
containing dollar signs. There are variants provided for DESCRIP.MMS
and TEX.CLD files, which are the names to which you should RENAME
whichever file you decide to collect. DO NOT USE any old .CLD or .MMS
files from the 1989 distribution. Neither should you attempt to use the
old bigTeX variant change files; these are no longer required, since the
latest version is automatically big.)
Last change Size File specification
- -----------------------------------------------------------------------------
4-Dec-90 19:21 13942 [tex-archive.tex.v3.vms]00readme.txt
4-Dec-90 19:21 6434 [tex-archive.tex.v3.vms]vms_tex_notes.txt
3-Dec-90 12:34 51256 [tex-archive.tex.v3.vms]tangle.pas_bootstrap
28-Sep-90 18:07 170436 [tex-archive.tex.v3.vms]tex.ch
26-Sep-90 18:02 17388 [tex-archive.tex.v3.vms]tex.cld_
26-Sep-90 18:01 17388 [tex-archive.tex.v3.vms]tex.cld$
26-Sep-90 18:00 31138 [tex-archive.tex.v3.vms]descrip.mms_tex
26-Sep-90 17:58 31138 [tex-archive.tex.v3.vms]descrip.mms$tex
25-Sep-90 17:38 4212 [tex-archive.tex.v3.vms]tex-trip.ch
3-Sep-90 10:48 114 [tex-archive.tex.v3.vms]compile_tex.com
1-Mar-90 18:01 3298 [tex-archive.tex.v3.vms]wmerge.mms
6-Oct-89 15:47 11724 [tex-archive.tex.v3.vms]wmerge.c
6-Oct-89 15:47 1376 [tex-archive.tex.v3.vms]webmerge.com
- -----------------------------------------------------------------------------
CANONICAL SOURCES for MF V2.7
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Last change Size Type File specification
- -----------------------------------------------------------------------------
24-Sep-90 14:03 950124 [tex-archive.metafont.mfdir.v2]mf.web
20-Apr-90 11:36 23238 [tex-archive.metafont.mfdir.v2]plain.mf
- -----------------------------------------------------------------------------
Change and other files to generate working MF V2.7 under VMS
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(See note above regarding `$' and `_' variants.)
Last change Size File specification
- -----------------------------------------------------------------------------
4-Dec-90 18:13 658 [tex-archive.metafont.mfdir.v2.vms]00readme.txt
4-Dec-90 18:13 9148 [tex-archive.metafont.mfdir.v2.vms]vms_mf_notes.tx
t
4-Dec-90 17:57 27552 [tex-archive.metafont.mfdir.v2.vms]descrip.mms$mf
4-Dec-90 17:56 27552 [tex-archive.metafont.mfdir.v2.vms]descrip.mms_mf
8-Oct-90 19:41 178818 [tex-archive.metafont.mfdir.v2.vms]mf.ch
28-Sep-90 18:20 23086 [tex-archive.metafont.mfdir.v2.vms]local.mf
28-Sep-90 18:14 24794 [tex-archive.metafont.mfdir.v2.vms]vis550.web
28-Sep-90 18:14 0 [tex-archive.metafont.mfdir.v2.vms]vis550.ch
26-Sep-90 18:01 10752 [tex-archive.metafont.mfdir.v2.vms]mf.cld_
26-Sep-90 18:01 10752 [tex-archive.metafont.mfdir.v2.vms]mf.cld$
25-Sep-90 17:27 6334 [tex-archive.metafont.mfdir.v2.vms]mf-trap.ch
3-Sep-90 10:52 7850 [tex-archive.metafont.mfdir.v2.vms]mf-extra.mar
3-Sep-90 10:52 54 [tex-archive.metafont.mfdir.v2.vms]makelib.com
3-Sep-90 10:52 102 [tex-archive.metafont.mfdir.v2.vms]grlib.opt
3-Sep-90 10:50 17516 [tex-archive.metafont.mfdir.v2.vms]go140.web
3-Sep-90 10:50 0 [tex-archive.metafont.mfdir.v2.vms]go140.ch
3-Sep-90 10:50 530 [tex-archive.metafont.mfdir.v2.vms]glib_index.dat
3-Sep-90 10:49 158 [tex-archive.metafont.mfdir.v2.vms]compile_mf.com
- -----------------------------------------------------------------------------
To collect any of these files, apart from the binary ones, you could
edit this message into a request for the TeXserver: select those lines
containing the files required and remove the date and size from each
line (thus making each line start with the `[' character).
Place the TeXserver command FILES before all these lines, and send the
resulting message to <TeXserver@Uk.Ac.ASton.TeX>. We don't recommend
that these files be coalesced into a DCL archive, because the resulting
monolithic file can cause the TeXserver to exceed its disk quota during
processing of your request!
You can collect any of these files, including the binary ones, by
specifying each file name in a separate DEC CBS V5.2 TRANSFER command;
specify /CODE=FAST so as to regenerate the file on your VAX in the same
form as in the Archive.
In addition, you may be interested in the contents of the directories
[tex-archive.web.new{.vms}], [tex-archive.tools.new.dviware{.vms}],
[tex-archive.tools.texware.new{.vms}] and
[tex-archive.tools.fontware.new{.vms}]. Each of these eight directories
contains a file 00files.txt which lists each directory's contents.
Please contact ME if you experience any difficulty in fetching the
files, or in bringing up an executable version on your VAX.
Brian {Hamilton Kelly}
------------------------------
Date: Wed, 05 Dec 90 13:14:27 +0000
From: TEX@UK.AC.CRANFIELD.RMCS
Subject: Reasons for having a new 7-bit encoding scheme
A week or two ago, Dominic Wujastyk entered a plea against re-inventing
wheels because he'd heard rumours about a new encoding scheme, which is
shortly to enter service as the default encoding method at the UK TeX
Archive at Aston University.
Since then, Graham Toal and Pierre MacKay have supported Dominic, so I
think the time has come to publish my reply to Graham and hopefully
convince everybody as to why present encoding schemes are inadequate for
use at archives such as Aston's, where files are collected by users who
have many different architectures and operating systems --- you will see
from the end of the message that I've managed to convince Dominic!
You'll also see, from the attached specification, that it meets Pierre
MacKay's requirements for an encoding scheme.
************************************
I appreciate your concerns about inventing yet another file encoding
scheme (I nearly called the program YAFES).
One of the major problems that we've had at Aston is incompatibility of
binary files (e.g. PK) between stream file systems (as on Unix, DOS) and
record oriented file systems (e.g. VMS, VM/CMS, MVS). I have tried to
find a coding scheme that meets our needs, not just those of the
Unix/MS-DOS community, but without success.
> I throw my rather substantial weight and less substantial influence
> behind Dominik :-) ... to introduce a new 7-bit encoding format would
> be shooting ourselves in the foot. I have exchanged binary files with
> many sites abroad - often through bitnet - and the standard 'xxencode'
> works beautifully (not the misnamed new program which was called
> xxencode for a short time I might add).
Have you exchanged binary files with computers that use record oriented
file systems? Is the "misnamed new program" Nelson Beebe's version of
XXcode?
> Phil Taylor explained to me why a new program is wanted - it is
> because a 7-bit encoded binary file cannot be properly reconstituded
> on VMS without some extra information. Well, I can think of two
> solutions:
>
> 1) Add *extra* vms information *BEFORE* a normal kosher xxencode
> file (or after it of course, but not *in* it)
A nice idea and this is in fact the case for stream files. If fixed
or variable length record files have to be sent then you need to include
information in the file to indicate where the record boundaries are.
> 2) Since we only have a small fixed number of file types in the
> archive where this is a problem (tfm, pk, gf, pxl?) we could
> write a 'fixup' command which converted a stream_lf or ra binary
> file to the appropriate record format.
The font files are generally held as fixed length record files on
VAX/VMS whereas object files are held as variable length binary files.
I'm not sure that the conversion between variable length binary files
and stream binary files is a reversible process. (Since first writing
the above, I have confirmed that this is impossible; under VMS a stream
file has implicit record boundaries --- three `flavours' of stream use
LF, CR or CRLF as the marker. Binary files don't necessarily contain
any of these characters, which would make the entire file into one
record --- VMS file reading is always record oriented because the RMS
services perform reads of rather larger entities than a character.
Files that didn't contain any such marks would be limited to
a total size of 32kB by the blocking conducted by RMS. Furthermore,
keeping all files in the Aston Archive in a stream format would prevent
the retrieval of any file in which more than 2kB appeared without an
intervening end-of-line mark in the stream, because of the Coloured
Books software.)
> Apart from those file types mentioned, I recommend that all other
> files in the archive are line-based text files which should get through
> most ftp implementations with their line-stucture preserved.
I agree, but others want to be able to fetch packages in .tar.Z format.
I've attached part of the very preliminary draft documentation for
VVCODE which I hope will explain why I have been forced to produce yet
another coding scheme.
Any comments on the attached draft would be appreciated.
I'll leave the last words to Dominik:
> Yes, Neil, I see. It really boils down to structured file support, I
> guess. I have never had a VMS account: all I know is DOS and Unix, and
> I am a bit myopic because of that.
>
> Doesn't VMS now support some kind of stream file format?
>
> Anyway, now I see the reason for VVencode, I shall swap to it. It would
> be good if it could be spread very widely, even outside the TeX world.
>
> Dominik
Niel Kempson
[Attached file: VVCODE.DOC]
- -----------------------------------------------------------------------------
VVCODE PRELIMINARY DOCUMENTATION
Version 0.0 of 26 October 1990
1. INTRODUCTION
Encoding schemes introduced to transmit binary files over text mail
systems. Primary examples are:
**TODO**
a. Hexadecimal
b. BOO
c. UUcode
d. XXcode
The known implementations of these schemes have been designed
primarily for operating systems with stream file systems. They are
unsuitable for exchanging data between operating systems with
record/block oriented file systems (e.g. VAX/VMS, VM/CMS) where
different file formats are used for different types of files. Some
encoding systems can be used to exchange data between operating
systems with record oriented file systems, but tend to be specific
to a particular operating system (e.g. TELCODE, MFTU for VAX/VMS).
2. THE IDEAL CODING SYSTEM
After a review of the known encoding systems (shortly after XXCODE
was released last year), an outline specification of the "ideal"
coding scheme was drawn up. The key points of the specification are:
2.1 CODING SCHEME
It should be possible to specify the coding table to be used
to encode the data. The coding table used shall be recorded
with each part of the encoded data.
If a recorded coding table is found while decoding the encoded
data file, it should be used to construct an appropriate
decoding table. Simple one-to-one character corruptions should
be corrected as long as only one of the input characters is
mapped to any one output character.
The default encoding/decoding table should avoid the
corruptions commonly encountered when passing mail through
badly-behaved gateways such as the UK.AC.EARN-RELAY EARN/JANET
geteway. The recommended table is the default XXcode table
using only the characters:
+-0123456789
abcdefghijklmnopqrstuvwxyz
ABCDEFGHIJKLMNOPQRSTUVWXYZ
Encoded lines should be prefixed by an approprite character
string to distinguish them from unwanted lines such as mail
headers and trailers. Lines should not end with whitespace
characters as some mailers and operating systems strip off
trailing whitespace.
2.2 FILE SPLITTING
The encoding program should be able to split the encoded output
into parts, each no larger than a maximum specified size.
Splitting the output into smaller parts is useful if the
encoded data is to transmitted using electronic mail or over
unreliable network links that do not stay up long enough to
transmit a large file. The recommended default maximum part
size is 30kB.
The decoding program should be able to decode a multi-part
encoded file very flexibly. It should not be necessary to
a. strip out mail headers and trailers.
b. combine all of the parts into one file in the
correct order.
c. process each part of the encoded data as a
separate file.
2.3 VERIFICATION
The encoding program should calculate parameters of the input
file such as the number of bytes and CRC and record them at the
end of the encoded data.
The decoding program should calculate the same parameters from
the decoded data and compare the values obtained from those
recorded at the end of the encoded data.
2.4 FILE ORGANIZATION
The encoding program should be able to read different types of
input file and record the organization of the file at the start
of the encoded data. This is not too important for operating
systems with stream type file systems (e.g. Unix, MS-DOS) where
files are simply written as streams of bytes, but is very
important for operating systems with record oriented file
systems (e.g. VAX/VMS, VM/CMS) where different types of file
are organized in different ways.
The decoding program should be able to use this information to
create the output file using the organization appropriate to
the operating system in use.
2.5COMPATIBILITY
The encoding and decoding schemes should be able to read and
write files compatible with one or more other coding schemes.
2.6 AVAILABILITY
The source code for the programs should be freely available.
It should also be portable and usable with as many computers,
operating systems and compilers as possible.
3. VVCODE
After scouring unsuccessfully around the networks and mailing lists
for such a coding system, we decided to implement yet another file
encoding scheme called VVCODE. VVCODE is an extension to the
standard Unix UUcode utilities used for the transmission of (binary)
files over a medium capable of passing only text files.
The VVCODE encoding and decoding programs implement most of the
specification detailed above. The features of VVENCODE and VVDECODE
are summarized below, keyed to the specification.
3.1 CODING SCHEME
The default coding table for both VVENCODE and VVDECODE is the
standard XXcode table using the characters:
+-0123456789
abcdefghijklmnopqrstuvwxyz
ABCDEFGHIJKLMNOPQRSTUVWXYZ
The encoding table used by VVENCODE is recorded in the encoded
data file.
If VVDECODE encounters an encoding table in the encoded data,
it is used to construct a decoding table. Simple one-to-one
character corruptions can be corrected as long as only one of
the input characters is mapped to any one output character.
A command line qualifier can be used to override the coding
table used by VVENCODE and VVDECODE.
Each line of the VVENCODEd data has a unique prefix ("Vv") and
suffix ("V"). VVDECODE ignores any lines in the input file
that do not begin with this prefix such as mail headers and
trailers. The suffix is not used - it is present to avoid
trailing whitespace on any line of the encoded data.
3.2 FILE SPLITTING
VVENCODE can split the encoded output into parts, each no
larger than a maximum specified size. The default maximum part
size is 30kB.
VVDECODE can decode a multi-part encoded file in a very
flexible way. The parts may be presented to VVDECODE in the
following ways:
a. as one file containing all of the parts in any
order.
b. each part is in a separate file. Ideally each
part number has the file extension ".v##", where
## is the part number, but if VVDECODE cannot find
a file with this extension it will prompt the user
to supply the file specification for the part.
c. a combination a. and b., i.e. a number of files,
each containing one or more parts in any order
Again the parts can be presented to VVDECODE as received; it
is not necessary to remove mail headers or trailers.
3.3 VERIFICATION
VVENCODE calculates the number of bytes and the 16 bit CRC of
the input file and records these parameters at the end of the
encoded data.
Whilst decoding, VVDECODE calculates the number of bytes and
the 16 bit CRC of the decoded data. If these parameters are
recorded in the encoded data file the two versions are compared
to verify the fidelity of the encoding/transmission/decoding
process.
3.4 FILE ORGANIZATION
**TODO**
modes: binary, text
file formats: stream (Unix, MS-DOS, TOPS)
fixed length records (VAX/VMS, VM/CMS)
variable length records (VAX/VMS, VM/CMS ?)
record length: specified and recorded in the VVCODE file
3.5 COMPATIBILITY
VVCODE cannot yet read or write encoded files compatible with other
systems such as UUcode and XXcode. Soon, VVCODE will be able to
read UUcode and VVcode files, but not write them.
3.6 AVAILABILITY
The source code for VVCODE will be freely available (see section 6
for conditions).
VVCODE has been ported to most of the commonly used environments.
For a full list of the environments supported, see section 10.
4. FORMAT OF A VVENCODED FILE
4.1 PREFIXES AND SUFFIXES
Vv prefix to help distinguish VVENCODEd lines from other lines
such as mail headers and trailers
V suffix to prevent lines ending in spaces which may be
trimmed by certain mailers and file systems
4.2 HEADER INFORMATION
a. mode
b. format
c. table
d. begin
e. skipfrom
4.3 ENCODED DATA
4.4 TRAILER INFORMATION
a. end
b. skipto
c. bytecount
d. crc16
5. USING VVCODE
**TODO**
6. AVAILABILITY OF VVCODE
The VVCODE programs may be freely copied and circulated to others,
provided that no fee (beyond reasonable media copying charges) is
levied. The authors welcome bug reports and encourages suggestions
for porting to other environments and operating systems, by mail
(paper or electronic) or by telephone.
If you port this program to a previously unsupported environment or
operating system, please feed your changes back to the authors so
that others may benefit. Contributions received will be gratefully
acknowledged.
7. PORTING VVCODE TO A NEW ENVIRONMENT
**TODO**
8.THE AUTHORS
Chief Architect:
Niel Kempson,
25 Whitethorn Drive,
CHELTENHAM
GL52 5LL
England
Tel: +44 242 579105 (home)
E-mail: TeX @ Uk.AC.Cranfield.RMCS
RMCS_TEX @ Uk.Ac.TeX
Advice and encouragement:
Brian {Hamilton Kelly},
School of Elec. Eng. & Science,
Royal Military College of Science,
Shrivenham,
SWINDON
SN6 8LA
England
Tel: +44 793 785252 (office)
E-mail: TeX @ Uk.AC.Cranfield.RMCS
RMCS_TEX @ Uk.Ac.TeX
9. ACKNOWLDEGEMENTS
16 bit CRC function and other general ideas:
Nelson H. F. Beebe,
Center for Scientific Computing,
Department of Mathematics,
220 South Physics Building,
University of Utah,
Salt Lake City,
UT 84112
E-mail: beebe @ science.utah.edu
10. ENVIRONMENTS SUPPORTED
**TODO**
11. MODIFICATION HISTORY
**TODO**
- -----------------------------------------------------------------------------
------------------------------
Date: Wed, 05 Dec 90 16:54:20 +0000
From: IN1053@UK.AC.WOLVERHAMPTON.SYSA
Subject: TEX for Atari ST
Do you know of a port of this system to the Atari ST or Motorola 68000
processor. Is the source code available and how much does it cost.
There you have it, short and sweet. Thanks a lot.
marek
.-------------------------------------------------------------------.
| ___ ___ _______ |
| Marek Paul \##\ \##\ |########\ |
| User Support Analyst \##\ \##\ |##|~~~|##| |
| Wolverhampton Polytechnic H.E.C. \##\ \##\ |##|___|##| |
| Phone - 0902 321000 (Switchboard) \##\ \##\ |########/ |
| DDI - 0902 322677 \##\ \##\ |##|~~~~ |
| Fax - 0902 322777 \##\ \##\ |##| |
| EMAIL - m.paul@uk.ac.wolves.a \##\ \##\|##| |
| ~~~ ~~~ ~~ |
`-------------------------------------------------------------------'
------------------------------
UK TeX ARCHIVE at ASTON UNIVERSITY
*** FTP access ***
Host: uk.ac.aston.tex username: public password: public
*** Files of interest ***
[tex-archive]00aston.readme [tex-archive]00directory.list
[tex-archive]00directory_dates.list [tex-archive]00directory.size
[tex-archive]00last30days.files
*** Media distributions ***
Washington Unix tape (28 March 1990)
TeX 2.993(==3.0), LaTeX 2.09, Metafont 1.9 (2.0)
Unix 4.2/3BSD & System V. Tar 1600bpi, blockfactor 20, 1 file.
Send one 2400' tape with return labels AND return postage.
VMS backup of the archive requires two 2400' tapes at 6250bpi.
VMS backup of TeX 2.991 plus PSprint requires one tape.
Exabyte 8mm tapes: same formats available as 1/2in tapes.
The following tapes are available: SONY Video 8 cassette P5 90MP,
MAXCELL Video 8 cassette P5-90, TDK Video 8 cassette P5-90MPB
OzTeX (for Macintosh): Send 10 UNFORMATTED 800K disks with return postage.
emTeX (for MS-DOS): Send 11 UNFORMATTED 720K 3.5" disks or 12 UNFORMATTED
5.25" disks with return postage.
*** Postage rates: (cheques made payable to Aston University) ***
0.5" tapes: UK: 2.50 pounds sterling (one tape), 5.00 (two tapes).
Europe: 5.00 pounds sterling (one tape), 9.00 (two tapes).
Outside Europe please enquire.
8mm tapes: UK: 1.00 pound sterling. Europe: 2.00.
DC600A cartridges: UK: 1.00 pound sterling. Europe: 2.00.
Diskettes: UK: 1.00 pounds sterling. Europe: 2.00.
*** Postal address ***
Peter Abbott,
Computing Service, Aston University, Aston Triangle, Birmingham B4 7ET
End of UKTeX Digest
*******************