summaryrefslogtreecommitdiff
path: root/dviware/crudetype/version3/aaaread.me
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 /dviware/crudetype/version3/aaaread.me
Initial commit
Diffstat (limited to 'dviware/crudetype/version3/aaaread.me')
-rw-r--r--dviware/crudetype/version3/aaaread.me484
1 files changed, 484 insertions, 0 deletions
diff --git a/dviware/crudetype/version3/aaaread.me b/dviware/crudetype/version3/aaaread.me
new file mode 100644
index 0000000000..4913de52ef
--- /dev/null
+++ b/dviware/crudetype/version3/aaaread.me
@@ -0,0 +1,484 @@
+SITE: UK.AC.RHBNC.VAX
+DIRECTORY:UHAH:[208.CRUDE]
+
+FILE: AAAREAD.ME. This file lists the intended contents of this directory.
+Note that not all these will be included when I send files out; you can get
+the missing ones if you have FTP access to this site.
+
+********************************** NOTE **********************************
+
+COPYRIGHT ( C ) R.M.Damerell, 1988.
+
+Permission is given to any person to make and distribute copies of this
+software, subject to the following conditions:
+
+1. All copies of the software must carry an exact copy of this notice.
+
+2. This software is distributed free of charge, "AS IS" with absolutely no
+guarantee of performance. Any persons receiving or using this software must do
+so entirely at their own risk. Neither the authors nor their institutions
+accept any liability for any defects of this software, or for any consequential
+loss or damage however caused.
+
+3. Any person who changes this software must clearly mark it as modified and
+add a note describing the changes made. Anybody making substantial additions or
+improvements is requested to give copies to me (RMD).
+
+****************************** VERSION 3 (1990) ********************************
+
+
+First, I want to thank G-H Knauf, M Rawohl, J Warbrick, A Trevorrow and P King,
+for many improvements which I have tried to incorporate into the WEB program.
+At present, this version runs on VMS and SUN-OS3.5 and "similar" versions of
+Unix. I have tried to adapt it to web2c; but the language that web2c translates
+is still nothing like Standard Pascal. The main changes include:
+
+Several new coding schemes;
+
+Separate horizontal and vertical magnifications;
+
+Two flavours of screenview
+
+Barring bugs, I intend V3 to support the Level 0 device driver standard,
+except as follows:
+
+2.6.1. (Location of origin). This must be allowed to move or else a
+negative \hoffset would force off the paper text which on a proper printer
+would be on the paper.
+
+2.6.3. (Range of movement). Standard specifies 2^31 units in any direction;
+Crudetype only allows 2^31-1 because that is VMS Pascal's maxint.
+
+3. Configuration. /D lets you specify the location of fonts. I dont know
+what the Standard means by changing the "naming scheme" for fonts, but I am
+sure you cannot do this without recompiling.
+
+4.1. Font formats. Since Crudetype does not use raster data, it reads TFM
+files only.
+
+5. For reasons explained in my original paper (Tugboat v7) you cannot get
+tolerable results on a lineprinter by merely rounding DVI units to printer
+units. Crudetype has to do something much more complicated.
+
+I have only seen a draft of the Standard, I dont know what changes may have
+been made since.
+
+
+ CRUDETYPE
+
+is written in PASCAL and WEB. In order to reduce the confusion of file names,
+I have had to try to introduce a definite scheme for naming files. In general,
+all files that belong to any particular operating system will have names that
+start with the system's name (truncated if necessary), and end with a (system-
+dependent) suffix indicating the type of file. Any exceptions should be
+documented here. e.g. the Unix Makefile ought to be called UNIX.COM or
+similar. Each file will start with a comment giving its name.
+
+CRUDETYPE.WEB the program, now Version 3
+CRUDETYPE.CH Dummy change file. (Its purpose is to let you weave
+ Crudetype, see below).
+
+
+VMS.CH VMS Change file.
+VMS.COM Command file giving some idea how to build Crudetype on VMS.
+ I am getting less and less interested in VMS; I dont
+ expect to make any serious attempt to debug this.
+VMSUSER.TEX Users documents. These are VMS-specific and will need to
+VMSHPGF.TEX be rewritten on other sites.
+
+
+UNIX.CH Unix Change file (written by Peter King, Heriot-Watt,
+ and copyrighted by him on the same terms. Altered by RMD.
+ I have made so many changes to all these files that I
+ think any bug reports should come to me ).
+Makefile Unix Makefile for the above. (ditto)
+UNIXEXT.C Routines in C to bypass defects in Unix Pascal. Mostly
+ copied from H.Trickey's DVITYEXT.C
+UNIX.CAP printcap file for some printers. buggy. I cannot get X-OFF flow
+ control to work properly.
+UNIXCRU.MAN Attempt at Unix style man page. This must be edited to reflect
+ local conditions.
+
+
+PRIMOS.CH Primos change file, by J.Warbrick.
+PRIMOS.CPL Command file for building this version.
+
+
+NOSVE.CH change file for NOS/VE, by courtesy of G-H Knauf
+ and M.Rawohl, University of Hannover.
+ (Provisional. Please send bug reports to RMD)
+NOSVE.DOC Document for this,
+NOSVE.COM a NOS/VE system procedure to call this program
+ (Needs rewriting, I dont know how)
+NOSVEBIND.CYB CYBIL routines for file handling (N.Schwarz, Ruhr
+ University Bochum).
+
+At present the Primos and NOS-VE files are all out of date; they belong to V2
+and I cannot do anything about this as I have no access to these machines.
+
+
+PRO-PAS.CH Attempted change file for MESS-DOS and Pro-Pascal. Failed
+ because the program is too big for Pro-Pascal, even
+ with the so-called "big" model and with some fudges
+ to reduce the data size. The worst thing is that the
+ diagnostics are completely useless. There is nothing
+ to show how much too big it is, or which bit is too big.
+ You dont even get told where in the program it failed;
+ the error is arbitrarily attached to the last line.
+
+
+NOSCHEME.ADD This has to be used with TFM files that do not have coding
+ schemes. Read it first, then append it to CRUDETYPE.WEB
+ then Tangle as usual. I believe it is system-independent.
+
+
+PHILIPS.CH Obsolete change file for Philips printer.
+HP.CH Change file for Hewlett-Packard Laserjet+
+HPGF.CH Same, but uses GF files instead of PXL. This version
+ is experimental, and slow. Allows /L = Landscape,
+ /E and /O = print even/odd pages only.
+
+
+CRUDETYPE.PAS etc. Files produced during compilation. Not distributed.
+
+W2C.* Modified version of WEB2C. See below.
+
+PHILIPS only works on a particular model of Philips GP300, with a particular
+suite of resident fonts (listed in the .CH file). It is really intended as a
+pattern to show what a printer change file should look like. There is a lot of
+scope for improvement, especially in the design of the multi-character
+commands. Because TEX characters are narrower than Philips, it seems that if
+you format a document correctly for ( say) A4 paper, it falls off the paper
+when printed on the Philips. This is most irritating, and I do not know any
+cure.
+Later: I have had to abandon any serious attempt to debug this version. The
+printer has been removed.
+
+HP cannot do landscape mode. (HPGF can) This could presumably be fixed fairly
+easily, given time. Also I can no longer test HP, because all the PIXEL files
+have been removed.
+
+ INSTALLATION
+
+This requires Pascal and the Stanford Tangle program (You will have Tangle if
+you got your TeX software from a reputable source.) In theory, you compile
+Crudetype the same way as TEX; assemble a suitable change file; then run it
+through Tangle and the Pascal compiler. In order to write Crudetype in any
+reasonably well-structured way I had to break the WEB rule that macros be
+defined before they are used. For simple and parametric macros, this rule is an
+illusion. In Tangle V4, this non-rule has been abandoned. If you use a macro
+before defining it TANGLE prints an error message "This identifier has already
+appeared" but expands it correctly. Such errors can therefore be disregarded.
+For numeric macros it is necessary to define WEB macros before use; I have
+conformed to this rule.
+
+When Crudetype was first written, I hoped to arrange that the installer could
+just take Change files for the local system and printer, concatenate them, and
+go. Unfortunately, it isnt that simple. Even if you are lucky enough to have a
+change file named after your system, there are often site-dependent variations.
+(Some of these are mentioned below). No matter what printer or machine you have
+in mind, I recommend that you get copies of ***all*** available change files.
+They show several possible approaches to similar problems. The basic version of
+Crudetype is designed for a lineprinter; you should start with this version
+because that defers the problems caused by trying to work with two changefiles
+at once.
+
+This seems time to mention a very obscure piece of jiggery-pokery in WEAVE.
+WEAVE will not work unless it can find a changefile. If WEAVE sees the command
+\let\maybe=\iffalse then it inserts a something into its TEX output. The result
+is that TEX prints only those modules that were altered by the changefile.
+CRUDETYPE.WEB contains this command, but CRUDETYPE.CH (which is only a dummy
+changefile) changes this to \iftrue. Weaving Crudetype with this will give the
+whole un-changed program. All the real changefiles leave \maybe unchanged; so
+these will give only the changed modules (well, maybe!!)
+
+Initially Crudetype was written for the VMS operating system, and a lot of very
+system-dependent code got into the main program. As change files started to
+appear, it became clear that this is unclean. I have now tried to remove all the
+most system-dependent code into the VMS change file. A typical example is the
+procedure that parses file names. CRUDETYPE.WEB merely provides a hook to hang
+this procedure on, saying "the changefile must define this procedure". All
+procedures that are handled in this way and all the code that is known to be not
+Standard Pascal are in the section headed "system-dependent code". Suppose that
+you have to write a change file from scratch, the most simple- minded way to
+begin is to choose any of the system change files and just throw the program at
+the compiler and look at the flood of errors that emerge. Tne go through the
+section on system-dependent code using the available change files as a model for
+the parts that have to be rewritten. I would assume that all of this section has
+to be rewritten for any new machine.
+
+If you succeed in getting Crudetype to work, then you need to edit the user
+document VMSUSER.TEX to reflect local conditions.
+
+ DIFFICULTIES
+
+This section describes some of the difficulties that have appeared on various
+systems, excluding those due to bugs in Crudetype, which I have tried to fix.
+Unix presents special difficulties, see below.
+
+1. Incompatible file formats. This disease is particularly bad on VMS systems.
+TEX and related programs assume that a binary file is just a stream of bytes.
+Now it seems that VMS Pascal cannot handle files of this type, so VMS TEX and
+Metafont generate files in fixed length 512-byte records. Crudetype expects
+this format. Some people have started distributing files in incompatible
+formats. I have seen: files in Stream-LF format, files with the bytes in a
+different order, and fixed-record files where the short record at the end is
+padded with what looks like random garbage. Stream-LF has two disadvantages: (a)
+there is no VMS software commonly available that can read it (b) some
+TEX-related files are intended to be read from the end backwards, and VMS Pascal
+can only do this with fixed-record files. What I think is particularly
+anti-social is that the authors of these files have not made any attempt to tell
+the rest of the VMS TEX community what they are doing or why. Later; it appears
+that somebody has cleaned this mess up. I have no idea who it was, but I am very
+grateful to him or her.
+
+When Crudetype meets a bad file, it will probably fail with a "cannot open file
+(name)" error. This can happen because: the file of that name isnt there; or the
+system doesnt give you permission to read it; or it has a bad record structure.
+In VMS, you can check by $DIRECTORY/FULL (name) . If the data is bad (e.g. bytes
+in unexpected order) you can check by dumping the first 100 bytes of the file in
+octal or hex and comparing this with the format as described in TUGboat. Or you
+can try running DVITYPE or TFTOPL or GFTYPE according to whatever file it was.
+This is easier, but if somebody has altered both the files and these programs,
+this will not be apparent. Note the (default) format of VMS DUMP is very
+peculiar, consult its manual.
+
+2. Missing coding schemes. The TFM files that come on tapes from Stanford
+contain a piece of data called a `coding scheme'. Essentially, this tells you
+what letter to expect to find in each cell of the font table, if you ignore
+topological differences of slant, blackness etc. Each table in Appendix F of the
+TEXbook gives a different scheme; and there are a few more schemes in fonts in
+common use. Unfortunately, some font designers have been producing fonts with
+this information lacking. It is not actually illegal to omit the coding scheme
+because the specification for TFM font files describes the coding scheme as
+optional. But in my opinion this is a bad practice. If a site cannot provide
+file space for every conceivable font, they will probably want to save space by
+some form of font-substitution. The coding scheme is an essential tool for
+trying to decide whether Font A is an acceptable substitute for B.
+
+If your TFM files do not have coding schemes, Crudetype should give a "no coding
+scheme" error. You can examine TFM files by TFTOPL or (in VMS) by DUMP. The file
+NOSCHEME.ADD gives code to tackle this problem. To use it, simply append it to
+CRUDETYPE.WEB. This essentially lists the schemes of each of the fonts I happen
+to have seen on a particular distribution. This will clearly go wrong if anybody
+starts writing TFM files of the same names with different schemes, and these new
+schemes are not written into the TFM file. V3 adds support for some Postscript
+fonts (due to J.Warbrick). The Postscript fonts on our site all have coding
+schemes but they were clearly inserted by somebody who didnt know what a coding
+scheme was. The schemes written into the files are like this: "HELVETICA LIGHT
+ITALIC", but the scheme actually used is nearly always "TEX TEXT". So when
+Crudetype finds an unknown scheme, it defaults to "TEX TEXT".
+
+3. Another difficulty (on VMS) was to find some way to get the output file
+across to the printer. I cannot give any useful advice on this because it is
+not merely system- but site-dependent. To get output on the HP, I had to
+connect it as a terminal because it was impossible to drive printers across
+our network. This needed the command:
+ $set terminal/eight_bit/form/pasthru
+to allow data to be tramsmitted correctly.
+ VMSSPEW.COM
+works at our site, as follows: user has to log in, then invoke the .COM file.
+This asks for the file to be printed, then pauses. Then it types the .HPL file
+at the terminal. Meanwhile the user must switch output onto the printer. Messy,
+but it works, and waiting for network software to be debugged is a job for
+Methuselah.
+
+In Unix I had to write a "printcap" file for similar reasons. My attempt at this
+was very buggy.
+
+4. Defects of PASCAL. In order to overcome some of the defects of Berkeley
+Pascal Peter King had to use some C programs which are part of the standard Unix
+Tex distribution (and needed for the same purpose there.) I could not get the
+regular versions of these to work, so I hacked them until they did work (on our
+machines). Essentially, I just deleted everything whose purpose was not obvious,
+but there was also a peculiar bug in passing strings from Pascal into C. These
+routines come in a file called "unixext.c". Eventually he or I might do the
+proper thing and make everything use the Pascal-to-C-converter. Meanwhile
+consult the Makefile for instructions. Similarly, the NOS-VE version uses a
+whole suite of "CYBIL" routines originally written for TEX by N.Schwarz. I
+gather that it is a complicated job to attach these to the program, at any rate
+I have no idea how it is done. You can go back to just using Pascal binding by
+redefining the macros in the changefile.
+
+5. Fortran carriage control. Originally there were bugs in this, I hope they
+are fixed. The code does work on VMS.
+
+6. In V3, the /i flag is extremely system-dependent. I got it to work on VMS
+and SUN-OS 3.5.
+
+
+
+
+
+ OTHER FILES
+
+In order to ease the process of installing the program on another system, I
+have prepared some test files. I am not sending any binary files as these get
+damaged in transit.
+
+SAMPLE.TEX A small piece of straightforward TEX text, copied from
+a Stanford tape.
+
+SAMPLE.DVI Its DVI file, produced by the VMS version of TEX,
+(also from a Stanford tape). Logically a DVI file is just a long stream of
+8-bit bytes, but it appears that VMS cannot handle that type of file properly.
+So VMS TEX writes DVI files in fixed-length 512 byte records.
+
+SAMPLE.PRI Same file, passed through Crudetype. Here again there
+is a peculiarity in the file format. Normal VMS text files have "list"
+carriage control, which means ( roughly speaking) that VMS will insert a CR
+and a LF at the end of each record when it prints the file. Crudetype has to
+use carriage control = NONE , which means that all carriage controls must be
+explicitly inserted by the program.
+
+SAMPLE.PHI Philips printer output.
+SAMPLE.HPL Laserjet printer output, generated by PHILIPS.EXE
+ and HPGF.EXE respectively.
+
+NASTY.TEX A selection from MYTANGLE.TEX . This contains some of
+ the modules from TANGLE; I chose several fragments
+ that gave me trouble when I tried to print them using
+ Crudetype.
+
+NASTY.DVI, etc. As for SAMPLE.
+
+TABLES.TEX, etc. Tries to print all the font tables from the TEXbook.
+ The purpose is to help installers to check any
+ font data that they enter.
+
+TINY.TEX A tiny piece of straight text. Provided to generate
+ the file
+TINY.DMP which is a hexadecimal dump of TINY.HPL . The idea is
+ that when you get a horrible mess coming out on your
+ printer, you can compare this file with a dump of your
+ locally-produced output. Reading VMS dump files is
+ somewhat of a black art: I have added comments.
+
+Another excellent test is to extract the quotation from Galileo from Page
+101 of the TEXbook. (copyright, so I cannot copy it here.) You need to set
+ \varunit=1.078pt
+to get it to work. The line-printed output looks best magnified by about 50%.
+
+
+ RECENT CHANGES
+
+1. Added extra magnification, described above.
+2. (Lineprinter) Improved horizontal & vertical positioning. Previously the
+line spacing jumped from double to triple quite unpredictably. Also WEB-style
+tables of contents used to come out excessively wide because the thin spaces
+between dots got expanded to whole lineprinter spaces. I have made a fix.
+3. (Lineprinter) Support for coding schemes "AEFMNOT ONLY" and "TEX TEXT
+WITHOUT F-LIGATURES".
+4. Improved sort routine. This makes the program at least 3 x faster; I think
+because it now takes advantage of runs in the input, and TEX DVI output is
+very "runny".
+5. I had to abandon the use of PXL files as they are too large. So I have
+cobbled together a GF-using version of HP. It needs a lot more work done on
+it; it is too slow.
+6. Fixed the "no-scheme" bug (caused Crudetype to crash if a TFM file has no
+coding scheme). If you have this sort of TFM file, you will need the file
+NOSCHEME.CH instead of CRUDETYPE.CH . Also some minor fixes.
+7. New version (Version 1, Jan '88). Fixes all bugs so far notified to me.
+Note: it also renders obsolete all previous Change files. The new versions
+all refer to Crudetype v.1.
+8. Tried to make the Lineprinter print TEX MATH EXTENSION characters.
+9. Unix Change file written by Peter King.
+10. NOS/VE Change file by courtesy of G-H Knauf and M.Rawohl.
+11. Version 2. Again, all existing change files are obsolete. Many bugfixes,
+code to read and parse a command line, and (I hope) a much cleaner interface
+to the operating system.
+12. HPGF altered to allow landscape mode printing. Also, print even- or odd-
+numbered pages. In theory this will allow double sided printing, but with
+difficulty.
+13. Some extra characters now get printed.
+14. Primos change file, courtesy J.Warbrick.
+15. After tremendous struggle, got it through web2c.
+16. Version 3.0. Bugfixes. Added flags /x, /y, /d, /b, /i. Try to conform to
+all relevant parts of the draft DVI driver standard (Level 0). Several extra
+coding schemes, courtesy J.Warbrick. Screenview versions, (also originally
+due to J.Warbrick).
+
+V3 makes all older changefiles obsolete. I have adapted vms.ch and unix.ch,
+but cannot deal with primos or nos-ve. I have added Emacs type labels to all
+changefiles.
+
+17. Version 3.01. Modified web2c so it will compile Crudetype. Further details
+below. Tiny change to the WEB file, does not affect any changefile I have seen.
+
+
+
+
+***************************************************************************
+
+MYTANGLE.WEB, .CH, etc.
+
+My version of TANGLE, more-or-less as described in TUGboat. (altered to give
+much better diagnostics than regular TANGLE). The change file is aimed at
+VMS. I hope my alterations might work with other sites versions of TANGLE.CH.
+Recently upgraded to Tangle V4; the VMS version has bugs which I hope to
+fix "soon".
+
+
+***************************************************************************
+
+ RUNNING CRUDETYPE on Unix
+
+This presents special difficulties because many Unix Pascal compilers are very
+bad and also very variable. There is in fact no such language as Unix Pascal;
+instead, there are many languages of the same name. Therefore some members of
+the Unix TEX community wrote a package called WEB2C that translates a very
+specialised and peculiar dialect of Pascal into C. Many constructions of
+Standard Pascal are rejected; others are incorrectly translated. In order to get
+around this I had to write my own version of Web2c; I have called it W2C to
+reduce confusion. The changes are all intended to make W2C more like Standard
+Pascal, but there is still an enormous difference. Also the change files for TEX
+etc contain many fudges to adapt these programs to Web2c; therefore I think it
+very unlikely that you could successfully compile TEX using my W2C. I hope
+sometime to rectify some of the following known defects. All of these and more
+are also in Web2c.
+
+The following constructions of Standard Pascal are mishandled by W2C:
+
+Procedures nested inside procedures; Procedure parameters; Redeclaration of
+identifiers in nested blocks (you can only redefine variables as variables);
+With statements; Variant records; Conformant array parameters; Enumerated types;
+Pointers; Arrays of dimension > 2; File^ for current member of a file; Non-local
+goto.
+
+Also W2C makes no attempt to detect run-time errors or various compile-time
+errors.
+
+Because the diagnostics are poor, I think W2C is only tolerable for use on a
+program that has already been extensively tested on a genuine Pascal compiler;
+so P.King's Unix changefile is still an essential tool for anybody who needs to
+test or debug Crudetype. On the other hand, using W2C does seem likely to work
+on a much wider range of Unixes that using Pascal, and the compiled program is
+roughly twice as fast (comparing unoptimised pc against unoptimised gcc ).
+W2C works on all Unix machines I have access to (not many).
+
+The procedure to build Crudetype from the sources is:
+
+1. On your TEX directory there should be a file called site.h that describes
+local conditions. Either use this or create a local site.h . Edit Makefile to
+point to this file.
+
+2. Edit other macros at the start of Makefile to describe local practice. In
+particular you need to edit the IMAGES macro to say what version(s) you want to
+build.
+
+In Makefile the POSSIBLE_IMAGES are:
+
+crudetype the main version, compiled with W2C.
+crude-p Ditto, compiled with pc
+noscheme-p noscheme-c Use these if your fonts dont have schemes.
+hpgf Attempt at HP LJ+ driver.
+
+
+3. Then run make; make install; and (optional) make clean or veryclean .
+
+This is a long messy process and requires YACC and LEX. If you dont want to do
+all this, I have included the files crude-c.c and noscheme-c.c; if you are
+clever you can probably bypass the w2c stage:
+
+touch crude-c.c
+make crudetype