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 . 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 *******************