summaryrefslogtreecommitdiff
path: root/dviware/beebe/updates
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/beebe/updates
Initial commit
Diffstat (limited to 'dviware/beebe/updates')
-rw-r--r--dviware/beebe/updates/00mail.1117
-rw-r--r--dviware/beebe/updates/00mail.10387
-rw-r--r--dviware/beebe/updates/00mail.11119
-rw-r--r--dviware/beebe/updates/00mail.12725
-rw-r--r--dviware/beebe/updates/00mail.13670
-rw-r--r--dviware/beebe/updates/00mail.14621
-rw-r--r--dviware/beebe/updates/00mail.15178
-rw-r--r--dviware/beebe/updates/00mail.16654
-rw-r--r--dviware/beebe/updates/00mail.17146
-rw-r--r--dviware/beebe/updates/00mail.2140
-rw-r--r--dviware/beebe/updates/00mail.3252
-rw-r--r--dviware/beebe/updates/00mail.465
-rw-r--r--dviware/beebe/updates/00mail.535
-rw-r--r--dviware/beebe/updates/00mail.6128
-rw-r--r--dviware/beebe/updates/00mail.773
-rw-r--r--dviware/beebe/updates/00mail.8189
-rw-r--r--dviware/beebe/updates/00mail.9292
17 files changed, 4791 insertions, 0 deletions
diff --git a/dviware/beebe/updates/00mail.1 b/dviware/beebe/updates/00mail.1
new file mode 100644
index 0000000000..94a48f9d12
--- /dev/null
+++ b/dviware/beebe/updates/00mail.1
@@ -0,0 +1,117 @@
+18-Feb-87 09:36:05-MST,4267;000000000001
+Mail-From: BEEBE created at 18-Feb-87 09:36:02
+Date: Wed 18 Feb 87 09:36:01-MST
+From: "Nelson H.F. Beebe" <Beebe@UTAH-SCIENCE.ARPA>
+Subject: DVI driver family update #1
+To: $90%dhdurz1.bitnet@WISCVM.WISC.EDU, austins%ucbcmsa.edu@UTAH-CS.ARPA,
+ cel%cithex.caltech.edu@UTAH-CS.ARPA,
+ crawford-j%ohio_state.arpa@UTAH-CS.ARPA,
+ crm8701%tamvenus.bitnet@WISCVM.WISC.EDU,
+ gaspard%hroeur5.bitnet@WISCVM.WISC.EDU,
+ james%vaxe.coe.northeaster.edu@UTAH-CS.ARPA,
+ lamy%ai.toronto.edu@RELAY.CS.NET, mpc91b%dgogwd01.bitnet@WISCVM.WISC.EDU,
+ rjones%uwovax.bitnet@WISCVM.WISC.EDU, rs%gnome.cs.cmu.edu@UTAH-CS.ARPA,
+ stone%ruthep.rutgers.edu@UTAH-CS.ARPA,
+ system%uvphys.bitnet@WISCVM.WISC.EDU, thobe@EE.UCLA.EDU,
+ zeffi%finabo.bitnet@WISCVM.WISC.EDU
+cc: BEEBE@UTAH-SCIENCE.ARPA
+X-US-Mail: "Center for Scientific Computation, South Physics, University of Utah, Salt Lake City, UT 84112"
+X-Telephone: (801) 581-5254
+Message-ID: <12280054855.6.BEEBE@UTAH-SCIENCE.ARPA>
+
+For those of you who supplied an EMAIL address, I have set
+up a mailing list which I will use to announce changes in my
+DVI driver family. All tapes and floppy disks received as
+of 18-Feb-87 have now been shipped.
+
+Since the TeXHaX announcement, ANONYMOUS FTP access for
+Internet sites has become available. To use it, login with
+ANONYMOUS FTP to UTAH-SCIENCE and get the file 00README.TXT.
+It contains information on how to find things.
+
+Here is part of the 00REVHST.TXT file:
+
+-----------------------------------------------------------------
+[10-Feb-87]
+ Yesterday I discovered that VAX VMS 4.4 printf()
+ wipes out the stack and kills the process if a
+ long string is printed. This turns out to be the
+ case in outline() in dvitos.c; the code has been
+ modified to use fputs() there instead.
+
+[10-Feb-87]
+ Several debugging sessions on VAX VMS stepping
+ through the call chain fflush() -> _flsbuf() ->
+ _flsbuf_record() -> write_record() ->
+ write_buffer() -> write_imbed() -> write_output()
+ ->signal() -> c$$translate() have made it clear
+ that the simple scheme in dvi*.c and lptops.c of
+ checking for a non-zero return value from
+ fflush() or ferror() is an unreliable way to
+ conclude a legitimate error (specifically, disk
+ storage exhausted) exists. Consequently, these
+ routines have been modified to call clearerr() at
+ the beginning of loadchar() and prtbmap(), then
+ to use a macro DISKFULL() to test for the error
+ condition. DISKFULL() is defined in machdefs.h,
+ and errno.h is now included by dvihead.h. This
+ regrettably introduces small changes in a number
+ of routines, but no other clean way of doing the
+ job appeared to be feasible.
+
+[02-Feb-87]
+ Changed "pagecollation on" to "pagecollation off"
+ in dviimp.c. With version 3.3 of the Imagen
+ Image Processor software, there seems to be a bug
+ in that "pagecollation on" causes page reversal.
+ I have reported this to Imagen.
+
+-----------------------------------------------------------------
+
+Here are Unix diff output listings for the affected files.
+All the dvi*.c routines have similar changes; the two listed
+here are typical.
+
+machdefs.h:
+113a114
+> #define DISKFULL(fp) (ferror(fp) && (errno == ENOSPC))
+337a339
+> #define DISKFULL(fp) ferror(fp) /* PCC-20 does not always set errno */
+
+dvialw.c:
+566a567,568
+> clearerr(plotfp); /* VMS sets the error flag unexpectedly */
+>
+583c585,586
+< if (ferror(plotfp) != 0)
+---
+>
+> if (DISKFULL(plotfp))
+
+
+dvitos.c:
+104c104
+< #define OUTFILE_EXT ".tos"
+---
+> #define OUTFILE_EXT ".dvi-tos"
+333,335c333,337
+< (void)fprintf(plotfp,"\033;%04d%s",
+< len >> 2,pline); /* quadruple count ESC;nnnn */
+<
+---
+> {
+> (void)fprintf(plotfp,
+> "\033;%04d",len >> 2); /* quadruple count ESC;nnnn */
+> (void)fputs(pline,plotfp);
+> }
+362a365,366
+> (void)clearerr(plotfp);
+>
+486,487c490,492
+< if (fflush(plotfp) == EOF)
+< (void)fatal("Output error -- disk storage probably full");
+---
+> (void)fflush(plotfp);
+> if (DISKFULL(plotfp))
+> (void)fatal("prtbmap(): Output error -- disk storage probably full");
+-------
diff --git a/dviware/beebe/updates/00mail.10 b/dviware/beebe/updates/00mail.10
new file mode 100644
index 0000000000..6c8f945f68
--- /dev/null
+++ b/dviware/beebe/updates/00mail.10
@@ -0,0 +1,387 @@
+20-Aug-87 08:46:00-MDT,18698;000000000000
+Date: Thu 20 Aug 87 08:46:00-MDT
+From: "Nelson H.F. Beebe" <Beebe@SCIENCE.UTAH.EDU>
+Subject: DVI driver family update #10
+To: "DVI mailing list": ;
+cc: BEEBE@SCIENCE.UTAH.EDU, "new addresses": ;
+X-US-Mail: "Center for Scientific Computation, South Physics, University of Utah, Salt Lake City, UT 84112"
+X-Telephone: (801) 581-5254
+Message-ID: <12328007179.15.BEEBE@SCIENCE.UTAH.EDU>
+
+ DVI Driver Family Update #10
+ [18-Aug-87]
+
+Version 2.08 of the driver family is now ready. Except for
+the Atari support, this is a maintenance release only, with
+minor cleanup, a couple of small bug fixes, and cosmetic
+changes to make the installation process smoother, with no
+unnecessary compilation warning messages which have been
+causing concern to some users.
+
+Unless you have been impacted by one of the bugs, or want
+the Atari support, or the test version of the Canon LBP-A2
+driver, it should not be necessary to update your sources.
+I will, however, provide the European redistribution sites
+for Bitnet and Janet with up-to-date versions. Because
+these changes affect a large number of modules, it is not
+worthwhile here to provide difference listings.
+
+This work had to be completed in time for me to make new
+master diskettes to take to the TUG meeting in Seattle next
+week. I had hoped to finish the support for resident Imagen
+fonts in time for this release, but it will have to wait.
+
+Beginning September 1987, I expect that IBM PC floppies of
+the DVI driver family will be available from from Personal
+TeX. The details will be ironed out at the TUG meeting next
+week, and announced on TeXHaX and this mailing list.
+
+For the European Bitnet server: Contact rz92@dhdurz1.bitnet
+
+For the British Janet server: Contact AbbottP@uk.ac.aston.mail
+
+The subject of how to set up a VMS printer spooler for the
+HP LaserJet has come up repeatedly. Portia Shao reported
+the following approach recently:
+
+>> Date: Wed, 13 May 87 18:42 PDT
+>> From: Portia 616-2635 <PORTIA@ENGVAX.SCG.HAC.COM>
+>> Subject: re: setting up HP laserjet +
+>>
+>> In response to the person asking about setup modules etc for the laserjet+
+>>
+>> This is how we set up our HP laser jet + on our microvax II.
+>>
+>> in systartup.com we have:
+>> $define/system laserjet $terminal7: ! substibute your terminal line here
+>> $set terminal laserjet/perm/nobroadcast/notypeahead/nowrap -
+>> /speed=9600/width=80/page=0/device_type = unknown
+>> $set device /spooled=(sys$print, sys$sysdevice:) laserjet
+>> $initialize/queue/start/lib=laserjetlib/separate=(reset=reset) -
+>> /on=laserjet/default=flag sys$print
+>> $define/form/stock=default portrait 1 /desc="Portrait Courier" -
+>> /setup=(portrait) /length=60/wid=80/margin=(bottom=0)/nowrap/notrunc
+>> $define/form/stock=default landscape 2 /desc="Landscape"/setup=(landscape) -
+>> /length=45/wid=132/margin=(bottom=0)/nowrap/notrunc
+>> $define/form/stock=default compressed 3 /desc="Compressed Portrait" -
+>> /setup=(compressed) /length=80/wid=120/margin=(bottom=0) -
+>> /nowrap/notrunc
+>>
+>> and we have the following modules in sys$library:laserjetlib.tlb
+>> COMPRESSED,LANDSCAPE,PORTRAIT,RESET
+>>
+>> where compressed.txt has the following ONE line
+>>
+>> <esc>E<esc>&l0O<esc>&a5l80M<esc>&a0R<esc>&l8D<esc>&l80F<esc>(8U<esc>(s0p16.66h
+>> 8.5v0s0b0T
+>>
+>> landscape.txt has the following ONE LINE
+>>
+>> <esc>E<esc>&l10<esc>&l55F<esc>(8U<esc>(s0p10h12v0s0b3T
+>>
+>> portrait.txt has the following ONE line
+>>
+>> <esc>E<esc>&l0O<esc>&a5180M<esc>&a0R<esc>&l60F<esc>(8U<esc>(s0p10h12v0s0b3T
+>>
+>> and reset.txt has the following line
+>>
+>> <esc>E
+>>
+>> -- Portia Shao UUCP -- {allegra|ihnp4}!scgvaxd!engvax!portia
+>> Hughes Aircraft Co. ARPA -- portia@engvax.scg.hac.com
+>> or -- portia%engvax.uucp@oberon.usc.edu
+>> (213) 616-2635
+>>
+
+Jerry Leichter at Yale has extended this, and here is his
+current recommendation:
+
+>> Reply-To: "Jerry Leichter" <leichter@venus.ycc.yale.edu>
+>>
+>> The HPLJ setup I use is derived from Portia's, with some
+>> changes here and there. (I've sent mine back to her.)
+>>
+>> SET TERM/NOINTERACTIVE, which is a synonym for /PASSALL, is
+>> WRONG. (It's also obsolete, and no longer appears in
+>> current documentation.) The problem with doing that is that
+>> it disables XON/XOFF handling. The Laserjet uses XON/XOFF
+>> signaling; I don't know to what extent it might happen
+>> during normal operation, but it will certainly XOFF the host
+>> if, for example, it runs out of paper. If the line is set
+>> /NOINTERACTIVE, you can lose characters. With XON/XOFF, I
+>> am running my Laserjet at 19.2KB, rather than 9600. The
+>> speedup is minor, but it IS there. I suspect the printer
+>> WILL send XOFF's at this speed on a fairly regular basis,
+>> since it's faster than the printer can actually print!
+>>
+>> The setup I use is:
+>>
+>> $ define/system SYS$LASERJET CSA0:
+>> $ set terminal SYS$LASERJET/perm/nobroadcast/notypeahead/nowrap -
+>> /speed=9600/width=80/page=0/device_type=unknown
+>> $ set device /spooled=(SYS$PRINT,SYS$SYSDEVICE:) SYS$LASERJET
+>> $ initialize/queue/start/lib=laserjetlib/separate=(reset=reset) -
+>> /on=SYS$LASERJET/default=(flag,form=portrait) SYS$PRINT
+>> $ define/form/stock=default portrait 1 /desc="Portrait Courier" -
+>> /setup=(portrait) /length=60/wid=80/margin=(bottom=0)/wrap/notrunc
+>> $ define/form/stock=default landscape 2 /desc="Landscape"/setup=(landscape) -
+>> /length=45/wid=132/margin=(bottom=0)/wrap/notrunc
+>> $ define/form/stock=default compressed 3 /desc="Compressed Portrait" -
+>> /setup=(compressed) /length=80/wid=120/margin=(bottom=0) -
+>> /wrap/notrunc
+>> $ define/form/stock=default clandscape 4 /desc="Compressed Landscape" -
+>> /setup=(clandscape) -
+>> /length=64/wid=176/margin=(bottom=0)/wrap/notrunc
+>>
+>> (This is on a MicroVAX, with the printer connected to the
+>> console port. The printer has an additional font cartridge,
+>> which contains the font used by the CLANDSCAPE form.
+>> /speed=9600 on the set terminal command is wrong (I actually
+>> run at 19200) but irrelevent since the port involved doesn't
+>> have a software-settable speed anyway. There are a set of
+>> forms definitions to go with this; they require some editing
+>> to mail because of embedded control characters, but I can
+>> send them to anyone who wants them.)
+>>
+>> I print both normal text files and DVI files with this
+>> printer; the only thing you MUST do is include /PASSALL on
+>> the PRINT command for a DVI file. (Note: The use of the
+>> same qualifier, /PASSALL, on both SET TERM and PRINT is
+>> unfortunate, as they mean different things. SET
+>> TERM/PASSALL is obsolete and should not be used.
+>> PRINT/PASSALL is very much alive and needed here.
+>>
+
+To save me some writing, I'm including below the verbatim
+change log history between 22-Jun-87 (Newsletter #9) and
+now.
+
+[14-Aug-87] {Thanks to Matthias Moritz (U608017@NHYKUN11.EARN)
+ for Atari support additions}
+ Merged in support for the Atari 520ST+ using the
+ Mark Williams C Compiler. makefile.ast should
+ build it. Since this involves changes in many
+ routines, I took the opportunity to introduce a
+ few other changes as well, and incremented the
+ version number of dvi*.c from 2.07 to 2.08. The
+ new versions should be functionally identical to
+ the previous ones for virtually everyone.
+
+ The Mark Williams compiler has some limitations,
+ and could not handle long macro definitions, in
+ particular DEBUG_OPEN and FONTLIST. I have
+ therefore made DEBUG_OPEN() expand to dbgopen(),
+ where the latter is defined at the end of
+ dviinit.h; this does not follow my standard
+ practice of one function per file. FONTLIST was
+ simply removed, and the two instances of its use
+ were replaced by its definition. There are about
+ 40 instances in the driver source code of macros
+ continued over multiple lines. They are written
+ that way to prevent long lines in the source code
+ (80 is the absolute limit), which is an even more
+ serious barrier to portability.
+
+ The default stacksize on the Atari is often too
+ small; for the time being, main programs have
+ been set to declare a larger stack. On PC DOS
+ (which Atari GEMDOS resembles), the Microsoft
+ EXEMOD utility can be used to change the
+ stacksize of an executable program without
+ requiring code modification. I don't know
+ whether there is something similar on the Atari.
+
+ I removed the OS_xxxx-dependent conditional code
+ in dvi*.c for output file extension selection, by
+ introduction of a new variable, DVIPREFIX, in
+ machdefs.h. This is prepended to the default
+ file extension, which is now always identical to
+ the letters following dvi in the dvi*.c files.
+ On systems which do not support long file
+ extensions, it will be a null string; otherwise,
+ it will be "dvi-".
+
+ In dvialw.c, a genuine BUG surfaced; PSDEF_PATH
+ should be #define'd to be subpath instead of
+ SUBPATH. Otherwise, it cannot be overridden by
+ an environment variable. Thanks to Matthias
+ Moritz for catching this one.
+
+ An experimental version of a Canon A2 driver has
+ been added as dvica2.c, based on work by Pekka
+ Pietilainen (TFYS-PP@FINOU.BITNET), starting from
+ dvican.c. I have merged in his changes and
+ removed Unix-isms. This driver is intentionally
+ not included in the Makefiles. Only a few sites
+ have the Canon A2 printer, and once more
+ experience is obtained, it may replace dvican.c.
+ If you have such a printer, you can easily modify
+ the appropriate Makefile to support it, or you
+ can just compile and load dvica2 manually. For
+ debugging purposes, three additional option
+ switches are accepted in option.h; they will
+ disappear as the code settles.
+
+ More experience with the drivers at many VAX VMS
+ sites has indicated that variable-length record
+ files for the output are probably undesirable
+ until DEC gets its act in gear and makes all VMS
+ utilities handle such files properly. I have
+ therefore modified the code in dviinit.h to use
+ the fixed-block binary format for all but
+ POSTSCRIPT devices (for which the output is truly
+ an ordinary text file); previously, this format
+ was only selected for IMPRESS (dviimp).
+
+ For non-Unix operating systems, it is generally
+ necessary to open binary files differently than
+ text files, since the C-runtime libraries use
+ that distinction to decide how to translate Unix
+ line terminators. Every system so far has used
+ the letter "b" in the fopen() mode string to
+ select this mode, and every Unix system ignores
+ the "b", except Ultrix, which raises a run-time
+ error, sigh... I have therefore replaced the
+ mode string by RB_OPEN and WB_OPEN, and they are
+ set in machdefs.h. For all Unix systems they
+ will be "r" and "w", and for most non-Unix
+ systems, "rb" and "wb".
+
+ Lines longer than 80 characters in *.c and *.h
+ files have been wrapped.
+
+ The header "%!PS-Adobe-1.0" in dvialw.c has been
+ shortened to "%!"; the Adobe TranScript spooler
+ software thinks it is allowed to do page reversal
+ when it sees this, but dvialw output pages cannot
+ be reordered because fonts are defined only on
+ demand. The similar header in lptops.c is all
+ right; the pages there ARE independent.
+
+ The sources have been run through 4.2BSD lint and
+ System V lint. A number of missing typecasts
+ have been supplied, and several unreferenced
+ local variables have been eliminated. lint still
+ produces many warnings, but the remaining ones
+ seem to be benign, or simply red herrings.
+
+ lint revealed numerous problems with texidx.c
+ (which came from the GNU Project). I have
+ eliminated unused variables and functions, but
+ there remain some serious errors of incorrect
+ argument lists to sort_in_core() and
+ sort_offline(). I am not proposing to fix these
+ now, because at least 3 comprehensive indexing
+ packages for TeX have appeared recently, and
+ texidx.c may rapidly become obsolete.
+
+ I have changed the handling of some preprocessor
+ symbols in several routines so as to eliminate
+ redefinition warnings, and any assumptions that
+ undefined symbols evaluate to 0. The draft ANSI
+ C standard REQUIRES that all undefined symbols
+ evaluate to 0 in preprocessor expressions, but
+ many compilers to do yet follow this rule (VAX
+ VMS C in particular).
+
+[15-Aug-87] {Thanks to Julian Perry (seismo!mcvax!zen.co.uk!jules)}
+ The code in option.h in the -o switch section
+ that forced page_begin[npage] <= page_end[npage]
+ conflicts with negative page numbers for counting
+ from the end. I have removed the code there, and
+ then in dvifile.h, before the main page loop,
+ inserted code to reset the page_begin[] and
+ page_end[] arrays to positive values (this can
+ only be done after page_count is known), and to
+ order them properly.
+
+
+[10-Aug-87] {Thanks to Gary Beihl (beihl%bell.cad.mcc.com@mcc.com)}
+ In lw78.c and dvialw.c, change instances of
+ time(0) to time((long*)NULL).
+
+
+[27-Jul-87] {Thanks to Charles Karney (Karney%ppc.mfenet@nmfecc.arpa)}
+ Here are two small changes to vaxvms.c:
+
+ In vmsexit(), we turn on a high bit on a non-zero
+ status code to suppress a useless VMS message:
+ 150,151c150,151
+ < exit((1 << 28) + 2); /* error */
+ < break; /* (suppresses %NONAME-E-NOMSG) */
+ ---
+ > exit(2); /* error */
+ > break;
+ 457d456
+
+ In system(), add a test for the status code
+ returned by LIB$SPAWN; for the MAKE utility, this
+ allows recognition of errors returned from a
+ compilation.
+
+ < int stat;
+ 463,464c462
+ < return ((LIB$SPAWN(&t,0,0,0,0,0,&stat) == SS$_NORMAL)
+ < && ((stat & 1) > 0)) ? 0 : 127;
+ ---
+ > return (LIB$SPAWN(&t) == SS$_NORMAL) ? 0 : 127;
+
+
+[20-Jul-87]
+ Updated cross-referencing awk scripts for use on
+ Sun OS 3.3 using standard cxref utility, replaced
+ old x*.awk by xref, xref1.awk, xref2.awk, and
+ xref3.awk, and replaced dvi.lrf and dvi.rby by
+ dvi.xrf.
+
+
+[20-Jul-87] {Thanks to Eric M. Carroll (Eric.M.Carroll@uunet.uu.net)}
+ In dvialw.c, getlogin() can return a NULL
+ pointer, so we need to guard against that.
+ Change
+
+ (void)fprintf(plotfp,"%%%%Creator: %s and ",getlogin());
+ to
+ (void)fprintf(plotfp,"%%%%Creator: %s and ",
+ (getlogin() == (char*)NULL) ? "" : getlogin());
+
+
+[08-Jul-87]
+ Update makefile.* to reflect new dvil3p, and
+ remove obsolete makefile.eun (for Eunice).
+
+
+[08-Jul-87]
+ Add symbol DECLN03PLUS and change SUBPATH for
+ Unix from /usr/lib/tex/inputs/ to
+ /usr/lib/tex/macros to match Washington TeX
+ distribution.
+
+
+[08-Jul-87]
+ In gblprocs.h, add OS_VAXVMS to the list of hosts
+ where sprintf() is not declared (because it is in
+ system include files).
+
+
+[08-Jul-87]
+ Change type of main() from void to int in
+ gblprocs.h and main.h to bring them into
+ conformance with the draft ANSI C Standard.
+
+
+[08-Jul-87]
+ In fontfile.h, changed VMS section to allow for
+ the possibility that TEXFONTS is a logical name
+ list (thanks for John Sauter for this).
+
+
+[08-Jul-87] {Thanks to John Sauter (Sauter@dssdev.dec.com)}
+ Add dvil3p.c for DEC LN03+ printer.
+
+
+[08-Jul-87]
+ In dvil75.c in prtbmap(), change OUTC('-') to
+ OUTS("-\n") so as to avoid long output lines.
+
+-------
diff --git a/dviware/beebe/updates/00mail.11 b/dviware/beebe/updates/00mail.11
new file mode 100644
index 0000000000..986474d765
--- /dev/null
+++ b/dviware/beebe/updates/00mail.11
@@ -0,0 +1,119 @@
+20-Aug-87 17:14:51-MDT,4764;000000000001
+Date: Thu 20 Aug 87 17:14:51-MDT
+From: "Nelson H.F. Beebe" <Beebe@SCIENCE.UTAH.EDU>
+Subject: DVI driver family update #11
+To: beebe@SCIENCE.UTAH.EDU, "DVI mailing list": ;
+cc: "new addresses": ;
+X-US-Mail: "Center for Scientific Computation, South Physics, University of Utah, Salt Lake City, UT 84112"
+X-Telephone: (801) 581-5254
+Message-ID: <12328099812.15.BEEBE@SCIENCE.UTAH.EDU>
+
+ DVI Driver Family Update #11
+ [20-Aug-87]
+
+[[===========================================================]]
+[[ This issue has nothing to do with the DVI driver family ]]
+[[ directly; it is primarily for the benefit of the many VAX ]]
+[[ VMS folks on the mailing list. ]]
+[[===========================================================]]
+
+Many VAX VMS sites have asked about printer spoolers for
+PostScript devices. Newsletter #10 described how to set up
+a spooler suitable for a HP LaserJet (or any similar printer
+which primarily needs XON/XOFF flow control support).
+
+PostScript printers are more difficult, because they are
+rather chatty. My LW78 works under TOPS-20, and
+modifications for Unix have been made at a user site which
+has promised to supply me with the changes; as far as I
+know, no one has attempted to adapt it to VAX VMS. In the
+meantime, the following news item which appeared on the
+INFO-VAX bulletin board this morning promises some good
+news.
+
+Besides this one, there is another from Clarkson University,
+but it is only available to those with Internet ANONYMOUS
+FTP capability. Both postings are reproduced below:
+
+25-Jun-87 21:19:20-MDT,987;000000000000
+Return-Path: <news@cs.utah.edu>
+Received: from cs.utah.edu by SCIENCE.UTAH.EDU with TCP; Thu 25 Jun 87 21:19:15-MDT
+Received: by cs.utah.edu (5.54/utah-1.0)
+ id AA22035; Thu, 25 Jun 87 21:21:34 MDT
+From: news@cs.utah.edu (Netnews Owner)
+Reply-To: ABSTINE%clvms.BITNET@CC.UTAH.EDU (AB Stine)
+To: comp-os-vms@cs.utah.edu
+Subject: PostScript Print Symbiont
+Message-Id: <8706252022.AA25693@ucbvax.Berkeley.EDU>
+Date: 24 Jun 87 15:02:00 GMT
+Sender: daemon@ucbvax.berkeley.edu
+Distribution: world
+Organization: The ARPA Internet
+
+The PSPRINT package is now available via anonymous FTP from node
+CLUTX.Clarkson.EDU
+
+The files you will need are:
+
+pub/vms/FIX_SAVESET.EXE -- program to fix up saveset after loading it from FTP
+pub/vms/PSPRINT.SAV -- backup saveset of PSPRINT package
+
+You should load it in image mode (in TEK TCP, /TYPE=IMAGE). It is some 1.4MEG.
+If you have any problems or other questions, drop me a note.
+
+Art Stine
+ABStine@CLVMS.Clarkson.EDU
+
+19-Aug-87 22:39:43-MDT,2055;000000000000
+Return-Path: <news@cs.utah.edu>
+Received: from cs.utah.edu by SCIENCE.UTAH.EDU with TCP; Wed 19 Aug 87 22:39:41-MDT
+Received: by cs.utah.edu (5.54/utah-1.0)
+ id AA02007; Wed, 19 Aug 87 22:41:38 MDT
+From: news@cs.utah.edu (Netnews Owner)
+Reply-To: ccaw001@utadnx.cc.utexas.edu ("Rick Watson")
+To: comp-os-vms@cs.utah.edu
+Subject: laser symbiont
+Message-Id: <8708200037.AA00811@ucbvax.Berkeley.EDU>
+Date: 19 Aug 87 20:19:00 GMT
+Sender: daemon@ucbvax.berkeley.edu
+Distribution: world
+Organization: The ARPA Internet
+
+For the many of you that have been interested in a symbiont for
+PostScript printers, my user-written laser symbiont is available on the
+latest DECUS tape under [VAX87A.UTEXAS.LASER].
+
+LASER is a user-written print symbiont that is tailored specifically to
+the Apple LaserWriter.
+
+This version of the symbiont is in use at several sites, but should
+still be considered to be in "BETA" testing. It has only been tested
+with version 23 of the LaserWriter, but should work with later versions.
+
+The symbiont as distributed is configured to print normal text files in
+a variety of formats on the laser printer. Support is also included for
+printing PostScript files, MacPaint files, and Zeta plot files. See
+LASER.C for additional capabilities of the symbiont.
+
+It is also available for anonymous ftp from utadnx.cc.utexas.edu:
+
+LASER_BACKUP.BCK - A backup save set that should be transferred
+ in binary,record mode by a site running WIN/TCP.
+LASER_SHAR.COM - A self-unpacking DCL-archive file. (ASCII only)
+
+SPAN nodes may copy the files from UTSPAN::UTADNX""::[FAL]
+
+You only need one of the files, the backup save set has everything
+already built. (You'll need VAXC if you want to recompile.)
+
+Since this is already being distributed via DECUS, I am not going to
+try posting or mailing the sources.
+
+Rick Watson
+University of Texas Computation Center
+ arpa: ccaw001@utadnx.cc.utexas.edu
+ bitnet: ccaw001@utadnx
+ span: utspan::ccaw001
+ phone: 512/471-3241 512/471-8220
+------
+-------
diff --git a/dviware/beebe/updates/00mail.12 b/dviware/beebe/updates/00mail.12
new file mode 100644
index 0000000000..eb743c8377
--- /dev/null
+++ b/dviware/beebe/updates/00mail.12
@@ -0,0 +1,725 @@
+ DVI Driver Family Update #12
+ [28-Sep-87]
+
+This issue announces Version 2.09, some minor editorial changes,
+and fixes to three serious bugs, one of which affects only
+dvijep, another only dvialw, and the third, most of the
+dot-matrix printer drivers. The fixes are extracted from the
+00REVHST.TXT file, and I record below everything posted to it
+since Version 2.08 (20-Aug-87)
+
+I am pleased to announce that the Free Software Foundation GNU
+Project C compiler, gcc, now successfully compiles the entire DVI
+driver family, both with and without optimization, on the Sun
+workstation. gcc can be built to produce code for Motorola
+68000, 68010, and 68020 CPU's, and for the DEC VAX architecture.
+I have installed version 1.11 here, and applied two bug fixes
+supplied by Richard Stallman to correct problems in gcc that
+showed up during the installation and testing of gcc on the DVI
+driver family. This testing also revealed a bug in the driver
+family itself; the fix is documented below.
+
+gcc currently runs with the host (Sun or VAX) C library, and
+consequently produces code which is calling-sequence compatible
+with the native Unix cc compilers. Presumably a later release of
+gcc will include complete run-time libraries, since the goal of
+the GNU project is to produce a complete free-standing operating
+system that runs on multiple architectures, and is freely
+available in source form.
+
+gcc's command-line switches are a superset of cc's. An important
+virtue is that specification of the debug switch (-g) does not
+nullify the optimization switch (-O), which is one of the great
+flaws with the Sun compilers. Optimization is likely to exhibit
+compiler bugs, and it is convenient to be able to track these
+down with a source-level debugger that can still find variables
+and line numbers, instead of an assembly-level debugger that only
+knows about machine addresses. gcc also is current with the
+October 1986 draft of the ANSI C standard, including string
+concatenation ("foo" "bar" becomes "foobar"), preprocessor token
+squashing ('#define X(n) X##n' results in X(abc) expanding to
+Xabc), and function prototype declarations.
+
+SRI has just released Version 4 of the TOPS-20 KCC compiler.
+Like gcc, this too conforms to the draft ANSI standard, and to
+the second edition of S. Harbison and G. Steele, ``C -- A
+Reference Manual'', Prentice-Hall (1987). This version also
+finally implements ioctl.h and signal.h, and fills in
+miscellaneous other routines from the 4.2BSD Unix library that
+were missing in earlier KCC releases
+
+The value of early availability of ANSI conformant compilers is
+significant, in that it permits more extensive testing of
+software portability, and also exposes the code to the more
+rigorous cross-checking available via function argument prototype
+declarations, a new feature introduced by the ANSI C committee.
+Function prototypes were actually borrowed from B. Stroustrup's
+C++ language, which is currently implemented as a preprocessor
+whose output is fed to the C compiler.
+
+C's readiness to automatically coerce values in expressions,
+assignments, and function calls is sometimes convenient, but more
+often introduces subtle machine dependencies. The approach I
+have rigorously adhered to in the DVI family is to use typecasts
+to specify explicit coercion, but such rigor requires automated
+tools which can check for compliance.
+
+ANSI extensions to VAX VMS C have been reported by at least one
+site; we do not yet have the upgrade locally. Microsoft C
+Version 5.0 is due out in October 1987, and should be similarly
+enhanced (it already had function prototypes declarations in
+Version 4.0).
+
+Here now are the recent change log entries:
+
+[28-Sep-87] Updated all makefiles to include a generic target
+ dvi$(PGM) and an extra compilation flag value
+ XCFLAGS, so test versions can be constructed by a
+ command like "make PGM=foo XCFLAGS=-g dvifoo".
+
+[28-Sep-87] {Thanks to Ian Young (ian@latlog.uucp)}
+ At the end of readgf.h, newfont() is called
+ before the loop which retrieves character metrics
+ via chargf(). This is incorrect for HPJETPLUS,
+ where the newfont() code in dvijep.c uses some of
+ the metrics. For the other devices, newfont()
+ only sets values in the font character tables.
+ Therefore, move the newfont() call to AFTER the
+ loop, so that the code reads in readgf.H:
+
+ for (the_char = FIRSTPXLCHAR; the_char <= LASTPXLCHAR; the_char++)
+ { /* Get remaining character metrics, and ignore error returns for now. */
+ tcharptr = &(fontptr->ch[the_char]);
+ if (tcharptr->fontrp >= 0L)
+ (void)chargf(the_char,(void(*)())NULL);
+ }
+
+#if (BBNBITGRAPH | HPJETPLUS | POSTSCRIPT | IMPRESS | CANON_A2)
+ (void)newfont();
+#endif
+
+[28-Sep-87] On Unix systems, getlogin() returns (char*)NULL
+ if the process is not attached to a terminal, in
+ particular, if the process is attached to a
+ pseudo-terminal (pty), such as a window or an
+ editor shell buffer. The way to get the real
+ login name in these circumstances is to use
+ cuserid((char*)NULL) in place of getlogin(), and
+ I have according made that change in dvialw.c and
+ lptops.c, and added appropriate function
+ declarations in gblprocs.h.
+
+ This change affects only text output in a
+ PostScript comment. Both cuserid and getlogin
+ are defined in 4.2BSD Unix, AT&T SYS V Unix,
+ HPUX, KCC (version 4), and IEEE Posix (which
+ draft ANSI C follows). PCC and V7 Unix had only
+ getlogin. VAX VMS C has only cuserid. KCC
+ (version 3), Microsoft C, Lattice C, and Wizard C
+ have neither.
+
+[23-Sep-87] {Version 2.09 announcement}
+ Testing of the Free Software Foundation gcc
+ compiler has uncovered two bugs so far in the
+ compiler (they are being fixed rapidly). gcc
+ produces code for both VAX and Motorola
+ architectures, and is being used to develop the
+ GNU operating system. The testing also found a
+ serious bug in my code which unfortunately
+ impacts most of the DVI drivers, and can be the
+ cause of core dumps or other failures.
+
+ The value of XSIZE in dvi*.c is currently
+ computed as XDPI*XPSIZE, that is, the number of
+ dots across the page. Unfortunately, one or more
+ local arrays are later allocated and used with
+ the assumption that XSIZE is a multiple of the
+ machine word size, HOST_WORD_SIZE, and in dvijet,
+ it was assumed to be a multiple of
+ 2*HOST_WORD_SIZE.
+
+ This bug was never caught on the DEC-20, because
+ there stacks grow upward, so beyond-bounds
+ references to stack arrays may just be writing
+ into unused memory. However, on the VAX, Intel
+ iAPX, and Motorola architectures, stacks grow
+ downward, and such references can wipe out the
+ call history, precipitating at best an address
+ exception or illegal instruction violation when
+ the return instruction is executed. This would
+ only happen if text was set against the
+ right-hand side of the page, and since TeX
+ documents usually produce wide margins, this may
+ be unlikely to happen.
+
+ To avoid complex dimension computations, and
+ preserve uniformity of definition among the
+ family, XSIZE is now increased to a multiple of
+ 2*HOST_WORD_SIZE throughout. The fix is to
+ change
+
+#define XSIZE (XDPI*XPSIZE) /* number of horizontal dots */
+
+ to
+
+#define XSIZE (((XDPI*XPSIZE+2*HOST_WORD_SIZE-1)/\
+ (2*HOST_WORD_SIZE))*(2*HOST_WORD_SIZE))
+ /* number of horizontal dots; */
+ /* MUST BE multiple of */
+ /* 2*HOST_WORD_SIZE */
+
+ in all the dvi*.c files. I view this bug fix to
+ be important enough to warrant a version number
+ change, so the family is now at version 2.09.
+
+ The following Unix script can be used on Unix
+ systems to automate the patch:
+
+#!/bin/csh
+foreach f (dvi*.c)
+ echo $f
+ mv $f $f-old
+ sed -f bugfix.sed <$f-old >$f
+end
+
+ Here is bugfix.sed:
+s|"2.08|"2.09|
+s|(XDPI\*XPSIZE)[ ]*/\* number of horizontal dots \*/|(((XDPI*XPSIZE+2*HOST_WORD_SIZE-1)/\\\
+ (2*HOST_WORD_SIZE))*(2*HOST_WORD_SIZE))\
+ /* number of horizontal dots; */\
+ /* MUST BE multiple of */\
+ /* 2*HOST_WORD_SIZE */|
+
+[23-Sep-87] In openfont.h, nopen is incremented when the
+ requested font is not found in the list of
+ currently open files, but the code forgets to
+ decrement it if the request font never gets
+ successfully opened, when can happen if the font
+ file cannot be found, and no substitution font is
+ provided. Change the code about line 185 to
+ decrement nopen on open failure, so that it now
+ reads:
+
+ if (fontfp == (FILE*)NULL)
+ {
+ --nopen; /* don't count this failed open */
+ (void)sprintf(message,"Font file [%s [mag %d]] could not be \
+
+
+[18-Sep-87] {Thanks to Mic Kaczmarczik (CC.KCACMARCZIK@A20.CC.UTEXAS.EDU)}
+ When dvialw.ps is modified to select LANDSCAPE
+ mode instead of NOTE (portrait), the output is
+ positioned incorrectly, and character bitmaps
+ look somewhat raggged. The former is due to a
+ missing translation command, and the latter to
+ tiny non-zero transformation matrix elements
+ which introduce computed coordinates which are in
+ error by one pixel. I have also taken the
+ liberty of installing a fix for the fact that
+ NOTE is not defined on non-Apple PostScript
+ printers. It should no longer be necessary to
+ edit dvialw.ps for Texas Instruments, QMS, et al
+ PostScript printers.
+
+ There is one problem with this change, and that
+ is that the SNAP call in the CharBuilder routine
+ must now be executed for each character set on
+ the page, so the output may prove to be somewhat
+ slower. To check this, I downloaded dvialw.ps to
+ our new Apple LaserWriter Plus, then executed
+
+ TeXdict begin
+ usertime 10000 {0 0 SNAP pop pop} repeat usertime
+ exch sub pstack
+
+ which results in a time of 70844 msec for 10000
+ calls, or an extra overhead of 7 msec per
+ character. Repeating the experiment using an
+ empty procedure body gives a loop overhead time
+ of 0.2 msec. With an average of 3000 characters
+ set per page, this amounts to 21 sec per page,
+ which is definitely not negligible. You may
+ therefore wish to leave the SNAP call out of a
+ version of dvialw.ps that is used only for
+ portrait orientation output.
+
+ Similar timing loops can be used to reveal an
+ average execution time of 1 msec for any
+ arithmetic operation (+-/*); PostScript
+ interpreters badly need hardware floating-point
+ support! There is a repeatable difference of
+ about 10% increase in speed when operands are
+ floating-point instead of integer values. dvialw
+ could be changed to write floating-point values
+ instead of integer ones, with a tradeoff of
+ slightly increased output file size to be
+ balanced against slightly faster arithmetic.
+
+ At the same time, I increased XPSIZE to 14 in
+ dvialw.c so that landscape mode output is not
+ clipped. Future work should introduce a general
+ flexible solution to the problem of paper size
+ specification for all of the drivers.
+
+ Here is a context difference which records the
+ changes. Additions are flagged with a "+" in the
+ first column, and changes with a "!", with the
+ old code first, and the new second.
+
+*** dvialw.ps-old Wed Jul 29 14:35:41 1987
+--- dvialw.ps Fri Sep 18 17:48:10 1987
+***************
+*** 1,3 ****
+--- 1,10 ----
++ % <BEEBE.TEX.DVI>DVIALW.PS.17, 18-Sep-87 17:48:04, Edit by BEEBE
++ % Add test for note paper and if unknown, use letter paper instead.
++ % Non-Apple PostScript implementations do not know about note paper
++ % but its use on the Apple LaserWriter gains 92K of virtual memory
++ % <BEEBE.TEX.DVI>DVIALW.PS.16, 18-Sep-87 15:50:52, Edit by BEEBE
++ % Modify coordinate computations to remove round-off errors
++ % in landscape mode, and correct landscape page origin
+ % <BEEBE.TEX.DVI>DVIALW.PS.14, 22-Jun-87 09:55:05, Edit by BEEBE
+ % Add missing "0 900 translate Mtrx currentmatrix pop" to /LEGAL
+ % <BEEBE.TEX.DVI>DVIALW.PS.13, 7-Jan-87 17:38:51, Edit by BEEBE
+***************
+*** 110,116 ****
+ /BOJ
+ {
+ 72 Resolution div 72 Resolution div scale
+! NOTE % default page format
+ } bdf
+
+ % BOP -- beginning of page
+--- 117,126 ----
+ /BOJ
+ {
+ 72 Resolution div 72 Resolution div scale
+! userdict /note known
+! {NOTE} % default page format for ALW
+! {LETTER} % default page format for others
+! ifelse
+ } bdf
+
+ % BOP -- beginning of page
+***************
+*** 146,151 ****
+--- 156,162 ----
+ ch-xoff neg ch-yoff ch-height sub
+ ch-width ch-xoff sub ch-yoff
+ setcachedevice
++ 0 0 SNAP translate
+ ch-width ch-height true [ 1 0 0 -1 ch-xoff ch-yoff ]
+ {ch-image} imagemask
+ } if
+***************
+*** 185,190 ****
+--- 196,202 ----
+ 72 Resolution div dup scale
+ 0 3300 translate
+ -90 rotate
++ 0 -750 translate
+ Mtrx currentmatrix pop
+ } bdf
+
+***************
+*** 271,276 ****
+--- 283,292 ----
+ % SF -- set new font at scale nnn (nnn = 1 normally; 2 gives double size chars)
+ % Usage -- nnn /fontname SF
+ /SF {findfont exch scalefont setfont} bdf() pop
++
++ % SNAP -- convert coordinates to integer device coordinates and back again
++ % Usage -- xxx yyy SNAP (leave xxx' yyy' on stack)
++ /SNAP {transform 2 {floor 0.5 add exch} repeat itransform} bdf
+
+ % T -- move absolute horizontally and show string, updating horizontal position
+ % to new endpt
+
+
+[08-Sep-87]
+ In lptops.c, change
+ OUTSTR(getlogin());
+ to
+ if (getlogin() != (char*)NULL)
+ OUTSTR(getlogin());
+ because getlogin() can sometimes return a null
+ pointer, instead of a null string.
+
+[31-Aug-87] {Thanks to HUXTABLE@UKANVAX.BITNET}
+ In gblprocs.h in the ANSI type declarations for
+ dvifile and main, change "char *[0]" to "char
+ *[]". The "[0]" is an odd production of
+ Microsoft C which was used to prepare the type
+ declarations at compile time. It sneaked through
+ the editing (it is not needed for Microsoft C to
+ compile these). VAX VMS C version 2.3-024 now
+ supports ANSI function declaration prototypes; I
+ don't have it up yet.
+28-Sep-87 19:15:06-MDT,17660;000000000000
+Date: Mon 28 Sep 87 19:15:06-MDT
+From: "Nelson H.F. Beebe" <Beebe@SCIENCE.UTAH.EDU>
+Subject: DVI driver family update #12
+To: "DVI mailing list": ;
+cc: BEEBE@SCIENCE.UTAH.EDU
+X-US-Mail: "Center for Scientific Computation, South Physics, University of Utah, Salt Lake City, UT 84112"
+X-Telephone: (801) 581-5254
+Message-ID: <12338345320.27.BEEBE@SCIENCE.UTAH.EDU>
+
+ DVI Driver Family Update #12
+ [28-Sep-87]
+
+This issue announces Version 2.09, some minor editorial changes,
+and fixes to three serious bugs, one of which affects only
+dvijep, another only dvialw, and the third, most of the
+dot-matrix printer drivers. The fixes are extracted from the
+00REVHST.TXT file, and I record below everything posted to it
+since Version 2.08 (20-Aug-87)
+
+I am pleased to announce that the Free Software Foundation GNU
+Project C compiler, gcc, now successfully compiles the entire DVI
+driver family, both with and without optimization, on the Sun
+workstation. gcc can be built to produce code for Motorola
+68000, 68010, and 68020 CPU's, and for the DEC VAX architecture.
+I have installed version 1.11 here, and applied two bug fixes
+supplied by Richard Stallman to correct problems in gcc that
+showed up during the installation and testing of gcc on the DVI
+driver family. This testing also revealed a bug in the driver
+family itself; the fix is documented below.
+
+gcc currently runs with the host (Sun or VAX) C library, and
+consequently produces code which is calling-sequence compatible
+with the native Unix cc compilers. Presumably a later release of
+gcc will include complete run-time libraries, since the goal of
+the GNU project is to produce a complete free-standing operating
+system that runs on multiple architectures, and is freely
+available in source form.
+
+gcc's command-line switches are a superset of cc's. An important
+virtue is that specification of the debug switch (-g) does not
+nullify the optimization switch (-O), which is one of the great
+flaws with the Sun compilers. Optimization is likely to exhibit
+compiler bugs, and it is convenient to be able to track these
+down with a source-level debugger that can still find variables
+and line numbers, instead of an assembly-level debugger that only
+knows about machine addresses. gcc also is current with the
+October 1986 draft of the ANSI C standard, including string
+concatenation ("foo" "bar" becomes "foobar"), preprocessor token
+squashing ('#define X(n) X##n' results in X(abc) expanding to
+Xabc), and function prototype declarations.
+
+SRI has just released Version 4 of the TOPS-20 KCC compiler.
+Like gcc, this too conforms to the draft ANSI standard, and to
+the second edition of S. Harbison and G. Steele, ``C -- A
+Reference Manual'', Prentice-Hall (1987). This version also
+finally implements ioctl.h and signal.h, and fills in
+miscellaneous other routines from the 4.2BSD Unix library that
+were missing in earlier KCC releases
+
+The value of early availability of ANSI conformant compilers is
+significant, in that it permits more extensive testing of
+software portability, and also exposes the code to the more
+rigorous cross-checking available via function argument prototype
+declarations, a new feature introduced by the ANSI C committee.
+Function prototypes were actually borrowed from B. Stroustrup's
+C++ language, which is currently implemented as a preprocessor
+whose output is fed to the C compiler.
+
+C's readiness to automatically coerce values in expressions,
+assignments, and function calls is sometimes convenient, but more
+often introduces subtle machine dependencies. The approach I
+have rigorously adhered to in the DVI family is to use typecasts
+to specify explicit coercion, but such rigor requires automated
+tools which can check for compliance.
+
+ANSI extensions to VAX VMS C have been reported by at least one
+site; we do not yet have the upgrade locally. Microsoft C
+Version 5.0 is due out in October 1987, and should be similarly
+enhanced (it already had function prototypes declarations in
+Version 4.0).
+
+Here now are the recent change log entries:
+
+[28-Sep-87] Updated all makefiles to include a generic target
+ dvi$(PGM) and an extra compilation flag value
+ XCFLAGS, so test versions can be constructed by a
+ command like "make PGM=foo XCFLAGS=-g dvifoo".
+
+[28-Sep-87] {Thanks to Ian Young (ian@latlog.uucp)}
+ At the end of readgf.h, newfont() is called
+ before the loop which retrieves character metrics
+ via chargf(). This is incorrect for HPJETPLUS,
+ where the newfont() code in dvijep.c uses some of
+ the metrics. For the other devices, newfont()
+ only sets values in the font character tables.
+ Therefore, move the newfont() call to AFTER the
+ loop, so that the code reads in readgf.H:
+
+ for (the_char = FIRSTPXLCHAR; the_char <= LASTPXLCHAR; the_char++)
+ { /* Get remaining character metrics, and ignore error returns for now. */
+ tcharptr = &(fontptr->ch[the_char]);
+ if (tcharptr->fontrp >= 0L)
+ (void)chargf(the_char,(void(*)())NULL);
+ }
+
+#if (BBNBITGRAPH | HPJETPLUS | POSTSCRIPT | IMPRESS | CANON_A2)
+ (void)newfont();
+#endif
+
+[28-Sep-87] On Unix systems, getlogin() returns (char*)NULL
+ if the process is not attached to a terminal, in
+ particular, if the process is attached to a
+ pseudo-terminal (pty), such as a window or an
+ editor shell buffer. The way to get the real
+ login name in these circumstances is to use
+ cuserid((char*)NULL) in place of getlogin(), and
+ I have according made that change in dvialw.c and
+ lptops.c, and added appropriate function
+ declarations in gblprocs.h.
+
+ This change affects only text output in a
+ PostScript comment. Both cuserid and getlogin
+ are defined in 4.2BSD Unix, AT&T SYS V Unix,
+ HPUX, KCC (version 4), and IEEE Posix (which
+ draft ANSI C follows). PCC and V7 Unix had only
+ getlogin. VAX VMS C has only cuserid. KCC
+ (version 3), Microsoft C, Lattice C, and Wizard C
+ have neither.
+
+[23-Sep-87] {Version 2.09 announcement}
+ Testing of the Free Software Foundation gcc
+ compiler has uncovered two bugs so far in the
+ compiler (they are being fixed rapidly). gcc
+ produces code for both VAX and Motorola
+ architectures, and is being used to develop the
+ GNU operating system. The testing also found a
+ serious bug in my code which unfortunately
+ impacts most of the DVI drivers, and can be the
+ cause of core dumps or other failures.
+
+ The value of XSIZE in dvi*.c is currently
+ computed as XDPI*XPSIZE, that is, the number of
+ dots across the page. Unfortunately, one or more
+ local arrays are later allocated and used with
+ the assumption that XSIZE is a multiple of the
+ machine word size, HOST_WORD_SIZE, and in dvijet,
+ it was assumed to be a multiple of
+ 2*HOST_WORD_SIZE.
+
+ This bug was never caught on the DEC-20, because
+ there stacks grow upward, so beyond-bounds
+ references to stack arrays may just be writing
+ into unused memory. However, on the VAX, Intel
+ iAPX, and Motorola architectures, stacks grow
+ downward, and such references can wipe out the
+ call history, precipitating at best an address
+ exception or illegal instruction violation when
+ the return instruction is executed. This would
+ only happen if text was set against the
+ right-hand side of the page, and since TeX
+ documents usually produce wide margins, this may
+ be unlikely to happen.
+
+ To avoid complex dimension computations, and
+ preserve uniformity of definition among the
+ family, XSIZE is now increased to a multiple of
+ 2*HOST_WORD_SIZE throughout. The fix is to
+ change
+
+#define XSIZE (XDPI*XPSIZE) /* number of horizontal dots */
+
+ to
+
+#define XSIZE (((XDPI*XPSIZE+2*HOST_WORD_SIZE-1)/\
+ (2*HOST_WORD_SIZE))*(2*HOST_WORD_SIZE))
+ /* number of horizontal dots; */
+ /* MUST BE multiple of */
+ /* 2*HOST_WORD_SIZE */
+
+ in all the dvi*.c files. I view this bug fix to
+ be important enough to warrant a version number
+ change, so the family is now at version 2.09.
+
+ The following Unix script can be used on Unix
+ systems to automate the patch:
+
+#!/bin/csh
+foreach f (dvi*.c)
+ echo $f
+ mv $f $f-old
+ sed -f bugfix.sed <$f-old >$f
+end
+
+ Here is bugfix.sed:
+s|"2.08|"2.09|
+s|(XDPI\*XPSIZE)[ ]*/\* number of horizontal dots \*/|(((XDPI*XPSIZE+2*HOST_WORD_SIZE-1)/\\\
+ (2*HOST_WORD_SIZE))*(2*HOST_WORD_SIZE))\
+ /* number of horizontal dots; */\
+ /* MUST BE multiple of */\
+ /* 2*HOST_WORD_SIZE */|
+
+[23-Sep-87] In openfont.h, nopen is incremented when the
+ requested font is not found in the list of
+ currently open files, but the code forgets to
+ decrement it if the request font never gets
+ successfully opened, when can happen if the font
+ file cannot be found, and no substitution font is
+ provided. Change the code about line 185 to
+ decrement nopen on open failure, so that it now
+ reads:
+
+ if (fontfp == (FILE*)NULL)
+ {
+ --nopen; /* don't count this failed open */
+ (void)sprintf(message,"Font file [%s [mag %d]] could not be \
+
+
+[18-Sep-87] {Thanks to Mic Kaczmarczik (CC.KCACMARCZIK@A20.CC.UTEXAS.EDU)}
+ When dvialw.ps is modified to select LANDSCAPE
+ mode instead of NOTE (portrait), the output is
+ positioned incorrectly, and character bitmaps
+ look somewhat raggged. The former is due to a
+ missing translation command, and the latter to
+ tiny non-zero transformation matrix elements
+ which introduce computed coordinates which are in
+ error by one pixel. I have also taken the
+ liberty of installing a fix for the fact that
+ NOTE is not defined on non-Apple PostScript
+ printers. It should no longer be necessary to
+ edit dvialw.ps for Texas Instruments, QMS, et al
+ PostScript printers.
+
+ There is one problem with this change, and that
+ is that the SNAP call in the CharBuilder routine
+ must now be executed for each character set on
+ the page, so the output may prove to be somewhat
+ slower. To check this, I downloaded dvialw.ps to
+ our new Apple LaserWriter Plus, then executed
+
+ TeXdict begin
+ usertime 10000 {0 0 SNAP pop pop} repeat usertime
+ exch sub pstack
+
+ which results in a time of 70844 msec for 10000
+ calls, or an extra overhead of 7 msec per
+ character. Repeating the experiment using an
+ empty procedure body gives a loop overhead time
+ of 0.2 msec. With an average of 3000 characters
+ set per page, this amounts to 21 sec per page,
+ which is definitely not negligible. You may
+ therefore wish to leave the SNAP call out of a
+ version of dvialw.ps that is used only for
+ portrait orientation output.
+
+ Similar timing loops can be used to reveal an
+ average execution time of 1 msec for any
+ arithmetic operation (+-/*); PostScript
+ interpreters badly need hardware floating-point
+ support! There is a repeatable difference of
+ about 10% increase in speed when operands are
+ floating-point instead of integer values. dvialw
+ could be changed to write floating-point values
+ instead of integer ones, with a tradeoff of
+ slightly increased output file size to be
+ balanced against slightly faster arithmetic.
+
+ At the same time, I increased XPSIZE to 14 in
+ dvialw.c so that landscape mode output is not
+ clipped. Future work should introduce a general
+ flexible solution to the problem of paper size
+ specification for all of the drivers.
+
+ Here is a context difference which records the
+ changes. Additions are flagged with a "+" in the
+ first column, and changes with a "!", with the
+ old code first, and the new second.
+
+*** dvialw.ps-old Wed Jul 29 14:35:41 1987
+--- dvialw.ps Fri Sep 18 17:48:10 1987
+***************
+*** 1,3 ****
+--- 1,10 ----
++ % <BEEBE.TEX.DVI>DVIALW.PS.17, 18-Sep-87 17:48:04, Edit by BEEBE
++ % Add test for note paper and if unknown, use letter paper instead.
++ % Non-Apple PostScript implementations do not know about note paper
++ % but its use on the Apple LaserWriter gains 92K of virtual memory
++ % <BEEBE.TEX.DVI>DVIALW.PS.16, 18-Sep-87 15:50:52, Edit by BEEBE
++ % Modify coordinate computations to remove round-off errors
++ % in landscape mode, and correct landscape page origin
+ % <BEEBE.TEX.DVI>DVIALW.PS.14, 22-Jun-87 09:55:05, Edit by BEEBE
+ % Add missing "0 900 translate Mtrx currentmatrix pop" to /LEGAL
+ % <BEEBE.TEX.DVI>DVIALW.PS.13, 7-Jan-87 17:38:51, Edit by BEEBE
+***************
+*** 110,116 ****
+ /BOJ
+ {
+ 72 Resolution div 72 Resolution div scale
+! NOTE % default page format
+ } bdf
+
+ % BOP -- beginning of page
+--- 117,126 ----
+ /BOJ
+ {
+ 72 Resolution div 72 Resolution div scale
+! userdict /note known
+! {NOTE} % default page format for ALW
+! {LETTER} % default page format for others
+! ifelse
+ } bdf
+
+ % BOP -- beginning of page
+***************
+*** 146,151 ****
+--- 156,162 ----
+ ch-xoff neg ch-yoff ch-height sub
+ ch-width ch-xoff sub ch-yoff
+ setcachedevice
++ 0 0 SNAP translate
+ ch-width ch-height true [ 1 0 0 -1 ch-xoff ch-yoff ]
+ {ch-image} imagemask
+ } if
+***************
+*** 185,190 ****
+--- 196,202 ----
+ 72 Resolution div dup scale
+ 0 3300 translate
+ -90 rotate
++ 0 -750 translate
+ Mtrx currentmatrix pop
+ } bdf
+
+***************
+*** 271,276 ****
+--- 283,292 ----
+ % SF -- set new font at scale nnn (nnn = 1 normally; 2 gives double size chars)
+ % Usage -- nnn /fontname SF
+ /SF {findfont exch scalefont setfont} bdf() pop
++
++ % SNAP -- convert coordinates to integer device coordinates and back again
++ % Usage -- xxx yyy SNAP (leave xxx' yyy' on stack)
++ /SNAP {transform 2 {floor 0.5 add exch} repeat itransform} bdf
+
+ % T -- move absolute horizontally and show string, updating horizontal position
+ % to new endpt
+
+
+[08-Sep-87]
+ In lptops.c, change
+ OUTSTR(getlogin());
+ to
+ if (getlogin() != (char*)NULL)
+ OUTSTR(getlogin());
+ because getlogin() can sometimes return a null
+ pointer, instead of a null string.
+
+[31-Aug-87] {Thanks to HUXTABLE@UKANVAX.BITNET}
+ In gblprocs.h in the ANSI type declarations for
+ dvifile and main, change "char *[0]" to "char
+ *[]". The "[0]" is an odd production of
+ Microsoft C which was used to prepare the type
+ declarations at compile time. It sneaked through
+ the editing (it is not needed for Microsoft C to
+ compile these). VAX VMS C version 2.3-024 now
+ supports ANSI function declaration prototypes; I
+ don't have it up yet.
+-------
diff --git a/dviware/beebe/updates/00mail.13 b/dviware/beebe/updates/00mail.13
new file mode 100644
index 0000000000..eecc1b6fcc
--- /dev/null
+++ b/dviware/beebe/updates/00mail.13
@@ -0,0 +1,670 @@
+ 1-Oct-87 14:06:14-MDT,23751;000000000001
+Date: Thu 1 Oct 87 14:06:14-MDT
+From: "Nelson H.F. Beebe" <Beebe@SCIENCE.UTAH.EDU>
+Subject: DVI driver family update #13
+To: "DVI mailing list": ;
+cc: BEEBE@SCIENCE.UTAH.EDU
+X-US-Mail: "Center for Scientific Computation, South Physics, University of Utah, Salt Lake City, UT 84112"
+X-Telephone: (801) 581-5254
+Message-ID: <12339075525.13.BEEBE@SCIENCE.UTAH.EDU>
+
+ DVI Driver Family Update #13
+ [01-Oct-87]
+
+This issue contains a preliminary Unix man page in troff/nroff
+format which may be useful at some sites. I have tested it with
+both screen and PostScript output, and with checknr, on a Sun
+workstation, and followed the guidelines in the Sun manuals on
+writing man pages, particularly with respect to font choices.
+
+There are sufficient differences in formatting from TeX's
+approach that I think I will continue to maintain dviman.ltx
+(which has similar contents), rather than just applying tr2tex to
+dvi.1l. As an example, troff does not normally provide
+typewriter fonts for program examples; combinations of bold and
+italic are used. Also, troff seems not to have a proper notion
+of ``quotes''. My AT&T Unix Programmers Manual -- Document
+Preparation, Volume 4, Holt, Rinehart and Winston (1986) lacks an
+index (a pox upon them), so I could easily have overlooked
+something.
+
+I've written several shorter man pages, but this one represents
+my biggest troff effort to date (and considering the amount of
+ugly how-to-do-it formatting required, may possibly be my last).
+Comments are encouraged.
+
+There are two changes noted in the man page file that are not yet
+reflected in the DVI software outside of my local installation.
+
+ The -d (debug) option can now be specified more than once, so
+ you need not add values. Originally I thought it might be
+ useful to have -d0 cancel a previously-typed debug request,
+ but this appears less useful than the new alternative.
+
+ The -z option will be available for 4.xBSD Unix systems (or
+ any that have an ioctl(fildes,TIOCSTI,*character) call) for
+ all devices.
+
+dviman.ltx will be brought up-to-date next.
+
+I am also trying to work my way through a file of mail with
+suggestions for the drivers, which will probably result in
+Version 2.10 being announced next week. To those whom I have not
+answered, my apologies; your comments are welcome and receiving
+consideration. I get 800Kb of email a month, so it is not always
+possible to respond in detail to everyone. I am also holding a
+couple of dozen orders for tape and floppy distributions until
+2.10 is ready.
+
+Here is dvi.1l; install it in /usr/local/man/man1, or wherever
+you usually put local additions.
+------------------------------------------------------------------------
+.TH dvi 1L "01 October 1987"
+
+.SH NAME
+
+dvixxx \- TeX DVI to device xxx translator family
+
+.SH SYNOPSIS
+
+\fBdvixxx\fP
+[\fB-a\fP]
+[\fB-b\fP]
+[\fB-c#\fP]
+[\fB-d#\fP]
+[\fB-e\fP\fIVAR=value\fP]
+[\fB-f\fP\fIfontsubfile\fP]
+.if n .ti +0.5i
+[\fB-l\fP]
+[\fB-m#\fP]
+[\fB-o#\fP]
+[\fB-o#:#\fP]
+[\fB-o#:#:#\fP]
+[\fB-p\fP]
+[\fB-q\fP]
+.ti +0.5i
+[\fB-r#\fP]
+[\fB-s#\fP]
+[\fB-v\fP]
+[\fB-x#\fP\fIunits\fP]
+[\fB-y#\fP\fIunits\fP]
+[\fB-z\fP]
+.if n .ti +0.5i
+\fBdvifile1\fP
+[\fB dvifile2\fP] .\|.\|.
+
+\fIxxx\fP\fR = output device identifier suffix (see below)\fP
+
+.SH DESCRIPTION
+
+This is a public-domain family of TeX DVI translators. They
+all have a common command-line interface, and are based on a
+shared set of source files.
+
+For all except \fIdvibit\fP, which is intended for interactive display,
+the output file will be given the name of the \fI.dvi\fP file, but with
+suffix \fI.dvi-xxx\fP, where \fIxxx\fP is the three-character mnemonic
+for the translator program. If long filenames are not supported,
+then \fI.xxx\fP is used. For \fIdvibit\fP, output is on \fIstdout\fP,
+which defaults to the terminal; it may be redirected in the usual Unix
+fashion by \fI>filename\fP on the command line (e.g. \fIdvibit foo
+>foo.out\fP).
+
+.SH DEVICES SUPPORTED
+
+As each \fI.dvi\fP file is processed, a list of errors is printed
+on the standard error unit, \fIstderr\fP; this list is also saved
+in a file with suffix \fI.dvi-err\fP (or \fI.err\fP, if long filenames
+are not supported). This file is not created if there are no errors. As
+each page is printed, the physical page number and the TeX page
+number(s) are printed without a following character return; after the
+last page, the string "[OK]" is printed, followed by a newline. This
+gives a convenient progress report to the terminal. If it is not wanted,
+then the error output can be redirected into a file (possibly the null
+device) (e.g. \fIdvixxx foo &foo.err\fP), or the \fB\-q\fP (quiet)
+option can be given to suppress it.
+
+The available translators are as follows:
+.TP \w'dvityp_or_dvitype'u+2n
+\fIdvialw\fP
+PostScript (Apple LaserWriter)
+.TP
+\fIdvibit\fP
+Version 3.10 BBN BitGraph terminal
+.TP
+\fIdvican\fP
+Canon LBP-8 A2 laser printer
+.TP
+\fIdvigd\fP
+Golden Dawn Golden Laser 100 printer
+.TP
+\fIdviimp\fP
+Imagen imPRESS-language laser printer family
+.TP
+\fIdvijep\fP
+Hewlett-Packard LaserJet Plus
+.TP
+\fIdvijet\fP
+Hewlett-Packard LaserJet
+.TP
+\fIdvil3p\fP
+DEC LN03 Plus laser printer
+.TP
+\fIdvil75\fP
+DEC LA75 144 dpi printer
+.TP
+\fIdvim72\fP
+Apple Imagewriter 72 dpi printer
+.TP
+\fIdvimac\fP
+Apple Imagewriter 144 dpi printer
+.TP
+\fIdvimpi\fP
+MPI Sprinter 72 dpi printer
+.TP
+\fIdvio72\fP
+OKIDATA Pacemark 2410 72 dpi printer
+.TP
+\fIdvioki\fP
+OKIDATA Pacemark 2410 144 dpi printer
+.TP
+\fIdviprx\fP
+Printronix 60h x 72v dpi printer
+.TP
+\fIdvitos\fP
+Toshiba P-1351 180 dpi printer
+.TP
+\fIdvityp\fP or \fIdvitype\fP
+DVI Translator for human-readable output
+
+.SH OPTIONS
+
+The order of command options and DVI file names is \fInot\fP
+significant; all switch values apply to all DVI files. DVI files are
+processed in order from left to right.
+
+Letter case is \fIignored\fP) in option switches: \fB\-A\fP
+and \fB\-a\fP are equivalent.
+.TP
+.B \-a
+Implement virtual font caching, if possible.
+When a font file is opened, a buffer is allocated
+to contain the entire file, and the file is then
+read with one system call. This is important
+primarily on networked file systems, where the
+many random-access calls in the font file for
+small amounts of data entail substantial network
+overhead. With the entire file cached in local
+memory, this overhead is removed. The
+additional memory required for the font file
+buffers amounts to 100K to 200K bytes (assuming
+the compact \fI\.pk\fP font file format), which is
+not excessive. If memory cannot be allocated for
+a font file, then normal buffering of small
+blocks is used. A trace option (\fB\-d64\fP) is
+provided to monitor the font caching; see below.
+.TP
+.B \-b
+Backwards order printing from the default. For example, laser printers
+using the Canon LBP-CX print engine normally receive pages in
+reverse order because they stack printed side up. Some have page
+handling mechanisms that stack them face down, and in such a case
+\fB\-b\fP will ensure that they come out in order 1, 2, .\|.\|.
+instead of n, n-1, n-2, .\|.\|.
+.TP
+.B \-c#
+Print # copies of each output page. Page copies
+are printed consecutively; this does
+\fInot\fP
+give multiple collated copies of the entire job.
+.TP
+.B \-d#
+Produce debugging output on \fIstderr\fP if a non-zero value is given.
+Multiple \fB\-d\fP switches may be specified, and one may also add
+values of the following possible options to obtain the switch value:
+.RS
+.TP
+.I 1
+(dvijet only) print page bitmap in hexadecimal;
+.TP
+.I 2
+display page coordinates and metrics of
+each output character, and print each
+character bitmap in hexadecimal;
+.TP
+.I 4
+(dvijep only) display updated page
+coordinate of each character after each call
+to \fIfixpos()\fP;
+.TP
+.I 8
+print filename and open mode of
+each
+\fIsuccessful\fP
+file opening;
+.TP
+.I 16
+print filename and open mode of
+each
+\fIunsuccessful\fP
+file opening;
+.TP
+.I 32
+show discarded off-page text;
+.TP
+.I 64
+trace virtual font caching.
+.RE
+.PP
+.RS
+For example, \fB\-d24\fP will trace all attempted file openings.
+.RE
+.TP
+.B \-eVAR=value
+Define an environment variable on the command line (see the later
+section ENVIRONMENT VARIABLES). The acceptable values for
+\fIVAR\fP
+are
+\fIDVIHELP,\fP
+\fIFONTLIST,\fP
+\fITEXFONTS\fP,
+and
+\fITEXINPUTS\fP.
+Under normal use of the
+translators, these can be set by TOPS-20 and
+VAX VMS
+\fBdefine VAR: value\fP
+commands, or by Unix
+csh
+\fBsetenv VAR value\fP
+or sh
+\fBVAR=value\fP
+commands. When the
+translator is invoked by another program, such as
+a print spooler, on some systems it may not be
+possible to set a
+particular value of an environment variable for
+the subprocess, so this option gets around this
+limitation. On most Unix systems, it should
+be possible to use the call
+\fBsystem("VAR=value; dvixxx filename")\fP.
+.TP
+.B \-ffontsubfile
+Define an alternate font substitution file which
+is to be used instead of the default ones (see below).
+.TP
+.B \-l
+Inhibit logging.
+.TP
+.B \-m#
+Reset magnification to #. The default for low resolution printers is
+\fB\-m603,\fP corresponding to 1/1.2^5 magnification of 300-dot/inch
+fonts. By TeX conventions, magnification 1000 corresponds to a
+200-dot/inch output device. The default magnification is always
+adjusted according to the output device resolution in order to give a
+normal page size, so this parameter should rarely be required. Legal
+values are int((1000 or 1440 or 1500) x 1.2^(k/2) [k = -16 .\|.\|. 16];
+other values will be set to the nearest in this family. Not all fonts
+will be available in this wide range, and most installations will
+probably have only a half dozen or so magnifications.
+
+Magnification values less than 25 are taken to be a TeX magstep
+parameter which is applied to the standard magnification for that
+device. For example, \fB\-m-0.5\fP selects a smaller size, and
+\fB\-m2\fP selects a size 1.44 times larger than normal.
+.TP
+.B \-o# \fIor\fP \-o#:# \fIor\fP \-o#:#:#
+Specify a page number, or range of page numbers, to be selected for
+output. In the third form, the last number is the page number step
+size; it is normally 1. This option may be specified any number of
+times. If it is not specified, then all pages will be printed. Pages
+are numbered in order 1, 2, 3, .\|.\|. in the file, but any page number
+recorded by TeX on the printed page will in general be different.
+Negative page numbers count backward; \-1 is the last page in the
+document, \-2 the second last page, and so on.
+
+As pages are selected for printing, [#{#} will be printed on
+\fIstderr\fP, where the first # is the sequential page number in the
+file, and the second # is a string of values of the TeX counters,
+\\count0 through \\count9, separated by dots, with trailing zero
+counters dropped. \\count0 usually records the printed page number.
+When the page is completely output, a closing \fI]\fP will be printed on
+\fIstderr\fP. Any error messages from processing of that page will
+therefore occur between the square brackets. For example, \fB\-o1:3
+\-o12 \-o17:23 \-o\-3:\-1\fP would select pages 1, 2, 3, 12, 17, 18, 19,
+20, 21, 22, and 23, plus the last three pages.
+
+Pages are processed in the order found in the DVI file; there is
+intentionally no attempt made to sort them according to the \\count0
+values, since different macro packages may use this counter for
+different purposes, and in the case of floating tables and figures,
+the pages may not be in order anyway.
+
+Pages will always be printed in an order appropriate for the device so
+that the first document page occurs first face up in the document
+stack; the \fB\-b\fP option can be used to reverse this order. For
+example, some Hewlett-Packard LaserJet Plus printers are equipped with
+a page flipper which stacks output face down; for these, the \fB\-b\fP
+option will ensure that the pages come out in the expected order.
+
+Specification of a page number step size is useful for producing duplex
+(two-sided) printing. For example, with laser printers using the Canon
+LBP-CX engine, the first run could specify \fB\-o1:9999:2,\fP which
+would stack output face up, beginning with the last page, and ending
+with page 1 on top. The printed pages can then be reinserted in the
+input tray \fIface up\fP, page 1 on the top, exactly as they were found
+in the output tray, with the top of the page in the tray closest to the
+end which is inserted first into the printer. A second run with \fB\-b
+\-o2:9999:2\fP would then print pages 2, 4, .\|.\|., on the backs of
+pages 1, 3, .\|.\|.; note the \fB\-b\fP option to get backwards order on
+the second run.
+
+There is a bug in Microsoft C's \fIsscanf()\fP on the IBM PC; it does
+not correctly parse input on the format \fI"%d:%d:%d"\fP in
+\fIoption()\fP for the page number switch. It correctly returns the
+numbers, but instead of returning the number of such items parsed, it
+returns \-1, which should only happen if none are parsed. A work
+around seems to be to supply a trailing colon on the switch, so that
+you write \fB\-o17:\fP instead of \fB\-o17\fP.
+.TP
+.B \-p
+Inhibit font preloading. This may produce output a few seconds
+earlier when all pages are output, but should have negligible effect
+on the execution time, and consequently, should normally not be
+specified. When individual pages are being printed with the
+\fB\-o#\fP option, preloading is necessary (and will be forced) to
+ensure that all fonts are defined before they are referenced.
+.TP
+.B \-q
+Quiet mode. Status displays to \fIstderr\fP are suppressed, unless
+warning or error messages are issued. For interactive devices
+(dvibit), warning messages are suppressed.
+.TP
+.B \-r#
+(Device = HP LaserJet only). Specify the Laser Jet output resolution
+in dots per inch. \fI#\fP must be one of 75, 100, 150, or 300. The
+actual plot file is identical in each case; only the size on the
+output page is changed, because the resolution change is effected by
+printing 1 x 1, 2 x 2, 3 x 3, or 4 x 4 pixel blocks.
+.TP
+.B \-r
+(Device = Golden Laser 100 only). Select
+run-length encoding of the output file. This
+reduces disk space typically by 10% to 40%, but
+increases host CPU time for the preparation of
+the output file.
+.TP
+.B \-r
+(Device = Apple ImageWriter only). Select run-length
+encoding of the output file.
+.TP
+.B \-r
+(Device = Toshiba P-1351 only). Select
+run-length encoding of the output file. This
+reduces disk space typically by 10% to 40%, but
+increases host CPU time for the preparation of
+the output file, and because of poor logic in the
+printer, may double the print time! The print
+quality is also substantially worse, so this
+option is generally
+\fInot\fP
+recommended.
+.TP
+.B \-s#
+(Device = Apple LaserWriter only). Force
+characters larger than # pixels wide or high to
+be reloaded each time they are required. The
+Version 23.0 PostScript interpreter has a bug
+which manifests itself in fatal
+\fIVM error\fP
+messages when large characters are sent. A
+reasonable default value has been set for this
+which should normally avoid the problem.
+Specifying
+.B \-s0
+will cause reloading of
+every character each time it is used.
+.TP
+.B \-v
+(Device = Apple LaserWriter only). Force reloading of
+all required fonts at start of each page.
+.TP
+.B \-x#\fIunits\fP
+The \fB\-x\fP options specify the left margin of the TeX page on the
+output page in any of the indicated units. Letter case is not
+significant in the units field, which must \fInot\fP be separated from
+the number by any space. \fI#\fP may be fractional. For example,
+\fB\-x1.0in\fP, \fB\-x2.54cm\fP, \fB\-x72.27pt\fP, and \fB\-x6.0225pc\fP
+all specify a one-inch left margin. Negative values are permissible, and
+may be used to shift the output page left (possibly truncating it on the
+left) in order to display a wide TeX page.
+
+The \fIunits\fP field is mandatory, and may be one of
+.RS
+.TP
+.B bp
+big point (1in = 72bp)
+.TP
+.B cc
+cicero (1cc = 12dd)
+.TP
+.B cm
+centimeter (1in = 2.54cm)
+.TP
+.B dd
+didot point (1157dd = 1238pt)
+.TP
+.B in
+inch
+.TP
+.B mm
+millimeter (10mm = 1cm)
+.TP
+.B pc
+pica (1pc = 12pt)
+.TP
+.B pt
+point (72.27pt = 1in)
+.TP
+.B sp
+scaled point (65536sp = 1pt)
+.RE
+.TP
+.B \-y#\fIunits\fP
+The \fB\-y\fP options specify the top margin of the TeX page on the
+output page. Letter case is not significant in the units field, which
+must \fInot\fP be separated from the number by any space. # may be
+fractional. For example, \fB\-y1.0in\fP, \fB\-y2.54cm\fP,
+\fB\-y72.27pt\fP, and \fB\-y6.0225pc\fP all specify a one-inch top
+margin. Negative values are permissible, and may be used to shift the
+output page up (possibly truncating it on the top) in order to display a
+long TeX page.
+
+By decree of the Stanford TeX Project, the default TeX page origin
+is always 1 inch over and down from the top-left page corner, even
+when non-American paper sizes are used. This corresponds to the switch
+settings \fB\-x1in \-y1in\fP; these values are assumed unless
+overridden.
+.TP
+.B \-z
+(Device = Apple LaserWriter or HP LaserJet Plus on TOPS-20 only, or any
+device on 4.xBSD Unix). For each DVI file processed, type in an EXEC
+command \fBDVISPOOL: dvifilename\fP (on Unix, \fBDVISPOOL
+dvifilename\fP) followed by a newline. The user should have defined
+\fIDVISPOOL:\fP (or \fIDVISPOOL\fP) to be a program or shell script
+which sends the translation of the DVI file to the appropriate output
+spooler.
+
+.SH ENVIRONMENT VARIABLES
+
+The behavior of the DVI translators can be influenced by
+definition of logical names on TOPS-20 and VAX VMS, or
+environment variables in Unix and PC DOS. Compiled-in
+internal defaults will be provided for any of these which are not
+defined. They \fImust\fP be entirely in upper-case, since that
+is conventional on Unix systems. The names currently recognized
+are as follows:
+.TP \w'TEXINPUTS'u+2n
+DVIHELP
+This variable defines an alternate help string which is
+typed when the user makes an input error. It should
+direct the user to additional documentation. For
+example, on TOPS-20, it might be "try HELP
+DVI or XINFO DVI".
+.TP
+FONTLIST
+Normally, the drivers are prepared to search first for \fI.pk\fP,
+then \fI.gf\fP, then \fI.pxl\fP font files. This variable can be used to
+change this search order, or remove one or more of the possibilities.
+It is expected to contain at least one of the strings "PK", "GF",
+or "PXL", possibly separated by arbitrary punctuation and other text.
+This flexibility is necessary because some operating systems expect
+environment variables to conform to some syntax, such as that of a file
+name. Letter case is \fInot\fP significant. Some acceptable strings
+are "PXL-then-PK-then-GF", "PK-GF", "use-only-PXL-fonts", and
+"PXL/GF/PK".
+.TP \w'TEXINPUTS'u+2n
+TERM
+This variable is used only for \fIdvibit\fP; if it does not evaluate to
+either "bitgraph" or "bg", \fIdvibit\fP will refuse to run. On Unix,
+this is the conventional way of defining terminal types with the
+\fItermcap\fP or \fIterminfo\fP systems. This variable is ignored on
+VAX VMS, since the VMS C library sets it to a value which can never be
+"bitgraph" or "bg".
+.TP
+TEXFONTS
+This defines the directory path for finding font files. Its value is
+\fIprepended\fP to the name of a \TeX font to get a full file
+specification. A typical value in Unix for \fITEXFONTS\fP would be
+\fI/usr/local/lib/tex/fonts/\fP. On TOPS-20, font \fIcmr10\fP on a
+300-dot/inch device might correspond to the files
+\fItexfonts:cmr10.300gf\fP, \fItexfonts:cmr10.300pk\fP, or
+\fItexfonts:cmr10.1500pxl\fP.
+.TP
+TEXINPUTS
+This defines the directory path for finding files which
+are not in the current working directory.
+It is \fIprepended\fP to file names. A typical value in Unix
+would be \fI/usr/local/lib/tex/macros/\fP.
+
+.SH FILES
+
+The values of \fItexinputs:\fP and \fItexfonts:\fP below are
+system-dependent. On Unix systems, typical values are
+\fI/usr/local/lib/tex/macros/\fP and \fI/usr/local/lib/tex/fonts/\fP.
+
+.TP \w'texinputs:texfonts.sub'u+2n
+.I *.dvi
+TeX DeVice Independent output file
+.TP
+.I *.dvi-log
+TeX DVIxxx translator error log
+.TP
+.I *.err
+TeX DVIxxx translator error log when long extensions are not available
+.TP
+.I *.dvi-xxx
+TeX DVIxxx translator output file
+.TP
+.I *.xxx
+TeX DVIxxx translator output file when long extensions are not
+available
+.TP
+.I *.sub
+DVI file-specific font substitution file
+.TP
+.I DVISPOOL
+Environment variable (4.xBSD Unix only) defining program or shell script
+which sends translation of DVI file to the appropriate output spooler.
+.TP
+.I DVISPOOL:
+Logical name (TOPS-20 only) defining program which sends translation
+of DVI file to the appropriate output spooler.
+.TP
+.I texfonts.sub
+Job-wide font substitution file
+.TP
+.I texfonts:*.*pxl
+TeX default font rasters
+.TP
+.I texfonts:*.*gf
+TeX default font rasters
+.TP
+.I texfonts:*.*pk
+TeX default font rasters
+.TP
+.I texinputs:dvialw.ps
+PostScript header file containing standard macro definitions prefixed
+to PostScript output from dvialw
+.TP
+.I texinputs:texfonts.sub
+System-wide font substitution file
+
+.SH "SEE ALSO"
+
+dvitype(1),
+latex(1),
+tex(1),
+tr2tex(1)
+
+.SH BUGS
+
+Bugs in either the software or its documentation
+should be reported by electronic or postal mail to
+
+.nf
+Nelson H.F. Beebe
+Center for Scientific Computation
+220 South Physics Building
+University of Utah
+Salt Lake City, UT 84112
+USA
+
+Tel: (801) 581-5254
+EMAIL: Beebe@Science.Utah.Edu (Internet)
+.fi
+
+An active electronic mailing list for news about the DVI driver family
+development is maintained by the author at the above net address. Send
+requests there if you wish to be on it.
+
+.SH AUTHORS
+
+David Fuchs at Stanford University wrote \fIdvitype\fP in
+\fIweb\fP
+and defined the DVI file format.
+
+Mark Senn at Purdue University wrote a preliminary version of the BBN
+BitGraph driver in C, using \fIdvitype\fP as a model. Stephan v.
+Bechtolsheim and Bob Brown at Purdue, Robert Wells at BBN, and Jim
+Schaad and Richard Furuta at the University of Washington, improved
+it.
+
+Contributions for PostScript devices came from Neal Holtz at Carleton
+University. Simon Barnes of Schlumberger Cambridge Research Ltd., and
+Robin Rohlicek at BBN provided useful additions to the BBN BitGraph
+driver which have been generalized and incorporated in Version 2.07.
+
+The transformation to about a dozen other device drivers,
+the massive code rearrangement for many new features and
+easy identification of host- and device-dependent sections, plus
+support for \fI\.pk\fP and \fI\.gf\fP
+compact font files, was carried out at the University of Utah by
+Nelson H.F. Beebe. He also wrote the documents
+\fIA TeX DVI Driver Family\fP
+and
+\fIUsing LaTeX at the University of Utah College of Science DEC-20\fP.
+The first describes all of these drivers in detail,
+and the second is the
+\fILocal LaTeX Guide\fP.
+
+Lon Willett at Utah adapted \fIdvijep\fP to make \fIdviimp\fP for the
+Imagen laser printer family.
+
+John Sauter adapted one of the low-resolution printer drivers to produce
+\fIdvil75\fP for the DEC LA75 printer, and \fIdvil3p\fP for the DEC LN03
+Plus laser printer.
+
+Norman Naugle and colleagues at Texas A&M implemented the
+family on several new systems.
+-------
diff --git a/dviware/beebe/updates/00mail.14 b/dviware/beebe/updates/00mail.14
new file mode 100644
index 0000000000..d34abf10af
--- /dev/null
+++ b/dviware/beebe/updates/00mail.14
@@ -0,0 +1,621 @@
+ 2-Nov-87 11:28:47-MST,30752;000000000001
+Date: Mon 2 Nov 87 11:28:45-MST
+From: "Nelson H.F. Beebe" <Beebe@SCIENCE.UTAH.EDU>
+Subject: DVI driver family update #14
+To: "DVI mailing list": ;
+cc: BEEBE@SCIENCE.UTAH.EDU
+X-US-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112"
+X-Telephone: (801) 581-5254
+Message-ID: <12347446387.22.BEEBE@SCIENCE.UTAH.EDU>
+
+ DVI Driver Family Update #14
+ [01-Nov-87]
+
+This issue announces Version 2.10 of the DVI driver family.
+
+There has a been a long delay in filling orders for the
+software, since I decided in mid-September to place new
+requests on hold until 2.10 was complete. It turned out to
+be a much larger job than I expected, since very substantial
+modifications were made in two drivers, DVIALW and DVIJEP.
+The delay, I believe, has been justified by the substantial
+improvements made in these two drivers, plus a large number
+of minor editorial changes, plus two new drivers. The
+details are contained in the extracts from 00REVHST.TXT
+given below.
+
+In a nutshell:
+
+** DVIJEP has completely eliminated the limit on the number of
+ fonts per page (previously 16) and the number of fonts per
+ document (previously 32); these limits are imposed by the
+ HP LaserJet Plus printer itself, and remain unchanged in
+ the Series II.
+
+** DVIALW has a radically different internal organization.
+ The output is nearly 10% more compact, and obeys a maximum
+ line width. It also is considerably more economical of
+ printer virtual memory resources (which are grossly
+ inadequate for downloaded-font applications), and it should
+ be routinely possible to print 100-page documents on an
+ Apple LaserWriter Plus non-stop. Large characters no
+ longer raise printer errors.
+
+** LW78 incorporates changes to eliminate apparent Apple
+ LaserWriter printer buffer overrun, which I hope will
+ eliminate the "I/O error" conditions we have experienced
+ for over 2 years. Users who have prepared their own local
+ PostScript drivers may find it useful to examine the new
+ LW78.
+
+** Two experimental drivers for the Epson and Epson clone
+ 9-pin printers, DVIE72 and DVIEPS, have been added.
+
+** On VAX VMS, the drivers now incorporate dynamic
+ determination of the VMS quota on the number of open files,
+ preventing them from terminating when a font file open
+ fails.
+
+** On Unix, the drivers may now be used as filters, with the
+ DVI file coming from stdout, and driver output to stdout,
+ eliminating the need to wrap them in a shell script when
+ used for printer spooling.
+
+** New debug option 128 for display of text to be set.
+
+** The -d (debug) option can now be specified more than once,
+ so you need not add values. Originally I thought it might
+ be useful to have -d0 cancel a previously-typed debug
+ request, but this appears less useful than the new
+ alternative.
+
+** The -z option is available for 4.xBSD Unix systems (or any
+ that have an ioctl(fildes,TIOCSTI,*character) call) for all
+ devices. This requests the driver to type in a command to
+ automatically spool the output.
+
+** A Unix man page in troff format (dvi.1l) has been prepared,
+ so full on-line documentation of the drivers is now
+ available. This complements the Emacs Info format
+ documentation (dviman.texinfo), and the typeset manual-page
+ format document (dviman.ltx). There is insufficient
+ commonality in these 3 formats to adopt only one, and
+ inventing a suitable subset of troff or LaTeX (which is
+ what the TeXinfo format attempts to do, with only limited
+ success) would require a substantial effort well beyond the
+ time I would be willing to devote to it.
+
+** The drivers now support 256-character fonts, which is
+ important for European additions to the Computer Modern
+ alphabets, and for oriental fonts.
+
+Finally, here are the details from 00REVHST.TXT:
+
+[01-Nov-87] Replaced references to (void)fprintf(..., plotfp)
+ with references to new macros OUTF(...),
+ OUTF2(...), and OUTF3(...), or existing ones
+ OUTC() and OUTS(). Replaced all instances of
+ putc(*c++,plotfp) by "OUTC(*c);c++". Since
+ putc() is usually a macro, there is a potential
+ incorrect side effect if its first argument is
+ evaluated more than once. Most C implementations
+ use it only in the two branches of a conditional
+ expression, which is safe.
+
+[01-Nov-87] Completed major overhaul of dvijep.c. The font
+ deletion mechanism was not successful, partly
+ because the font number was not subsequently
+ reset in one place, but mostly because it causes
+ a page eject. This would make it impossible to
+ print some documents. dvijep now keeps track of
+ both the number of fonts in use on the current
+ page, and the total number in use in the
+ document. When either of these limits is
+ reached, the characters in those fonts are sent
+ as bitmaps, instead of as downloaded fonts. It
+ is still possible to have a document which is too
+ complex for the LaserJet to print (raising error
+ code 21 on the printer front panel status
+ display), but that is now a limit imposed by the
+ printer, rather than the DVI driver, and cannot
+ be gotten around.
+
+ There is room for further work here, however.
+ Most documents do not require an excessively
+ large number of fonts. For example,
+ dvidriver.ltx uses 23 fonts, and weave.tex uses
+ 15, but the TeXbook uses 54.
+
+ When the DVI driver begins execution, through the
+ call chain main() -> dvifile() -> readpost() ->
+ getfntdf() -> readfont() -> reldfont() ->
+ read{pk|gf|pxl}() -> newfont(), it normally reads
+ in the font definitions from the DVI file
+ postamble and assigns font numbers in order of
+ occurrence, and builds its internal font and
+ character tables. Later, as pages are processed,
+ font changes occasioned by DVI fnt_num_0 ..
+ fnt_num_63 and fnt1 .. fnt4 commands result in
+ setting the global flag font_switched, which in
+ turn causes setchar() and setstr() to output font
+ switch commands to the device.
+
+ The implication of this for dvijep is that all
+ fonts beyond the first 32 are marked as
+ non-downloadable. In the case of the TeXbook, it
+ turns out that this includes the heavily-used
+ cmr, cmsy, and cmmi fonts at 5, 6, 7, 8, 9, and
+ 10 pt sizes, which means that almost all of the
+ characters set on a page will be sent as bitmaps,
+ instead of as downloaded characters. On my HP
+ LaserJet Plus, every page raised printer error
+ code 21. This might not happen on an HP LaserJet
+ Series II, which can have substantially more
+ memory, but I haven't one locally to try the
+ experiment.
+
+ The solution to this problem is to delay font
+ number assignment until the font is actually
+ referenced. Since a considerably smaller number
+ of fonts are needed on each page, it is then
+ possible to download most of them, and a
+ font-rich document like the TeXbook can be
+ printed successfully in sections. The change
+ involves moving the body of newfont() to a new
+ function, makefont(), and having newfont() only
+ initialize the font_number with a special
+ "undefined" value. The macro SET_CURRENT_FONT
+ has become big enough that it has been
+ transformed into a function, setfont().
+ setfont() now checks font_number for the
+ undefined value, and in such a case, calls
+ makefont() to assign the font a number and create
+ it in the printer. With this change, the TeXbook
+ can be printed successfully.
+
+[30-Oct-87] Changed vaxvms.c, gblprocs.h, openfont.h, and
+ machdefs.h to support dynamic determination of
+ the limit on the number of open files for VAX
+ VMS. This is a VMS quota parameter whose dynamic
+ value depends on the number of subprocesses.
+ Previously, a user with too small a limit would
+ find the dvi drivers could fail because the hard
+ limit on the number of open font files was too
+ large.
+
+[29-Oct-87] In LW78.C, removed typeout of final CR LF in
+ Get_Msg(), and inserted system call to dismiss
+ the process until the output buffer is empty at
+ the start of Put_Packet().
+
+ LW78 had been experiencing I/O error returns from
+ the Apple LaserWriter Plus, and when I attempted
+ to copy a PostScript file directly to the
+ printer, the same thing happened, only much
+ earlier in the job. This raised the suspicion of
+ buffer overrun in the printer. Three experiments
+ using a 100-page document with (1) a 5-second
+ sleep before outputting each buffer, (2) process
+ dismissal until the buffer was empty, and (3) the
+ Kermit TRANSMIT command (which waits for a prompt
+ from the LaserWriter after each line) all
+ resulted in successful printing, and I have
+ confidence that this change in LW78 will provide
+ superior performance.
+
+ With the new LW78, I sent dvidriver.dvi-alw with
+ the modified BOP and EOP definitions given below,
+ and printed the 100 pages at an average rate of 5
+ pages per minute. Virtual memory usage was
+ initially 2Kb to 4Kb per page while fonts were
+ being downloaded, and in later pages, dropped to
+ a low of 1105 bytes/page. Pages with that low
+ figure had only text set on them, and no fonts
+ downloaded, with the text guarded by save/restore
+ sequences. That virtual memory was still
+ consumed leads one to wonder if there is not a
+ bug in the PostScript memory allocation code
+ which causes some "seepage" loss. If one of
+ dvialw's macros were leaving unclaimable garbage
+ behind, one would expect that the garbage amount
+ would vary, but many different pages had the same
+ 1105 bytes/page consumption. Total virtual
+ memory consumed by the job was 112Kb, with 78Kb
+ remaining available at end-of-job.
+
+[27-Oct-87] Simplified beginning-of-page and end-of-page code
+ in prtpage.h by creating bopact() and eopact()
+ routines in several drivers, and removed bopact.h
+ and eopact.h (which were previously used only by
+ dvibit), including references to them in
+ makefile.*.
+
+[27-Oct-87] Numerous small editorial changes for code
+ consistency, and to reduce the number of warnings
+ from the lint utility.
+
+[27-Oct-87] {Thanks to John Pavel (mcvax!nplpsg!jrp@uunet.uu.net)
+ for urging this change}
+ On Unix only, Version 2.10 now permits input to
+ come from stdin, and output to go to stdout,
+ allowing use of the drivers as filters. This
+ choice is automatically made when no file names
+ are specified on the command line.
+
+ Use of stdout for binary files is generally
+ impossible for other operating systems, which
+ either make a distinction between text and binary
+ file formats, or use line terminators other than
+ <LF>, necessitating translation of Unix
+ end-of-line '\n' on input and output. With the
+ exception of dvialw, all the drivers produce
+ binary output files.
+
+[27-Oct-87] {Thanks to Bernhard Nebel (NEBEL@DB0TUI11.BITNET)
+ for useful suggestions}
+ Completed major overhaul of dvialw.c. A
+ fundamental problem with existing PostScript
+ interpreters is that they lack garbage
+ collection, and the PostScript programmer is
+ expected to manage storage with save/restore
+ command judiciously wrapped around throw-away
+ code. The problem this poses for a TeX
+ environment is that one does not wish to discard
+ downloaded fonts, since they will likely be
+ needed again.
+
+ In the previous version of dvialw, the -s and -v
+ options provided some user control of this, but
+ such user control is only of marginal utility.
+
+ It proved interesting to install the following
+ PostScript code segment immediately before the
+ BOJ (beginning of job) command in an output file
+ from dvialw produced from Appendix F of the
+ TeXBook. The TeXbook uses 54 fonts, and
+ therefore puts a sizeable burden on a printer
+ that has only limited font memory.
+
+% These provide alternate definitions of BOP and EOP in dvialw.ps
+% which cause CPU time and virtual memory statistics to be printed
+% at the bottom of each output page
+/BOP
+{
+clear
+Mtrx setmatrix
+25 0 translate
+vmstatus pop /VMUSED exch def pop
+usertime
+} bdf
+/EOP
+{
+/#copies exch def
+/USERTIMEIN exch def
+save
+/pt {Resolution 72 div mul} def
+/Helvetica-BoldOblique findfont 12 pt scalefont setfont
+/SP {12 pt 0 pt rmoveto} def
+/PN {SP 10 vmstr cvrs show} def
+/vmstr 15 string def
+36 pt 36 pt moveto
+([VMstatus:) show
+vmstatus PN PN PN (]) show
+SP SP ([VMpage:) show
+vmstatus pop exch pop VMUSED sub PN
+(]) show
+SP SP ([Page time:) show
+usertime USERTIMEIN sub PN ( msec]) show
+restore
+showpage
+} bdf
+
+ With this addition, each page now carries both
+ memory usage and (printer) CPU time statistics at
+ the bottom of each page. On the Apple
+ LaserWriter with paper type "note", there is
+ about 250Kb of virtual memory available at job
+ start. Here is a table of the memory
+ requirements for successive pages of Appendix F
+ of the TeXbook:
+
+ ---- ----------- -----------
+ Page DVIALW 2.09 DVIALW 2.10
+ ---- ----------- -----------
+ 431 4953
+ 432 26057
+ 433 3713
+ 434 9693
+ 435 27948 21101
+ 436 18971 13421
+ 437 15644 10109
+ 438 21764 15324
+ 439 27064 19596
+ 440 8172 6628
+ ---- ----------- -----------
+
+ Version 2.09 reached a VM error condition
+ (virtual memory exhausted) on page 434, while
+ Version 2.10 was able to proceed 4 pages beyond
+ that before hitting the same limit. Each page in
+ Version 2.10 requires about 30% less virtual
+ memory.
+
+ Initially, I wrote a short filter program that
+ moved the text strings on each page to after the
+ font download sequences, wrapping the text in a
+ save/restore pair to recover the virtual memory
+ needed to store them. This proved to be quite
+ straightforward, requiring only about 60 lines of
+ C code.
+
+ To implement the same facility in dvialw proved
+ much more complex, because I was not willing to
+ suffer the performance penalty of reading each
+ page of the DVI file twice, once to collect
+ needed fonts, and a second time to set text and
+ rules. Instead, a completely new mechanism is
+ implemented whereby output is channelled through
+ several new routines, which ultimately reach the
+ low-level textchr() routine which gets a single
+ character to process. Based on a global flag,
+ textchr() either outputs this immediately (e.g.
+ for macros, rules, and font downloading), or
+ stores it in an internal buffer (text setting).
+ On the basis of examination of .dvi-alw files for
+ the DVI driver manual, and the TeXbook, the
+ internal buffer is chosen to be large enough so
+ that it will usually only need to be dumped once
+ per page.
+
+ PostScript loop tests on the Apple LaserWriter
+ Plus (Version 38.0 PostScript) give execution
+ times of about 0.25 msec for one iteration of an
+ empty loop, determined by executing
+
+ usertime 10000 {} repeat usertime exch sub
+
+ and 55 msec for one save/restore pair:
+
+ usertime 1000 {save restore} repeat usertime exch sub
+
+ Consequently, one does NOT want to do a
+ save/restore around every string, but only around
+ large groups of strings.
+
+ Because of the use of relative coordinates in
+ most output typeset text (the T macro instead of
+ the S macro), and the use of remembered rule
+ widths (w and h in the B and Q macros), it is not
+ trivial to correctly handle the case of more than
+ one bufferful per page (since intervening
+ non-buffered output might change the font or
+ current point), and it took a considerable number
+ of iterations to get it working satisfactorily,
+ with the buffer size temporarily set artificially
+ low.
+
+ Having the output being filtered through a
+ central location, textchr(), has made it possible
+ to further economize on the output volume (e.g by
+ collapsing <letter><newline><open-paren> to
+ <letter><open-paren>, and to more closely
+ approach a constant line width (except for
+ PostScript from a \special{} command, which is
+ output verbatim). Some operating systems have
+ trouble with long lines in files, and Version
+ 2.10 should now largely remove this problem.
+
+ The line breaking algorithm implemented in
+ textchr() and textflush() is far from trivial,
+ because PostScript does not uniformly recognize
+ <backslash><newline> as a continuation sequence
+ that can be discarded; instead, it permits this
+ continuation mechanism only in parenthesized
+ strings. Otherwise, comments cannot be
+ continued, angle-bracketed strings can be
+ continued by simply inserting a bare newline, and
+ elsewhere, a newline can be used any place a
+ blank is used. Some of the comment lines
+ produced by dvialw are long; they are now split
+ automatically by placing a hyphen in the last
+ column of the line, and continuing with "%-" on
+ the next line. Any software that takes advantage
+ of the %%PageTable at the end will therefore need
+ adjusting (I doubt that any exists, so this
+ change does not concern me). It is regrettable
+ that the PostScript developers did not give line
+ continuation more thought.
+
+ Font change commands are now defined more
+ compactly as "F#" or "F##", where "#" is the
+ sequential number of the font in the document.
+ This further helps to reduce output volume. The
+ initial font definitions (the NF macro) still use
+ the full name, and carry a comment with the font
+ file name, so it is still possible to easily find
+ out what font file was used for any part of the
+ output. The problem of corrupted font files has
+ come to my attention on several occasions, so it
+ is worthwhile to maintain this connection in
+ dvialw, which is the only driver that produces
+ human-readable printer output.
+
+ On Appendix F of the TeXbook, these changes
+ reduced the output file size by about 8% compared
+ to Version 2.09, and about 9% when PS_SHORTLINES
+ was non-zero. On the DVI driver manual (99
+ pages), the file size from Version 2.10 with
+ PS_SHORTLINES defined was 15% shorter than that
+ from Version 2.09. Since a non-zero
+ PS_SHORTLINES produces marginally smaller output,
+ it is now the default for all implementations,
+ but it can be overridden by a compile-time
+ redefinition.
+
+[22-Oct-87] {Thanks to Marcus Moehrmann (marcus%fkihh@unido.uucp)}
+ Added drivers dvieps and dvie72 for Epson 9-pin
+ printers and compatibles. dvieps is for 240H x
+ 216V resolution, and dvie72 for 60H x 72V
+ resolution (same as dviprx for Printronix
+ printers).
+
+ It was necessary to make a number of changes to
+ the submitted code to bring it up-to-date with
+ the rest of the family, and to conform to my
+ coding practices. Since I do not have an Epson
+ printer on which to test this locally, the
+ version number carries the suffix
+ "[experimental]". The same suffix appears in
+ dvica2. These will be removed when the drivers
+ are considered ready for final release, based on
+ positive user feedback.
+
+[22-Oct-87] Added debug option 128 (DBG_SET_TEXT) to display
+ each piece of text set by the driver, together
+ with its page coordinates in dots, and its font
+ name. This of course produces voluminous output,
+ but is quite handy when you are trying to step a
+ long way into execution to track down a bug.
+
+[22-Oct-87] All debug options have been turned into symbolic
+ references, e.g.
+
+ if (DBGOPT(DBG_OFF_PAGE))
+
+ instead of
+
+ if (debug_code & 32)
+
+ It was clearly a mistake not to have done this in
+ the first place. I also wish that I had made
+ these options sequential numbers, instead of
+ powers of two, but it is probably too late to
+ change that now.
+
+[12-Oct-87] Edited dviman.texinfo to bring it up-to-date with
+ dvi.1l and dviman.ltx.
+
+[01-Oct-87] Created Unix-style man page file, dvi.1l.
+
+[01-Oct-87] Added support for a "-z" option (typein of
+ "DVISPOOL dvifilename") for 4.xBSD Unix systems,
+ which have imitated TOPS-20's STI% (Simulate
+ Terminal Input) JSYS facility with ioctl(fildes,
+ TIOCSTI, *char).
+
+[30-Sep-87] {Thanks to Stefan Kronberg (ZEFFI@FINABO.BITNET)}
+ Added support of font files with up to 256
+ characters. Normal TeX Computer Modern fonts use
+ only 128 characters per font, but extensions for
+ European alphabets, and Japanese fonts, will
+ require more than 128.
+
+ Unfortunately, this was not quite as trivial as I
+ had originally intended, where the values
+ LASTPXLCHAR and NPXLCHARS in gendefs.h need only
+ be increased from 127 and 128 to 255 and 256
+ respectively. The problem is that several loops
+ used code like
+
+ BYTE k;
+ ...
+ for (k = FIRSTPXLCHAR; k <= LASTPXLCHAR; ++k)
+
+ With LASTPXLCHAR = 255, the last loop iteration
+ will increment k to 256, but since it is a byte
+ value, this wraps to 0, and the loop becomes
+ infinite on a byte-oriented machine. This made
+ it necessary to retype the offending loop indices
+ as UNSIGN16.
+
+ The context diff listing for these changes is
+ rather long (about 1200 lines), so I do not
+ include it here.
+
+[30-Sep-87] Changed -d option processing in option.h to allow
+ multiple -d options to accumulate, instead of
+ requiring them to be set with one -d option. The
+ change is simple: replace
+
+ debug_code = (BYTE)atoi(optstr+2);
+
+ by
+
+ debug_code |= (BYTE)atoi(optstr+2);
+
+
+[29-Sep-87] Because of problems on record-oriented file
+ systems (VAX VMS being the worst offender), the
+ code in dvialw.c does more when PS_SHORTLINES is
+ defined; it now keeps track of output widths, and
+ will not produce output lines more than a couple
+ of characters longer than a fixed value,
+ PS_MAXWIDTH. However, no such limit is placed on
+ comments, or macros retrieved from dvialw.ps;
+ both of these are already of limited length.
+
+ Changed machdefs.h to allow PS_SHORTLINES to be
+ set at compile time.
+
+ A single experiment on a 20-page DVI file showed
+ that the .dvi-alw output was about 3% longer when
+ a version of dvialw with PS_SHORTLINES set was
+ used.
+
+[29-Sep-87] {Thanks to John Pavel (mcvax!nplpsg!jrp@seismo.css.gov)
+ and Brendan McKay (munnari!anucsd.oz!dbm@seismo.css.gov)}
+
+ The code in dvialw.c in functions setchar() and
+ setstr() emits a save/restore pair around a large
+ character font definition. On the Apple
+ LaserWriter Plus (which I only recently got as a
+ replacement for our stolen ALW), this results in
+ a "Fatal system error @ 0X2e6bec". The fix is
+ fortunately simple. Change those two instances
+ of
+
+ OUTS("save");
+
+ (but NOT the one in special()) to
+
+ OUTS("save /temporary_font NF 1 /temporary_font SF");
+
+ This will put the character in a temporary font
+ which is discarded when the restore command is
+ executed. Here is simple test file using cminch;
+ it produces a large (~400Kb) .dvi-alw file.
+
+% test for dvialw downloading of large characters
+\font\bigfont=cminch
+This file tests a DVI driver's capability to support downloading
+of large characters. The following uninteresting tables of the
+Roman alphabet are printed in font {\it cminch\/}.
+\bigfont
+\obeylines
+ABC
+DEF
+GHI
+JKL
+MNO
+PQR
+STU
+VWX
+YZ
+\vfill\eject\end
+
+
+[29-Sep-87] {Thanks to John Pavel (mcvax!nplpsg!jrp@seismo.css.gov)}
+ Removed obsolete SHORTLINES references from
+ machdefs.h; PS_SHORTLINES remains, and can now be
+ set in machdefs.h, instead of only in dvialw.c.
+ The default setting in machdefs.h now is
+
+ #define PS_SHORTLINES 0
+
+ and dvialw.c now has
+
+ #ifndef PS_SHORTLINES
+ #define PS_SHORTLINES 0 /* run with long output lines */
+ #endif
+
+-------
diff --git a/dviware/beebe/updates/00mail.15 b/dviware/beebe/updates/00mail.15
new file mode 100644
index 0000000000..3517af3a16
--- /dev/null
+++ b/dviware/beebe/updates/00mail.15
@@ -0,0 +1,178 @@
+ 9-Dec-87 18:05:25-MST,8641;000000000000
+Mail-From: BEEBE created at 9-Dec-87 18:05:21
+Date: Wed 9 Dec 87 18:05:21-MST
+From: "Nelson H.F. Beebe" <Beebe@SCIENCE.UTAH.EDU>
+Subject: DVI driver family update #15
+To: "DVI mailing list": ;
+cc: beebe@SCIENCE.UTAH.EDU
+X-US-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112"
+X-Telephone: (801) 581-5254
+Message-ID: <12357217912.28.BEEBE@SCIENCE.UTAH.EDU>
+
+ DVI Driver Family Update #15
+ [09-Dec-87]
+
+This newsletter will be fairly short. Its primary purpose is to
+report some experience with Microsoft C Version 5.0 on the IBM PC,
+and provide a fix for a bug uncovered in PCMAKE.
+
+In PCMAKE, in file execute.c, there is an off-by-one error in one
+call to strncat(). The argument param should be replaced by
+&param[1]; elsewhere in the code, param[0] was set to the string
+length, this apparently being required by the Wizard C library
+routines that were called. When I made this fix, I also
+installed a check for command line truncation and trimming of
+unnecessary leading whitespace. Here is a difference listing: (<
+marks original; > marks new):
+
+130c130,135
+< return(system(str));
+---
+> {
+> if (strlen(str) > 128)
+> fprintf(stderr,
+> "?MAKE -- command line exceeds DOS limit of 128 characters\n");
+> return(system(str));
+> }
+228a234
+> char *p;
+233c239,245
+< VOID strncat(str,param,MAXCMD);
+---
+> p = &param[1]; /* param[0] has string length */
+> while ((*p == ' ') || (*p == '\t'))
+> ++p; /* discard leading whitespace */
+> VOID strncat(str,p,MAXCMD);
+> if ((strlen(cmd) + 1 + strlen(p)) > MAXCMD)
+> fprintf(stderr,
+> "?MAKE -- command line truncated at DOS limit of 128 characters\n");
+
+It is my intention to implement the new features of PCMAKE in the
+multi-O/S version, PDMAKE, and then abandon PCMAKE. In order to
+do this, it has been necessary to implement versions of the Unix
+environment area support routines, getenv() and putenv(), for all
+the systems supported by PDMAKE. That work is complete for all
+but two of the operating systems, neither of which I have
+available for testing. However, my project backlog is large,
+with several commitments months overdue, so further work on
+PDMAKE will likely be delayed until spring. We have initiated an
+effort to acquire a supercomputer at the University of Utah, and
+I am a member of the committee charged with the task, so that too
+will seriously impact the time I can spend on programming
+projects.
+
+The remainding text is stored as file 01README.TXT in DVI
+distributions after 18-Nov-87.
+
+ Changes to the Public Domain DVI Driver Family
+ for
+ IBM PC Microsoft Version 5.0
+ [17-Nov-87]
+
+Version 5.0 of Microsoft C finally arrived 13-Nov-87, and I spent the
+weekend revising Make to work with this compiler. Previously,
+because of the use of non-standard library functions, it worked only
+with Wizard C (now defunct, but forming the basis of Borland
+International's Turbo C). Unfortunately, it would work only in the
+small memory model, which in practice limited it to Makefiles of
+about 150 lines or less. This was very inconvenient for the TeX DVI
+driver family, which required 5 separate Makefiles. The new version
+of Make now works correctly with Microsoft C Version 5.0, removes
+some serious size limitations of the old one, and introduces several
+new features; they are described in a 00README.TXT file in the PCMAKE
+directory.
+
+Microsoft C Version 5.0 is now essentially completely conformant with
+October 1986 draft ANSI C. Version 4.0 supported draft ANSI C
+function prototypes only with type names, not variable names; Version
+5.0 eliminates this. Version 4.0 did not support const and volatile
+type modifiers; 5.0 does. In Version 4.0, function type checking was
+selected by defining the preprocessor variable LINT_ARGS; it is
+enabled by default with Version 5.0. The Version 5.0 library also
+conforms to draft ANSI C.
+
+The addition of draft ANSI C library conformance changes the types of
+a number of functions and arguments, so type declarations have been
+modified in gblprocs.h. Previously, the DVI drivers had a single
+flag, ANSI, which previously selected ANSI function prototype
+declarations. This has now been replaced by two, ANSI_LIBRARY, to
+indicate library conformance, and ANSI_PROTOTYPES, to indicate
+support for function prototypes. Variable names are NOT used in
+these prototypes, so the code will still compile with Version 4.0.
+
+Version 4.0 supported two interfaces to the compiler, MSC and CL.
+MSC was the only one available in Version 3.0, so I continued to use
+it. Version 5.0 drops MSC and provides only CL. The Makefile has
+been revised to reflect this.
+
+A few more missing type casts have been installed in the code.
+The number of data conversion warning messages has been drastically
+reduced by the discovery that a declaration "float x = 1.0" always
+produces a warning, but "double x = 1.0" does not. The Makefile has
+been revised to define float to be double for all the code. The
+warnings that remain (about 3 in each driver, instead of dozens)
+appear to possibly be compiler artifacts. More experimentation is
+still required.
+
+Besides full draft ANSI C conformance, Version 5.0 introduces some
+new optimization levels, and in-line expansion of some important
+library functions from the strxxx and memxxx classes. I am happy to
+report that these seem to work successfully with the DVI drivers, and
+optimization level -Oailt is now the default, instead of -Od (no
+optimization). Despite the in-line expansion, the .EXE files are 3K
+to 7K bytes shorter than they were with Version 4.0.
+
+Except for the scanf() bug which affects the -o#:#:# option
+(documented in the user manual), it looked like Version 4.0 had no
+other bugs which affected the drivers. However, in October 1987, we
+found a bug which can be reproduced by a very simple example: the TeX
+file containing just
+
+$VW$
+\bye
+
+prints V and W correctly, while
+
+$WV$
+\bye
+
+prints V correctly, but produces a black blob for W. Some length
+sessions with Codeview revealed that in the second case, the call to
+fseek() in charpk() to position to the bitmap for W was returning a
+success status, but not positioning correctly. In fact, subsequent
+getc() calls returned EOF! End-of-file is not intentionally not
+checked for, because in that code section, it cannot happen (unless
+the compiler or library are in error). Since EOF has the value -1,
+or 0xFFFF, this produced a bitmap with all bits set to one, and a
+black blob resulted. Further experimentation showed that a rewind()
+issued at the end of readfont() could remove that error, and should
+be otherwise harmless, even if it is correctly unnecessary.
+With Version 5.0, the bug is no longer there!
+
+A version of qsort() has been added for texidx. keytst has been
+updated for convenience, and a version of sleep() added to it so that
+it can be run under PC DOS.
+
+LINK 3.61 supplied with Microsoft C Version 5.0 supports two new
+options, /FARCAL and /PACKCODE, which cause the linker to try to
+combine code segments, and replace far calls by near calls, in an
+effort to speed up the code. I have not yet experimented with this.
+
+Stack size for programs on the IBM PC remains a thorny issue.
+Experimentation with EXEMOD and DVIALW showed that DVIALW would run
+with a stack size of 5000 (hex) or larger, but not 4800 (hex) or
+less. I have reduced stack size in MAKEFILE.MSC to 8000 (hex), and
+now set it with a LINK option, instead of having to run EXEMOD
+separately. With the new Make, a new rule for producing the .SYM
+file has been introduced, shortening the makefile.
+
+One user has reported having downloaded DVI files and font files from
+a host that stored them as fixed blocked binary records, with the
+last (short) block null-padded. The DVIxxx.EXE files as distributed
+will not handle this. However, code is there in readgf.h and
+readpxl.h to handle this case under OS_VAXVMS; just change the "#if
+OS_VAXVMS" to "#if (OS_PCDOS | OS_VAXVMS)". I have not done this in
+the master distribution, because I regard such incorrect padding as an
+operating system defect. Users who download fonts from Unix or
+TOPS-20 systems will not experience such problems.
+-------
diff --git a/dviware/beebe/updates/00mail.16 b/dviware/beebe/updates/00mail.16
new file mode 100644
index 0000000000..746e9f8d84
--- /dev/null
+++ b/dviware/beebe/updates/00mail.16
@@ -0,0 +1,654 @@
+26-May-88 18:15:50-MDT,26245;000000000001
+Date: Thu 26 May 88 18:15:48-MDT
+From: "Nelson H.F. Beebe" <Beebe@SCIENCE.UTAH.EDU>
+Subject: DVI driver family update #16
+To: "DVI mailing list part 2": ;
+cc: BEEBE@SCIENCE.UTAH.EDU
+X-US-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112"
+X-Telephone: (801) 581-5254
+Message-ID: <12401511229.12.BEEBE@SCIENCE.UTAH.EDU>
+
+ DVI Driver Family Update #16
+ [26-May-88]
+
+
+============
+INTRODUCTION
+============
+
+This newsletter should have gone out a couple of months ago,
+but I have just been too busy. Utah is in the process of
+planning for the purchase of a supercomputer, and I've been
+serving on the technical committee for it since Oct-87.
+Bids have now come in, and evaluations are underway.
+
+I will be away from Salt Lake from 9-June to 5-August, and
+unfortunately, will not be able to get Version 2.11 released
+before I leave. I therefore felt that this issue had better
+get out now, or you won't hear from me until September.
+With my current mail volume, I expect that it will take 3 to
+4 weeks after my return just to open and answer mail,
+sigh...
+
+
+============
+MAKE PROGRAM
+============
+ One of the notes below comments on a bug in the
+public-domain version of Make. Ignore the comment about
+volunteer efforts for preparing a fix. Since Easter, I've
+developed a brand new ground-up reimplementation of Make
+which on completion of testing will be available on the same
+terms as the DVI family. This new implementation is
+designed from the start to eliminate all the misfeatures of
+other Makes, add features of newer Unix Makes, plus
+directives similar to those of the C preprocessor (but with
+! instead of # prefixes), conform completely to January 1988
+draft ANSI C, run on multiple operating systems, and conform
+(mostly) to the syntax of Unix Make. It is being tested
+locally on a dozen different machines representing 5
+hardware architectures and 4 operating systems. I'd hoped
+to have it ready for beta testing before my June departure,
+but alas, that will not be possible either. The current
+version is working locally, has about 8800 lines of code in
+itself and support software, plus about 100 pages of
+documentation in two manuals. If any of you are interested
+in getting your name in for a beta test release, send me
+mail to that effect; it will, however, require that you have
+Internet access for FTP, because I will not send tapes or
+floppies, and it is too big for easy electronic mail
+distribution.
+
+
+=======
+TURBO C
+=======
+
+Several people tried (unsuccessfully) to implement the
+driver family on the IBM PC with Turbo C 1.0. The large
+number of bugs that were being reported on the net
+discouraged me from even buying it (one of the bugs resulted
+in the reciprocal of division results being returned). I
+bought version 1.5, and made some extensive tests with it on
+the DVI family, the ELEFUNT elementary function test
+package, and on my new Make implementation.
+
+The good news is that Turbo C 1.5 is fast; compilation of
+one DVI driver on the PC XT drops from 35 minutes with
+Microsoft C 5.0 to 7 minutes with Turbo C 1.5.
+
+The bad news is that the compiler is fatally flawed for C
+programs containing floating-point, to the extent that even
+random numeric constants are compiled into incorrect values!
+I won't go into further details about this. A 10-page
+letter to Borland International resulted in a positive
+response from the software development director, and my
+appointment as a beta test site for 2.0, which in-house at
+least, fixes all the bugs I reported.
+
+Given that the discounted price of Microsoft C is about
+$350, and that of Turbo C about $45, it would be nice to
+switch to Turbo C. For the new Make, which has no
+floating-point usage, Turbo C performs admirably, and I've
+not detected any bugs that affect Make.
+
+The Turbo C library is not as complete as the Microsoft C
+library; it lacks the <sys/xxx.h> files, <signal.h> and
+signal(), utime(), and probably some others. The output
+.EXE files seem to be somewhat smaller than those from
+Microsoft C 5.0, and TLINK is much faster than LINK. LINK
+can also be used with Turbo C output. Although Turbo C does
+support most draft ANSI C syntax, it does not issue as many
+helpful diagnostics as Microsoft C does, nor does it have an
+option to produce ANSI style declarations from existing
+code. Also, Turbo C's command line options are not
+standard; instead of "cc -o foo foo.c", you have to write
+"tcc -efoo foo.c" (no space after -e), which requires
+additional nuisance changes in Makefiles.
+
+Wildcard command-line expansion for compiled programs is
+automatic; with Microsoft C, a special library routine has
+to be loaded.
+
+
+=====================
+LATEX EDITING SUPPORT
+=====================
+
+I have developed some extensive support for editing LaTeX
+files in GNU Emacs, which is widely available and runs on
+most Unix and VMS systems. We are shipping Emacs copies on
+VMS BACKUP tapes with the DVI drivers. The latex.el library
+is now at beta test release 0.07, with 34 sites
+participating.
+
+latex.el grew out of a translation from TECO to Lisp of the
+editing support I developed for TOPS-20 Emacs, which is
+described in our Local LaTeX Guide; many of you have seen it
+(it is accessible for ANONYMOUS FTP from SCIENCE.UTAH.EDU in
+APS:<TEX.PUB.LOCAL-GUIDE>. Thanks to the ease of
+programming in Lisp, I have added many new features,
+including the availability on a key of every macro in the
+LaTeX book, together with helpful information about macro
+arguments. There is also support for SliTeX. The current
+development version (pre-0.08) of latex.el is 2513 lines
+long.
+
+The library has a LaTeX-gripe function that makes it easy
+for users to mail comments to me while they are still in the
+editor , and I have several submissions that contain good
+ideas that I'd like to implement before the final release.
+
+I'd hoped to finish up the test before my departure, and
+make an official release of latex.el to the Free Software
+Foundation, but again, this will not be possible until at
+least August.
+
+
+===========
+MAKEINDEX
+===========
+
+One of the changes recorded below is a correction to
+TeXindex. After uncovering some further misfeatures of
+TeXindex that make it unable on the IBM PC to handle index
+files larger than 32767 bytes long (that in itself is a long
+story), I turned my efforts to seeing if MakeIndex could be
+gotten to work on non-Unix environments. That indeed was
+the case, after a fair amount of work, and a couple of
+months ago, an announcement of it was made on TeXhax.
+MakeIndex now runs on all the systems that the DVI driver
+family runs under (except IBM VM/CMS), and is a much
+superior system. There was initial confusion about its
+release status, because it was developed at the Berkeley
+VORTeX project, which licenses its software for a fee. That
+has been worked out, and MakeIndex may be freely
+distributed; if that had not happened, I would have turned
+elsewhere in search of a public indexing system. Pehong
+Chen and Leslie Lamport have done an excellent job of
+MakeIndex, and I urge you to get it and adopt it. Copies
+are available for ANONYMOUS FTP from UCBVAX.BERKELEY.EDU,
+SCIENCE.UTAH.EDU, CTRSCI.UTAH.EDU, and
+JUNE.CS.WASHINGTON.EDU. It will become part of the
+Washington Unix TeX distribution, and is also included on
+DVI tapes that we ship from Utah.
+
+
+=======================
+DVI DRIVER DEVELOPMENTS
+=======================
+
+Since the 2.10 release in November, 1987, the DVI family has
+seen the addition of two new drivers, DVIADX, for the Anadex
+Silent Scribe 72dpi and 144 dpi dot matrix printers and
+DVIGP, for the Phillips GP 72dpi and 144dpi dot matrix
+printers. With these two, I am discontinuing the practice
+of maintaining separate programs for different resolutions
+of the same device (as was done for the Apple Imagewriter,
+Okidata, and Epson printers); local recompilation with
+different compile-time switch values can produce programs to
+support the two resolutions.
+
+A significant new development during the past month has been
+the first successful port of the family to IBM VM/CMS using
+the Waterloo C compiler; the changes have been merged into
+my development sources, and will be available when 2.11
+comes out. Shashi Sathaye at the University of Kentucky
+gets credit for this; I've sent her a copy of the current
+sources for verification of the merged changes. A couple of
+weeks after I received her changes, I got notification from
+Russell Fulton at the University of Auckland in New Zealand
+that the start of a port to VM/CMS had also been made there.
+Previous attempts elsewhere with the SAS and IBM C compilers
+have been stymied by compiler bugs.
+
+I've also received from Julian Perry an update for 2.10 of
+the changes to dvijep.c to support portrait and landscape
+printing, and Steven H. Gutfreund has supplied modifications
+to support \special{}. Neither of these are currently
+merged into the master sources, because I'm awaiting the
+completion of the TeX Users Group committee report on
+standardization of \special{}s and other DVI driver
+features. On request, I have mailed the changes to
+individuals who wanted to merge them into their own private
+versions of dvijep.
+
+Thanks to the good efforts of the following people:
+
+"DVICAN@science.utah.edu":
+! The DVICAN mailing list [25-May-88] !
+beebe@science.utah.edu, !Nelson H.F. Beebe!
+bertheau%FRINRA72.BITNET@cunyvm.cuny.edu, !Yves Bertheau!
+DLT%STAR.RL.AC.UK@cunyvm.cuny.edu, !David Terrett!
+friesland%rz.informatik.uni-hamburg.dbp.de@RELAY.CS.NET, !Gerd Friesland!
+rjjt%oberon.sv.dg.com@cs.utah.edu, !Richard J.J. Tobias!
+TFYS-PP%FINOU.BITNET@cunyvm.cuny.edu, !Pekka Pietilainen!
+dvican@science.utah.edu ! !
+!**** Last Line ****
+
+dvican, the driver for the Canon LBP 8 A2, has been
+substantially improved. I've formed a small mailing list
+(the above people) to exchange correspondence about it; if
+any of you on this larger DVI list (currently 224 sites)
+have a Canon A2, let me know (soon), so I can get you on the
+small list too.
+
+
+==============
+CHANGE HISTORY
+==============
+
+Because of the work noted in the preceding section, the
+development directories have many more changes than are
+recorded here. These here are ones that you might want to
+patch into your local sources if they appear to impact you;
+if not, just sit tight and wait for 2.11.
+
+[18-May-88]
+ In dvijep.c about line 180, change
+ {PUTESC; sprintf(plotfs,"*c%dE",MAP_CHAR(ch)); OUTST(plotfs); }\
+ to
+ {PUTESC; sprintf(plotfs,"*cd%dE",MAP_CHAR(ch)); OUTST(plotfs); }\
+ This correction sets the font number to 0; the
+ old one works on the HP LaserJet, but might break
+ on clones.
+
+[14-Apr-88]
+ Changed system() in vaxvms.c to allow warning and
+ information status returns to be treated as
+ success. The body of system() now reads:
+
+ t.dsc$w_length = strlen(s);
+ t.dsc$a_pointer = s;
+ t.dsc$b_class = DSC$K_CLASS_S;
+ t.dsc$b_dtype = DSC$K_DTYPE_T;
+
+ /* The 3 low-order bits of stat are
+ 0 (warning),
+ 1 (success),
+ 2 (error),
+ 3 (information), or
+ 4 (severe or fatal error)
+ Consider values of 0, 1, or 3 to be success. LIB$SPAWN
+ will usually return SS$_NORMAL, independent of the value
+ of stat.
+ */
+
+ if (LIB$SPAWN(&t,0,0,0,0,0,&stat) != SS$_NORMAL)
+ return (127);
+ switch (stat & 7)
+ {
+ case 0:
+ case 1:
+ case 3:
+ return (0);
+ default:
+ return (127);
+ }
+
+
+[07-Mar-88]
+ Changed type of main() in keytst.c and lptops.c
+ from void to int, and inserted return(0) at end
+ to keep lint and VAX VMS C compiler happy. Draft
+ ANSI C (Oct-86 and Jan-88) does not specify what
+ the type of main() should be, and most compilers
+ don't care. VMS C 2.3 however produces an
+ annoying warning message if main() is not of type
+ int; I view this behavior as erroneous, because
+ main() is only a convention in C, and it is
+ possible to write C programs in many
+ implementations that do not have a main().
+
+[02-Mar-88]
+ Added code to findpost.h to ignore trailing NULs
+ in a .DVI file, borrowing code from readpxl.h and
+ readgf.h that do the same thing for font files.
+ Users (including me) have been annoyed by the
+ inability of the drivers to handle a .DVI file
+ which has passed through a VAX VMS system where
+ gratuitous NULs are appended to pad the file
+ length to a multiple of 512 bytes.
+
+ This effort revealed another problem under VAX
+ VMS, and that is that the code in FSEEK() in
+ vaxvms.c on a request to position at end-of-file
+ actually positions before the last character,
+ instead of after it. An attempt at correcting
+ this was foiled by the VMS library ftell() which
+ returns 0 when the position set by FSEEK() is
+ outside the actual file limits, and while FTELL()
+ can correct the brain-damaged value returned by
+ ftell(), it cannot distinguish a nonsensical 0
+ result from ftell() at end-of-file from one at
+ the beginning of the file. Consequently, it has
+ been necessary in findpost.h to bump the
+ postambleptr value by one.
+
+ Since this modification can be installed
+ independently in even old versions of the DVI
+ driver family, and a context difference listing
+ is larger than findpost.h, here is the complete
+ new version:
+
+/* -*-C-*- findpost.h */
+/*-->findpost*/
+/**********************************************************************/
+/****************************** findpost ******************************/
+/**********************************************************************/
+
+void
+findpost()
+
+{
+ register long postambleptr;
+ register BYTE i;
+ register UNSIGN16 the_char; /* loop index */
+
+ (void) FSEEK (dvifp, 0L, 2); /* goto end of file */
+
+ /* VAX VMS binary files are stored with NUL padding to the next
+ 512 byte multiple. We therefore search backwards to the last
+ non-NULL byte to find the real end-of-file, then move back from
+ that. Even if we are not on a VAX VMS system, the DVI file might
+ have passed through one on its way to the current host, so we
+ ignore trailing NULs on all machines. */
+
+ while (FSEEK(dvifp,-1L,1) == 0)
+ {
+ the_char = (UNSIGN16)fgetc(dvifp);
+ if (the_char)
+ break; /* exit leaving pointer PAST last non-NUL */
+ UNGETC((char)the_char,dvifp);
+ }
+
+ postambleptr = FTELL(dvifp) - 4;
+
+#if OS_VAXVMS
+ /* There is a problem with FSEEK() that I cannot fix just now. A
+ request to position to end-of-file cannot be made to work correctly,
+ so FSEEK() positions in front of the last byte, instead of past it.
+ We therefore modify postambleptr accordingly to account for this. */
+
+ postambleptr++;
+#endif
+
+ (void) FSEEK (dvifp, postambleptr, 0);
+ while (TRUE)
+ {
+ (void) FSEEK (dvifp, --(postambleptr), 0);
+ if (((i = (BYTE)nosignex(dvifp,(BYTE)1)) != 223) &&
+ (i != DVIFORMAT))
+ (void)fatal("findpost(): Bad end of DVI file");
+ if (i == DVIFORMAT)
+ break;
+ }
+ (void) FSEEK (dvifp, postambleptr - 4, 0);
+ (void) FSEEK (dvifp, (long)nosignex(dvifp,(BYTE)4), 0);
+}
+
+[20-Feb-88]
+ We have uncovered a bug in the public-domain
+ multi-operating-system make utility, pdmake.
+ When a file in a dependent list must itself be
+ built by application of a rule, the value of $<
+ gets changed to reflect that new file, but is
+ subsequently not restored to its value for the
+ original target file. Make will then apply the
+ rule for the target file, but use the wrong file
+ name. This situation never occurred before,
+ because dependent files are usually just include
+ files, which never have to be built by
+ application of a rule. The workaround in such a
+ case is to replace use of $< in a rule by
+ $*.suffix.
+
+ Here is a simple makefile that illustrates the
+ bug:
+
+DEBUG = /NOTRACE /NODEBUG
+BFLAGS = /NOLIST $(DEBUG)
+
+.SUFFIXES: .obj .l32 .b32 .r32
+
+.b32.obj:
+ echo
+ echo '.B32.OBJ:'
+ echo '$$@' = [$@]
+ echo '$$*' = [$*]
+ echo '$$<' = [$<]
+ echo '$$?' = [$?]
+ bliss $(BFLAGS) /OBJECT=$*.obj $<
+
+.r32.l32:
+ echo
+ echo '.R32.L32:'
+ echo '$$@' = [$@]
+ echo '$$*' = [$*]
+ echo '$$<' = [$<]
+ echo '$$?' = [$?]
+ bliss /library=$*.l32 $<
+
+ftp_user.obj: ftp.l32 cli.l32
+
+ To try it, create 3 empty files: cli.r32,
+ ftp.r32, and ftp_user.b32, and then type "make
+ -n". Unix make will correctly say
+
+ echo '$<' = [ftp_user.b32]
+
+ while pdmake will incorrectly say
+
+ echo '$<' = [cli.r32]
+
+ If the .b32.obj rule is changed to replace $< by
+ $*.b32, pdmake will work correctly.
+
+ Unfortunately, after spending a day and a half on
+ this bug, I cannot offer a program correction to
+ fix it, and I cannot spend more time on it.
+ Volunteer efforts are welcome.
+
+ The call sequence is such that make() calls
+ dyndep() which sets $< in a call to setmacro(),
+ then make() calls make1() which calls docmd2()
+ which calls expand() which then substitutes for
+ $<. If a file in the dependency list must be
+ made, make() will call itself recursively before
+ calling make1(), and that call substitutes a new
+ value of $<. The problem is that the code in
+ dyndep() to set $< cannot be used directly in
+ make1() before the docmd2() call, because at that
+ point, a rule is not being expanded, and a change
+ to $< would require knowledge about the files
+ which does not seem to be available there.
+
+[06-Feb-88]
+ Revised lpt.ps to handle formfeed and tabs.
+
+[03-Feb-88]
+ Alfred Ganz (ganz-alfred@yale.arpa) has been
+ updating the catdvi program which converts Unix
+ troff C/A/T output to a TeX DVI file; the
+ existing version only knows about the very old
+ DVI format version 1. In doing so, he found a
+ bug in setchar() in dvialw.c. DVI files output
+ by TeX normally will not cause setchar() to be
+ entered. There is a missing close parenthesis
+ that should have been output about line 106 in
+ setchar(). Here is a Unix context difference
+ (diff -c) listing; '+' marks the inserted line.
+
+*** dvialw.c,78 Sun Nov 1 11:21:38 1987
+--- dvialw.c Wed Feb 3 16:38:28 1988
+***************
+*** 1080,1085 ****
+--- 1080,1086 ----
+ }
+ OUT_CHR('(');
+ OUT_XCHR(c);
++ OUT_CHR(')');
+ if (ycp != str_ycp)
+ {
+ OUT_NUM(xcp);
+
+
+[03-Feb-88] {Adobe Transcript warning}
+ Alfred Ganz (ganz-alfred@yale.arpa) reports that
+ the Adobe Transcript spooler on his machine does
+ not do page accounting correctly when the input
+ file contains a Ctl-D (the last character
+ produced by dvialw). That character is there to
+ signal end-of-job to the printer; although it
+ would normally be supplied by a spooler program,
+ dvialw is used on many machines (e.g. IBM PC)
+ with less sophisticated connections to the
+ printer, and it therefore supplies the Ctl-D
+ itself. If you are using Transcript, check the
+ accounting records it creates, and if necessary,
+ comment out the final line
+
+ OUT_CHR('\004'); /* PostScript end-of-job signal */
+
+ in devterm() in dvialw.c. A similar patch should
+ be applied to lptops.c; look for the line
+
+ if (putchar('\004') == EOF) /* CTL-D for EOF signal */
+
+ and change it to output a newline ('\n') instead.
+
+[25-Jan-88]
+ A couple of users have commented on the slow
+ speed and large output file sizes of dvil3p for
+ the DEC LN03+. The contributor, John Sauter
+ (sauter%dssdev.DEC@decwrl.dec.com), clarifies:
+
+ ``Yes, it does create bitmaps. If you have an
+ LN03-PLUS but no font cartridges DVIL3P will
+ work, whereas DVI2LN3 (Flavio Rose's program)
+ requires at least one font RAM cartridge but does
+ not require the upgrade to full graphics (LN03 to
+ LN03-PLUS).''
+
+ It would clearly be desirable to have another
+ version that supported a downloaded font
+ mechanism like the Flavio Rose driver.
+ Volunteers, anyone? I have no LN03 access
+ locally to do it myself.
+
+[20-Jan-88] {VAX VMS Warning}
+ I have observed that under VAX VMS, when a font
+ substitution file is used, the drivers may issue
+ the following (spurious) message:
+
+%fontsub(): Bad font substitution at line 3 in file [TEX_INPUTS:texfonts.sub]:
+[SYS$INPUT]
+Current TeX page counters: [0]
+
+ They then continue correctly with the requested
+ substitution:
+
+%Substituting font file [amcsc10 [mag 1369]] by [SYS$TEX:[TEX.CM.274]cmcsc10.pk
+[mag 1369]]
+Current TeX page counters: [0]
+
+ Simply relinking the program (WITHOUT
+ recompilation) with the debugger and running it
+ again causes the message to disappear. I am
+ therefore inclined to suspect a VMS code
+ generation error; since the message is harmless,
+ I do not propose to investigate it further.
+ Since VMS lacks the ability to insert a debugger
+ into the address space at run-time, like TOPS-20
+ can, it would be very difficult to track down
+ this error; the above output indicates that the
+ current input line read "SYS$INPUT", when in fact
+ no such string is found in texfonts.sub.
+
+[13-Jan-88]
+ TEXIDX.C needs some changes to work correctly
+ under VAX VMS because of flaws in the VMS
+ library. Somehow it got overlooked for testing.
+ Here is a Unix context difference listing of the
+ changes (diff -c old new):
+
+*** texidx.c,13 Sat Nov 14 23:21:38 1987
+--- texidx.c Wed Jan 13 11:51:49 1988
+***************
+*** 51,56 ****
+--- 51,59 ----
+ #include <stdio.h>
+ #include <ctype.h>
+
++ #define READ read
++ #define EXIT exit
++
+ #ifdef KCC_20
+ #include <file.h>
+ #define tops20
+***************
+*** 57,62 ****
+--- 60,69 ----
+ #else
+ #ifdef OS_VAXVMS
+ #include <file.h>
++ #undef READ
++ #define READ vms_read
++ #undef EXIT
++ #define EXIT vms_exit
+ #else
+ #ifdef OS_ATARI
+ #else
+***************
+*** 413,419 ****
+ }
+
+ flush_tempfiles (tempcount);
+! exit (0);
+ }
+
+ /* This page decodes the command line arguments to set the parameter variables
+--- 420,426 ----
+ }
+
+ flush_tempfiles (tempcount);
+! EXIT (0);
+ }
+
+ /* This page decodes the command line arguments to set the parameter variables
+***************
+*** 1027,1033 ****
+
+ if (desc < 0)
+ fatal ("failure reopening %s", infile);
+! file_size = read (desc, data, total);
+ file_data = data;
+ data[file_size] = 0;
+
+--- 1034,1040 ----
+
+ if (desc < 0)
+ fatal ("failure reopening %s", infile);
+! file_size = READ (desc, data, total);
+ file_data = data;
+ data[file_size] = 0;
+
+***************
+*** 1676,1682 ****
+ char *s1, *s2;
+ {
+ error (s1, s2);
+! exit (1);
+ }
+
+ /* Print error message. `s1' is printf control string, `s2' is arg for it. */
+--- 1683,1690 ----
+ char *s1, *s2;
+ {
+ error (s1, s2);
+!
+! EXIT (1);
+ }
+
+ /* Print error message. `s1' is printf control string, `s2' is arg for it. */
+-------
diff --git a/dviware/beebe/updates/00mail.17 b/dviware/beebe/updates/00mail.17
new file mode 100644
index 0000000000..b96af76798
--- /dev/null
+++ b/dviware/beebe/updates/00mail.17
@@ -0,0 +1,146 @@
+31-May-88 18:41:51-MDT,5098;000000000000
+Date: Tue 31 May 88 18:41:51-MDT
+From: "Nelson H.F. Beebe" <Beebe@SCIENCE.UTAH.EDU>
+Subject: DVI driver family update #17
+To: "DVI mailing list part 2": ;
+cc: BEEBE@SCIENCE.UTAH.EDU
+X-US-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112"
+X-Telephone: (801) 581-5254
+Message-ID: <12402826690.23.BEEBE@SCIENCE.UTAH.EDU>
+
+ DVI Driver Family Update #17
+ [31-May-88]
+
+
+=============
+A SHORT FLASH
+=============
+
+I thought that #16 [26-May-88] would be the last issue until
+early fall, but I just discovered that an important bug in dvialw
+found on February did not get recorded in the change file, and so
+did not make it into the newsletter. The day after posting #16,
+Jerry Leichter and I solved a long-standing bug in dvijep. Here
+are the change log entries.
+
+[30-May-88] {Thanks to Jerry Leichter (LEICHTER@Venus.YCC.Yale.Edu)
+ for providing an example that exposed this bug.}
+ In dvijep.c, rules are output one dot too high.
+ According to the HP documentation, the position
+ of a rule is the upper-left corner. I took this
+ to mean that the rule would be output starting
+ just under the pixel at (x,y) in that corner.
+ What they must mean is that (x,y) is the position
+ of the pixel in the upper-left corner of the
+ filled area. Change the definitions of RULE()
+ and RULE2() about line 160 to reduce the height
+ value by 1 in the arguments to MOVETO():
+
+diff -c dvijep.c,75 dvijep.c
+*** dvijep.c,75 Wed May 18 09:42:01 1988
+--- dvijep.c Mon May 30 19:03:07 1988
+***************
+*** 162,174 ****
+ lower-left corner, while the LaserJet Plus uses the upper-left corner.
+ */
+ #define RULE(x,y,width,height) {\
+! MOVETO(x,(y)+height);PUTESC;\
+ sprintf(plotfs,"*c%da%dbP",width,height); OUTST(plotfs);\
+ }
+ /* Set rule of same size as previous one at TeX position (x,y). The
+ device coordinates will be changed on completion. */
+ #define RULE2(x,y) {\
+! MOVETO(x,(y)+rule_height);\
+ PUTESC;OUTST("*cP");\
+ }
+ /* Set the current font and character in preparation for a DOWNLOADCHAR */
+--- 162,174 ----
+ lower-left corner, while the LaserJet Plus uses the upper-left corner.
+ */
+ #define RULE(x,y,width,height) {\
+! MOVETO(x,(y)+height-1);PUTESC;\
+ sprintf(plotfs,"*c%da%dbP",width,height); OUTST(plotfs);\
+ }
+ /* Set rule of same size as previous one at TeX position (x,y). The
+ device coordinates will be changed on completion. */
+ #define RULE2(x,y) {\
+! MOVETO(x,(y)+rule_height-1);\
+ PUTESC;OUTST("*cP");\
+ }
+ /* Set the current font and character in preparation for a DOWNLOADCHAR */
+
+ The same correction must be made to dvilzr.c for
+ the DataProducts laser printer.
+
+ I had previously received reports of suspicions
+ of an error in dvijep's rule positions, but no
+ one ever was able to supply an example that I
+ could reproduce locally. Here is Jerry's
+ excellent little test file:
+
+\documentstyle[12pt]{article}
+\def\vec(#1,#2){\put(0,0){\vector(#1,#2){50}}}
+\begin{document}
+
+\setlength{\unitlength}{.01in}
+\begin{picture}(0,0)(100,100)
+\vec(-1,0)
+\vec(1,0)
+\vec(0,1)
+\vec(0,-1)
+%
+\vec(-4,1)\vec(-3,1)\vec(-2,1)\vec(-1,1)
+\vec(4,1)\vec(3,1)\vec(2,1)\vec(1,1)
+%
+\vec(-3,2)\vec(-1,2)
+\vec(3,2)\vec(1,2)
+%
+\vec(-4,3)\vec(-2,3)\vec(-1,3)
+\vec(4,3)\vec(2,3)\vec(1,3)
+%
+\vec(-3,4)\vec(-1,4)
+\vec(3,4)\vec(1,4)
+%
+\vec(-4,-1)\vec(-3,-1)\vec(-2,-1)\vec(-1,-1)
+\vec(4,-1)\vec(3,-1)\vec(2,-1)\vec(1,-1)
+%
+\vec(-3,-2)\vec(-1,-2)
+\vec(3,-2)\vec(1,-2)
+%
+\vec(-4,-3)\vec(-2,-3)\vec(-1,-3)
+\vec(4,-3)\vec(2,-3)\vec(1,-3)
+%
+\vec(-3,-4)\vec(-1,-4)
+\vec(3,-4)\vec(1,-4)
+%
+\end{picture}
+\end{document}
+
+ When printed with dvialw, the two horizontal
+ rules are printed correctly; before the above
+ correction to dvijep, they were one pixel too
+ high, (this gives a visible white streak). The
+ correction should also fix the misalignment with
+ the arrowheads.
+
+[30-May-88]
+ The following bug in dvialw.c was fixed on
+ 3-Feb-88, but unfortunately didn't make it into
+ this log.
+
+diff -c dvialw.c,78 dvialw.c,79
+*** dvialw.c,78 Sun Nov 1 11:21:38 1987
+--- dvialw.c,79 Wed Feb 3 16:38:28 1988
+***************
+*** 1080,1085 ****
+--- 1080,1086 ----
+ }
+ OUT_CHR('(');
+ OUT_XCHR(c);
++ OUT_CHR(')');
+ if (ycp != str_ycp)
+ {
+ OUT_NUM(xcp);
+
+ There was a missing ')' in the output.
+-------
diff --git a/dviware/beebe/updates/00mail.2 b/dviware/beebe/updates/00mail.2
new file mode 100644
index 0000000000..6a9c864ef1
--- /dev/null
+++ b/dviware/beebe/updates/00mail.2
@@ -0,0 +1,140 @@
+18-Feb-87 09:36:42-MST,8654;000000000001
+Mail-From: BEEBE created at 18-Feb-87 09:36:40
+Date: Wed 18 Feb 87 09:36:39-MST
+From: "Nelson H.F. Beebe" <Beebe@UTAH-SCIENCE.ARPA>
+Subject: DVI driver family update #2
+To: $90%dhdurz1.bitnet@WISCVM.WISC.EDU, austins%ucbcmsa.edu@UTAH-CS.ARPA,
+ cel%cithex.caltech.edu@UTAH-CS.ARPA,
+ crawford-j%ohio_state.arpa@UTAH-CS.ARPA,
+ crm8701%tamvenus.bitnet@WISCVM.WISC.EDU,
+ gaspard%hroeur5.bitnet@WISCVM.WISC.EDU,
+ james%vaxe.coe.northeaster.edu@UTAH-CS.ARPA,
+ lamy%ai.toronto.edu@RELAY.CS.NET, mpc91b%dgogwd01.bitnet@WISCVM.WISC.EDU,
+ rjones%uwovax.bitnet@WISCVM.WISC.EDU, rs%gnome.cs.cmu.edu@UTAH-CS.ARPA,
+ stone%ruthep.rutgers.edu@UTAH-CS.ARPA,
+ system%uvphys.bitnet@WISCVM.WISC.EDU, thobe@EE.UCLA.EDU,
+ zeffi%finabo.bitnet@WISCVM.WISC.EDU
+cc: BEEBE@UTAH-SCIENCE.ARPA
+X-US-Mail: "Center for Scientific Computation, South Physics, University of Utah, Salt Lake City, UT 84112"
+X-Telephone: (801) 581-5254
+Message-ID: <12280054972.6.BEEBE@UTAH-SCIENCE.ARPA>
+
+!PS:<ANONYMOUS>00TOPS20.TXT.7, 9-Feb-87 10:32:13, Edit by BEEBE
+
+This file shows how we have setup TeX on UTAH-SCIENCE (DEC-20/60
+TOPS-20). The main TeX directory structure is identical to that
+maintained by the TeX Project at SU-SCORE, but we have numerous
+additional local directories.
+
+In SYSTEM:n-m-CONFIG.CMD (where system-wide logical names are
+conventionally defined, and n and m are major and minor Monitor release
+numbers), we have
+
+
+DEFINE DVISPOOL: TEX:NOSPOOL.EXE !Dummy .DVI file spooler
+
+DEFINE TEX: APS:<TEX> ! *.EXE files for TeX,
+ ! TeXWare and DVI drivers
+
+DEFINE TEXFORMATS: APS:<TEX.FORMATS> ! TeX and LaTeX *.FMT files
+
+DEFINE TEXFONTS: APS:<TEX.CM>,- ! CM fonts in .TFM and .PK form
+ SCRTCH:<TEX.PXL>,- ! AM fonts in .PXL form
+ SCRTCH:<TEX.FONTS> ! AM*.TFM files
+
+DEFINE TEXINPUTS: APS:<TEX.INPUTS>,-
+ APS:<TEX.LATEX>,-
+ APS:<TEX.AMSTEX>
+
+DEFINE TEXSPOOL: TEX:NOSPOOL.EXE !Dummy .DVI file spooler
+
+Users can individually redefine TEXSPOOL: to be TEX:DVIxxx.EXE for their
+preferred DVI file translator, and DVISPOOL: to be TEX:IMSPOOL.EXE
+(Imagen 3320) or TEX:PSSPOOL.EXE (PostScript (Apple LaserWriter)).
+
+Both laser printers are driven by spooler jobs running under SYSJOB
+(started by @DO OPR:--START-IM-SPOOL and @DO OPR:--START-PS-SPOOL);
+these use PCL command procedures to poll the spooler directory contents,
+print any files found there, and then sleep for a while. See
+APS:<IMAGEN.IMAGEN>*.* for the PCL files and Imagen spooler program.
+The PostScript spooler program is APS:<TEX.DVI>LW78.C. This approach is
+considerably simpler than modifying LPTSPL, although is does have a
+certain amount of polling overhead which can be reduced by making the
+sleep time longer. We have not found it objectionable in 18+ months of
+use.
+
+Here is what our TeX directory structure looks like:
+
+===========================================================================
+ 9-Feb-87 00:02:49 USED PERM WORK
+===========================================================================
+
+APS:<TEX.AMSFONTS> (742) -------------------------- 170 200 1200
+APS:<TEX.AMSTEX> (137) 185 150 300
+APS:<TEX.AMSTEX.NEW> (714) 96 200 1000
+APS:<TEX.BIBTEX> (733) ---------------------------- 203 700 2100
+APS:<TEX.CM> (630) 2956 2000 4000
+APS:<TEX.DVI> (1171) 878 2000 inf
+APS:<TEX.DVI.DOC> (1172) -------------------------- 125 200 inf
+APS:<TEX.FORMATS> (70) 233 200 400
+APS:<TEX.HP> (173) 86 100 200
+APS:<TEX.INPUTS> (131) ---------------------------- 268 100 500
+APS:<TEX.LATEX> (136) 1121 1200 3600
+APS:<TEX.LATEX.LOCAL-GUIDE> (1151) 102 200 1000
+APS:<TEX.LATEX.MF> (1153) ------------------------- 42 200 1000
+APS:<TEX.LATEX.NEW> (734) 35 2000 4000
+APS:<TEX.LATEX.OLD> (1150) 354 200 1000
+APS:<TEX.MF> (201) -------------------------------- 0 500 1000
+APS:<TEX.OLD-MF> (27) 213 220 440
+APS:<TEX.OLD-MF-LOCAL> (30) 103 100 200
+APS:<TEX.PCC> (1173) ------------------------------ 68 100 777777
+APS:<TEX.PUB> (1070) 0 400 2000
+APS:<TEX.PUB.AFM> (602) 9 200 1000
+APS:<TEX.PUB.DECUS> (434) ------------------------- 35 200 1000
+APS:<TEX.PUB.DETEX> (423) 356 200 1000
+APS:<TEX.PUB.DVI2PS> (1071) 67 200 1000
+APS:<TEX.PUB.DVITTY> (567) ------------------------ 57 200 1000
+APS:<TEX.PUB.FTP> (616) 105 200 1000
+APS:<TEX.PUB.GNU> (1147) 96 200 1000
+APS:<TEX.PUB.IDX-INDEX> (1072) -------------------- 8 200 1000
+APS:<TEX.PUB.INDEX-CITE> (1073) 8 200 1000
+APS:<TEX.PUB.LATEX-INDEX> (1074) 4 600 1800
+APS:<TEX.PUB.LATEX-INDEX.LIBGLOB> (1075) ---------- 10 200 1000
+APS:<TEX.PUB.LATEX-INDEX.LIBPROFILE> (1077) 24 200 1000
+APS:<TEX.PUB.LATEX-INDEX.LOCAL_INCLUDE> (1115) 13 200 1000
+APS:<TEX.PUB.LGRAPH> (452) ------------------------ 31 200 1000
+APS:<TEX.PUB.LN03> (1100) 173 200 1000
+APS:<TEX.PUB.MANUALFEED> (1101) 4 200 1000
+APS:<TEX.PUB.MITQMS> (1102) ----------------------- 42 200 1000
+APS:<TEX.PUB.NEWIDX> (1103) 20 200 1000
+APS:<TEX.PUB.NEWIDX.LIBTRW> (1104) 13 200 1000
+APS:<TEX.PUB.ONE_MORE_UNDUMP> (1105) -------------- 4 200 1000
+APS:<TEX.PUB.PATCH> (1106) 26 200 1000
+APS:<TEX.PUB.R2BIB> (1107) 9 200 1000
+APS:<TEX.PUB.SLITEX0> (1110) ---------------------- 4 200 1000
+APS:<TEX.PUB.SLITEX1> (1111) 25 200 1000
+APS:<TEX.PUB.SLITEX2> (1112) 21 200 1000
+APS:<TEX.PUB.SUN3-UNDUMP> (1113) ------------------ 9 200 1000
+APS:<TEX.PUB.TGRIND> (577) 33 200 1000
+APS:<TEX.PUB.TIB3> (125) 4 200 1000
+APS:<TEX.PUB.TROFF-TO-TEX> (341) ------------------ 74 600 2600
+APS:<TEX.PUB.TROFF-TO-TEX.NEW> (1354) 349 200 1000
+APS:<TEX.PUB.TROFF-TO-TEX.OLD> (1345) 76 200 1000
+APS:<TEX.PUB.UNDUMP> (1114) ----------------------- 17 200 1000
+APS:<TEX.TIB> (333) 301 inf inf
+APS:<TEX.TIB2> (737) 801 1000 3000
+APS:<TEX.TIB3> (520) ------------------------------ 311 200 1000
+APS:<TEX.WEB> (151) 1856 3200 7000
+APS:<TEX.WEB.NEW> (735) 0 200 1000
+SCRTCH:<TEX.CM> (202) 6196 5000 inf
+SCRTCH:<TEX.DOC> (203) ---------------------------- 1356 1200 inf
+SCRTCH:<TEX.FONTS> (312) 513 600 1200
+SCRTCH:<TEX.MF> (247) 2090 inf inf
+SCRTCH:<TEX.PATASHNIK> (336) ---------------------- 230 200 1000
+SCRTCH:<TEX.PXL> (311) 13391 14000 28000
+SCRTCH:<TEX.PXLHEX> (222) 50 12000 20000
+SCRTCH:<TEX.TEST> (337) --------------------------- 183 200 1000
+SCRTCH:<TEX.WEB> (35) 0 250 250
+SCRTCH:<TEX.WEB.OLD> (36) 554 600 1000
+===========================================================================
+-------
diff --git a/dviware/beebe/updates/00mail.3 b/dviware/beebe/updates/00mail.3
new file mode 100644
index 0000000000..bc10067765
--- /dev/null
+++ b/dviware/beebe/updates/00mail.3
@@ -0,0 +1,252 @@
+18-Feb-87 09:37:14-MST,10470;000000000001
+Mail-From: BEEBE created at 18-Feb-87 09:37:11
+Date: Wed 18 Feb 87 09:37:10-MST
+From: "Nelson H.F. Beebe" <Beebe@UTAH-SCIENCE.ARPA>
+Subject: DVI driver update #3
+To: $90%dhdurz1.bitnet@WISCVM.WISC.EDU, austins%ucbcmsa.edu@UTAH-CS.ARPA,
+ cel%cithex.caltech.edu@UTAH-CS.ARPA,
+ crawford-j%ohio_state.arpa@UTAH-CS.ARPA,
+ crm8701%tamvenus.bitnet@WISCVM.WISC.EDU,
+ gaspard%hroeur5.bitnet@WISCVM.WISC.EDU,
+ james%vaxe.coe.northeaster.edu@UTAH-CS.ARPA,
+ lamy%ai.toronto.edu@RELAY.CS.NET, mpc91b%dgogwd01.bitnet@WISCVM.WISC.EDU,
+ rjones%uwovax.bitnet@WISCVM.WISC.EDU, rs%gnome.cs.cmu.edu@UTAH-CS.ARPA,
+ stone%ruthep.rutgers.edu@UTAH-CS.ARPA,
+ system%uvphys.bitnet@WISCVM.WISC.EDU, thobe@EE.UCLA.EDU,
+ zeffi%finabo.bitnet@WISCVM.WISC.EDU
+cc: BEEBE@UTAH-SCIENCE.ARPA
+X-US-Mail: "Center for Scientific Computation, South Physics, University of Utah, Salt Lake City, UT 84112"
+X-Telephone: (801) 581-5254
+Message-ID: <12280055066.6.BEEBE@UTAH-SCIENCE.ARPA>
+
+!PS:<ANONYMOUS>00VMSSETUP.TXT.1, 9-Feb-87 09:50:01, Edit by BEEBE
+
+This file shows how we have set up TeX on UTAH-CSC (VAX 8600 VMS 4.4)
+with the Kellerman & Smith Imprint driver and TeX implementation. The
+DVI driver family needs to have foreign command symbols created for each
+.EXE file. For example, you might put lines like this
+
+ $ DVIALW :== $SYS$TEX:[TEX]DVIALW.EXE
+
+in a command file referenced in SYS$MANAGER:SYLOGIN.COM.
+
+type lib:[tex]define.com
+
+$ ! SYS$LIBROOT:[TEX]DEFINE.COM, Thu Dec 18 11:03:33 1986, Edit by BEEBE (at VAX
+-VMS)
+$ ! Make define/system after installation complete
+$ defsys :== define/nolog/system
+$
+$ ! New version on PS:
+$ defsys sys$tex sys$libroot:
+$
+$ ! Put [.amstex] and [.latex] first to override old stuff in [.inputs]
+$ defsys tex_inputs sys$tex:[tex.latex], -
+ sys$tex:[tex.amstex], -
+ sys$tex:[tex.inputs]
+$ defsys tex_fonts sys$tex:[tex.cm]
+$ defsys tex_formats sys$tex:[tex.formats]
+$ defsys tex_output texput
+
+type lib:[imprint]*.com
+
+SYS$LIBROOT:[IMPRINT]INSTALL.COM;6
+
+$ !=====================================================================
+$ ! Install IMPRINT spooler on system (do only once)
+$ !=====================================================================
+$ define imp sys$libroot:[imprint]
+$ set command /tables=sys$library:dcltables -
+ /output=sys$library:dcltables -
+ imp:imprint.cld
+$ set process/privilege=cmkrnl
+$ library/replace/help sys$help:helplib imp:imprint.hlp
+$ run sys$system:install
+sys$library:dcltables/replace
+/exit
+$ ! copy imprint.fmt sys$manager:
+$ ! define/system imp_formats sys$manager:
+$ define/system imp_formats sys$libroot:[imprint]
+$ define/system imp_fonts sys$libroot:[imprint.fonts]
+
+SYS$LIBROOT:[IMPRINT]SHUTIMAGEN.COM;2
+
+$ !=====================================================================
+$ ! Shutdown the Imagen 8/300 queue
+$ !=====================================================================
+$ set noon
+$ stop /next /queue sys$imagen
+$ delete/queue sys$imagen
+$ set device /nospooled sys$imagen
+
+SYS$LIBROOT:[IMPRINT]STARTIMAGEN.COM;6
+
+$ !=====================================================================
+$ ! Start IMPRINT spooler
+$ !=====================================================================
+$ define/system sys$imagen txa0:
+$ define/system imp_formats sys$libroot:[imprint]
+$ define/system imp_fonts sys$libroot:[imprint.fonts]
+$ reply/enable=printer
+$ set term sys$imagen -
+ /permanent -
+ /nowrap -
+ /speed=19200
+$ set device/spooled sys$imagen
+$ initialize /queue -
+ /term -
+ /proc=imprint -
+ /default=(feed,flag) -
+ /start -
+ sys$imagen
+$ ! Print test file.
+$ ! imprint imp_formats:imprint.fmt
+
+
+$ cd lib:[imprint]
+$ @mgr:dirtree
+Output File: tt:
+
+ Your Directory Structure. One moment please...
+
+ IMPRINT
+ ^-----FONTS
+ ^-----1200
+ ^-----1440
+
+$ cd lib:[tex]
+$ @mgr:dirtree
+Output File: tt:
+
+ Your Directory Structure. One moment please...
+
+ TEX
+ ^-----AM
+ ^-----1000
+ ^-----1095
+ ^-----1200
+ ^-----1315
+ ^-----1440
+ ^-----1500
+ ^-----1643
+ ^-----1728
+ ^-----1800
+ ^-----2074
+ ^-----2160
+ ^-----2400
+ ^-----2488
+ ^-----2592
+ ^-----2628
+ ^-----2880
+ ^-----2986
+ ^-----3110
+ ^-----3456
+ ^-----3732
+ ^-----4479
+ ^-----AMSTEX
+ ^-----BIBTEX
+ ^-----CM
+ ^-----100
+ ^-----1075
+ ^-----121
+ ^-----1290
+ ^-----145
+ ^-----1548
+ ^-----174
+ ^-----208
+ ^-----240
+ ^-----250
+ ^-----274
+ ^-----300
+ ^-----329
+ ^-----360
+ ^-----432
+ ^-----518
+ ^-----622
+ ^-----746
+ ^-----896
+ ^-----DOC
+ ^-----FORMATS
+ ^-----HP
+ ^-----INPUTS
+ ^-----LATEX
+ ^-----LTXGDE
+ ^-----ROCHESTER
+ ^-----SVI
+ ^-----TEX
+ ^-----TEXWARE
+ ^-----TRIP
+ ^-----WEB
+
+$ dir tex_fonts
+
+Directory SYS$LIBROOT:[TEX.CM]
+
+00HEXBIN.COM;3 00HEXCHK.COM;2 00RENAME.COM;2 00TEST.COM;2
+100.DIR;1 1075.DIR;1 121.DIR;1 1290.DIR;1
+145.DIR;1 1548.DIR;1 174.DIR;1 208.DIR;1
+240.DIR;1 250.DIR;1 274.DIR;1 300.DIR;1
+329.DIR;1 360.DIR;1 432.DIR;1 518.DIR;1
+622.DIR;1 746.DIR;1 896.DIR;1 AMR10.TFM;1
+CIRCLE10.TFM;1 CIRCLEW10.TFM;1 CMB10.TFM;1 CMBSY10.TFM;1
+CMBX10.TFM;1 CMBX12.TFM;1 CMBX5.TFM;1 CMBX6.TFM;1
+CMBX7.TFM;1 CMBX8.TFM;1 CMBX9.TFM;1 CMBXSL10.TFM;1
+CMBXTI10.TFM;1 CMCSC10.TFM;1 CMDUNH10.TFM;1 CMDUNH10.TFMHEX;1
+CMEX10.TFM;1 CMFF10.TFM;1 CMFIB8.TFM;1 CMINCH.TFM;1
+CMMI10.TFM;1 CMMI12.TFM;1 CMMI5.TFM;1 CMMI6.TFM;1
+CMMI7.TFM;1 CMMI8.TFM;1 CMMI9.TFM;1 CMMIB10.TFM;1
+CMR10.TFM;1 CMR12.TFM;1 CMR17.TFM;1 CMR5.TFM;1
+CMR6.TFM;1 CMR7.TFM;1 CMR8.TFM;1 CMR9.TFM;1
+CMSL10.TFM;1 CMSL12.TFM;1 CMSL8.TFM;1 CMSL9.TFM;1
+CMSLTT10.TFM;1 CMSS10.TFM;1 CMSS12.TFM;1 CMSS17.TFM;1
+CMSS8.TFM;1 CMSS9.TFM;1 CMSSBX10.TFM;1 CMSSDC10.TFM;1
+CMSSI10.TFM;1 CMSSI12.TFM;1 CMSSI17.TFM;1 CMSSI8.TFM;1
+CMSSI9.TFM;1 CMSSQ8.TFM;1 CMSSQI8.TFM;1 CMSY10.TFM;1
+CMSY5.TFM;1 CMSY6.TFM;1 CMSY7.TFM;1 CMSY8.TFM;1
+CMSY9.TFM;1 CMTCSC10.TFM;1 CMTEX10.TFM;1 CMTEX8.TFM;1
+CMTEX9.TFM;1 CMTI10.TFM;1 CMTI12.TFM;1 CMTI7.TFM;1
+CMTI8.TFM;1 CMTI9.TFM;1 CMTT10.TFM;1 CMTT12.TFM;1
+CMTT8.TFM;1 CMTT9.TFM;1 CMU10.TFM;1 CMVTT10.TFM;1
+DOC.TFM;1 DUMMY.TFM;1 FONTTEST.COM;2 FONTTEST.LOG;1
+FONTTEST.TEX;1 ICMEX10.TFM;1 ICMMI8.TFM;1 ICMSY8.TFM;1
+ICMTT8.TFM;1 ILASY8.TFM;1 ILCMSS8.TFM;1 ILCMSSB8.TFM;1
+ILCMSSI8.TFM;1 LASY10.TFM;1 LASY5.TFM;1 LASY6.TFM;1
+LASY7.TFM;1 LASY8.TFM;1 LASY9.TFM;1 LASYB10.TFM;1
+LCMSS8.TFM;1 LCMSSB8.TFM;2 LCMSSI8.TFM;1 LINE10.TFM;1
+LINEW10.TFM;1 LOGO10.TFM;1 LOGO8.TFM;1 LOGO9.TFM;1
+LOGOBF10.TFM;1 LOGOSL10.TFM;1 MANFNT.TFM;1 TESTFONT.COM;11
+TESTFONT.LIS;1
+
+Total of 133 files.
+
+$ dir sys$tex:[tex.cm.300]
+
+Directory SYS$LIBROOT:[TEX.CM.300]
+
+CIRCLE10.PK;2 CIRCLEW10.PK;2 CMB10.PK;2 CMBSY10.PK;2
+CMBX10.PK;4 CMBX12.PK;2 CMBX5.PK;2 CMBX6.PK;2
+CMBX7.PK;2 CMBX8.PK;2 CMBX9.PK;2 CMBXSL10.PK;2
+CMBXTI10.PK;2 CMCSC10.PK;2 CMDUNH10.PK;2 CMEX10.PK;2
+CMFF10.PK;2 CMFIB8.PK;2 CMINCH.PK;2 CMMI10.PK;2
+CMMI12.PK;2 CMMI5.PK;2 CMMI6.PK;2 CMMI7.PK;2
+CMMI8.PK;2 CMMI9.PK;2 CMMIB10.PK;2 CMR10.300GFHEX;1
+CMR10.GF;1 CMR10.PK;3 CMR12.PK;2 CMR17.PK;2
+CMR5.PK;2 CMR6.PK;2 CMR7.PK;2 CMR8.PK;2
+CMR9.PK;2 CMSL10.PK;3 CMSL12.PK;2 CMSL8.PK;2
+CMSL9.PK;2 CMSLTT10.PK;2 CMSS10.PK;2 CMSS12.PK;2
+CMSS17.PK;2 CMSS8.PK;2 CMSS9.PK;2 CMSSBX10.PK;2
+CMSSDC10.PK;2 CMSSI10.PK;2 CMSSI12.PK;2 CMSSI17.PK;2
+CMSSI8.PK;2 CMSSI9.PK;2 CMSSQ8.PK;2 CMSSQI8.PK;2
+CMSY10.PK;2 CMSY5.PK;2 CMSY6.PK;2 CMSY7.PK;2
+CMSY8.PK;2 CMSY9.PK;2 CMTCSC10.PK;2 CMTEX10.PK;2
+CMTEX8.PK;2 CMTEX9.PK;2 CMTI10.PK;2 CMTI12.PK;2
+CMTI7.PK;2 CMTI8.PK;2 CMTI9.PK;2 CMTT10.PK;2
+CMTT12.PK;2 CMTT8.PK;2 CMTT9.PK;2 CMU10.PK;2
+CMVTT10.PK;2 LASY10.PK;2 LASY5.PK;4 LASY6.PK;2
+LASY7.PK;2 LASY8.PK;2 LASY9.PK;2 LASYB10.PK;2
+LINE10.PK;1 LINEW10.PK;1 LOGO10.PK;1 LOGO8.PK;1
+LOGO9.PK;1 LOGOBF10.PK;1 LOGOSL10.PK;1 MANFNT.PK;1
+
+Total of 92 files.
+
+-------
diff --git a/dviware/beebe/updates/00mail.4 b/dviware/beebe/updates/00mail.4
new file mode 100644
index 0000000000..1500180169
--- /dev/null
+++ b/dviware/beebe/updates/00mail.4
@@ -0,0 +1,65 @@
+25-Feb-87 11:33:35-MST,3082;000000000000
+Mail-From: BEEBE created at 25-Feb-87 11:33:31
+Date: Wed 25 Feb 87 11:33:31-MST
+From: "Nelson H.F. Beebe" <Beebe@UTAH-SCIENCE.ARPA>
+Subject: DVI driver update #4
+To: $90%dhdurz1.bitnet@WISCVM.WISC.EDU, austins%ucbcmsa.edu@UTAH-CS.ARPA,
+ cel@CITHEX.CALTECH.EDU, crawford-j%ohio-state.arpa@UTAH-CS.ARPA,
+ crm8701%tamvenus.bitnet@WISCVM.WISC.EDU,
+ david%ci-dandelion.uucp@EDDIE.MIT.EDU,
+ gaspard%hroeur5.bitnet@WISCVM.WISC.EDU,
+ james%vaxe.coe.northeastern.edu@UTAH-CS.ARPA,
+ lamy%ai.toronto.edu@RELAY.CS.NET, mpc91b%dgogwd01.bitnet@WISCVM.WISC.EDU,
+ rjones%uwovax.bitnet@WISCVM.WISC.EDU, rs%gnome.cs.cmu.edu@UTAH-CS.ARPA,
+ stone%ruthep.rutgers.edu@UTAH-CS.ARPA,
+ system%uvphys.bitnet@WISCVM.WISC.EDU, thobe@EE.UCLA.EDU,
+ x854%ddagsi3.bitnet@WISCVM.WISC.EDU, zeffi%finabo.bitnet@WISCVM.WISC.EDU
+cc: BEEBE@UTAH-SCIENCE.ARPA
+X-US-Mail: "Center for Scientific Computation, South Physics, University of Utah, Salt Lake City, UT 84112"
+X-Telephone: (801) 581-5254
+Message-ID: <12281911255.16.BEEBE@UTAH-SCIENCE.ARPA>
+
+Yesterday, we hit yet another problem with VMS C, and today
+I found a workaround. The symptom was that the PostScript
+macros prefixed to the .dvi-alw output file were truncated.
+I recompiled DVIALW with the debugger this morning, and
+single-stepped it through cppsfile(), verifying that all the
+macros got written. When I examined the output file
+closely, it found that the truncation point was exactly
+after character number 2048, which is an extremely
+suspicious number, being a power of two, and a multiple of
+the VMS file blocksize.
+
+I haven't time now to step around in the library to find out
+why it is happening, but I have found a workaround. In
+dviinit.h, I had arranged for the output file to be opened
+in fixed-block binary mode, since that was required by the
+Kellerman & Smith spooler program which drives our Imagen.
+By reverting to stream-lf form for all by the Imagen, the
+problem disappears in the PostScript output, and it prints
+correctly. Here is the relevant section of dviinit.h:
+
+#if OS_VAXVMS
+ /* Create fixed-length binary 512-byte instead of stream organization
+ so Kellerman & Smith IMPRINT spooler will handle it. */
+#if IMPRESS
+ plotfp = FOPEN(dvoname,"wb","rfm=fix","bls=512","mrs=512");
+#else
+ plotfp = FOPEN(dvoname,"wb");
+#endif
+#else
+ plotfp = FOPEN(dvoname,"wb");
+#endif
+
+It is possible that this will break some of the other
+drivers, but since the only output device I have attached to
+the VAX 8600 is the Imagen 8/300, it is hard to test. Our
+present FTP on the VAX is very poor and it is very difficult
+to transfer files to another machine without gratuitous
+insertion of CRLF pairs every so often, or other fiddling
+with the binary data. An FTP replacement from CMU should be
+installed soon, but until then, it will not be feasible for
+me to really check the output from the VAX.
+
+Feedback from user sites is therefore most welcome.
+-------
diff --git a/dviware/beebe/updates/00mail.5 b/dviware/beebe/updates/00mail.5
new file mode 100644
index 0000000000..7ccd559366
--- /dev/null
+++ b/dviware/beebe/updates/00mail.5
@@ -0,0 +1,35 @@
+26-Feb-87 13:46:28-MST,1632;000000000000
+Mail-From: BEEBE created at 26-Feb-87 13:46:24
+Date: Thu 26 Feb 87 13:46:24-MST
+From: "Nelson H.F. Beebe" <Beebe@UTAH-SCIENCE.ARPA>
+Subject: DVI family update #5
+To: $90%dhdurz1.bitnet@WISCVM.WISC.EDU, austins%ucbcmsa.edu@UTAH-CS.ARPA,
+ cel@CITHEX.CALTECH.EDU, crawford-j%ohio-state.arpa@UTAH-CS.ARPA,
+ crm8701%tamvenus.bitnet@WISCVM.WISC.EDU,
+ david%ci-dandelion.uucp@EDDIE.MIT.EDU,
+ gaspard%hroeur5.bitnet@WISCVM.WISC.EDU,
+ james%vaxe.coe.northeastern.edu@UTAH-CS.ARPA,
+ lamy%ai.toronto.edu@RELAY.CS.NET, mpc91b%dgogwd01.bitnet@WISCVM.WISC.EDU,
+ rjones%uwovax.bitnet@WISCVM.WISC.EDU, rs%gnome.cs.cmu.edu@UTAH-CS.ARPA,
+ stone%ruthep.rutgers.edu@RUTGERS.RUTGERS.EDU,
+ system%uvphys.bitnet@WISCVM.WISC.EDU, thobe@EE.UCLA.EDU,
+ x854%ddagsi3.bitnet@WISCVM.WISC.EDU, zeffi%finabo.bitnet@WISCVM.WISC.EDU
+cc: BEEBE@UTAH-SCIENCE.ARPA
+X-US-Mail: "Center for Scientific Computation, South Physics, University of Utah, Salt Lake City, UT 84112"
+X-Telephone: (801) 581-5254
+Message-ID: <12282197588.22.BEEBE@UTAH-SCIENCE.ARPA>
+
+In dispchar.h, change the line
+
+ rightones[HOST_WORD_SIZE - 1 - bits_to_next] &
+to
+ rightones[bits_to_next] &
+
+This code is not active for non 32-bit machines, or the IBM
+PC, and the local 32-bit Unix machines running the driver
+family have been using only the laser printer members, so
+the bug was not caught until we actually tried DVIPRX output
+under VAX VMS. The effect it has is that large vertical
+white streaks appear in the output bitmap; dispchar() is
+used by all the low-resolution dot matrix printers.
+-------
diff --git a/dviware/beebe/updates/00mail.6 b/dviware/beebe/updates/00mail.6
new file mode 100644
index 0000000000..6cdb261863
--- /dev/null
+++ b/dviware/beebe/updates/00mail.6
@@ -0,0 +1,128 @@
+ 4-Mar-87 18:29:46-MST,5297;000000000000
+Mail-From: BEEBE created at 4-Mar-87 18:29:43
+Date: Wed 4 Mar 87 18:29:43-MST
+From: "Nelson H.F. Beebe" <Beebe@UTAH-SCIENCE.ARPA>
+Subject: DVI driver update #6
+To: $90%dhdurz1.bitnet@WISCVM.WISC.EDU, AustinS%ucbcmsa.edu@UTAH-CS.ARPA,
+ Berg-lists%gsb-why@SCORE.STANFORD.EDU, CEL@CITHEX.CALTECH.EDU,
+ Celoni@SCORE.STANFORD.EDU, Crawford-J%ohio-state.arpa@UTAH-CS.ARPA,
+ CRM8701%tamvenus.bitnet@WISCVM.WISC.EDU,
+ Dan%buchmd.bu-cs.arpa@UTAH-CS.ARPA, David%ci-dandelion.uucp@EDDIE.MIT.EDU,
+ Gaspard%hroeur5.bitnet@WISCVM.WISC.EDU,
+ Goodall%admin.okanagan.bcc.cdn@RELAY.CS.NET,
+ James%vaxe.coe.northeastern.edu@UTAH-CS.ARPA,
+ JRP%nplpsg.uucp@UTAH-CS.ARPA, Karney%ppc.mfenet@NMFECC.ARPA,
+ Lamy%ai.toronto.edu@RELAY.CS.NET, MPC91B%dgogwd01.bitnet@WISCVM.WISC.EDU,
+ RJones%uwovax.bitnet@WISCVM.WISC.EDU, RS%gnome.cs.cmu.edu@UTAH-CS.ARPA,
+ Simon%m_scrvx2%slb-test.csnet.csnet-relay@CSNET-RELAY.ARPA,
+ Stone%ruthep.rutgers.edu@RUTGERS.RUTGERS.EDU,
+ System%uvphys.bitnet@WISCVM.WISC.EDU, Thobe@EE.UCLA.EDU,
+ X854%ddagsi3.bitnet@WISCVM.WISC.EDU, Zeffi%finabo.bitnet@WISCVM.WISC.EDU
+cc: beebe@UTAH-SCIENCE.ARPA
+X-US-Mail: "Center for Scientific Computation, South Physics, University of Utah, Salt Lake City, UT 84112"
+X-Telephone: (801) 581-5254
+Message-ID: <12283822029.27.BEEBE@UTAH-SCIENCE.ARPA>
+
+A couple of years ago, I spent some time debugging the
+DVIxxx drivers under Eunice (Wollongong's 4.1 BSD Unix
+underneath VAX VMS), trying to determine why they core
+dumped after completing successfully. The problem was
+reported again from a 4.2 Eunice site, and last week from a
+4.2 BSD Unix VAX site. It does not occur in 4.3BSD, or in
+HPUX, or any other non-Unix system in which the family has
+been implemented. Stepping with the debugger, I found that
+the program would run successfully right up to the call to
+exit() in abortrun.h, then die after it entered exit(). I
+hit the problem again today on a 4.2 BSD Unix system on an
+Integrated Solutions machine, and can now report a solution.
+The report last week from Los Angeles pointed the finger at
+fclose(), and indeed, if each call to fclose() makes sure
+not to make the call if the file pointer is null, the core
+dumps no longer happen. Two modules, abortrun.h and
+dviterm.h are affected, and a VAX VMS DIFF listing is
+appended to this note. This is definitely a bug in 4.1 and
+4.2 Unix, not the DVI drivers, but a workaround is
+necessary. The man page (man 3s fclose) states
+
+ These routines return EOF if stream is not
+ associated with an output file, or if buffered data
+ cannot be transferred to that file.
+
+There is no mention of a subsequent core dump!
+
+I hit a second problem on the Integrated Solutions system:
+the global variable errno is not defined in the file
+errno.h; it is under VAX VMS and TOPS-20. dvihead.h
+therefore needs a change too for these systems. It must be
+inside a conditional, because in the coming ANSI C standard,
+errno will be defined as a macro in stddef.h, which will not
+necessarily expand to an extern int. Why it is not defined
+in errno.h is a mystery, since errno is unlikely to be used
+without errno.h to get definitions of error symbols.
+
+diff abortrun.h
+************
+File SYS$LIBROOT:[PLOT79.TEX.DVI]ABORTRUN.H;5
+ 21 if (font_files[k].font_id != (FILE*)NULL)
+ 22 (void)fclose(font_files[k].font_id);
+ 23
+ 24 if (dvifp != (FILE*)NULL)
+ 25 (void)fclose(dvifp);
+ 26 if (plotfp != (FILE*)NULL)
+ 27 (void)fclose(plotfp);
+ 28 if (g_dolog && (g_logfp != (FILE *)NULL))
+******
+File SYS$LIBROOT:[PLOT79.TEX.DVI]ABORTRUN.H;4
+ 21 (void)fclose(font_files[k].font_id);
+ 22
+ 23 (void)fclose(dvifp);
+ 24 (void)fclose(plotfp);
+ 25 if (g_dolog && (g_logfp != (FILE *)NULL))
+************
+
+Number of difference sections found: 1
+Number of difference records found: 7
+
+DIFFERENCES /IGNORE=()/MERGED=1-
+ SYS$LIBROOT:[PLOT79.TEX.DVI]ABORTRUN.H;5-
+ SYS$LIBROOT:[PLOT79.TEX.DVI]ABORTRUN.H;4
+diff dvihead.h
+************
+File SYS$LIBROOT:[PLOT79.TEX.DVI]DVIHEAD.H;8
+ 338 #if (BSD41 | BSD42)
+ 339 extern int errno; /* not in all errno.h files, sigh... */
+ 340 #endif
+ 341
+******
+File SYS$LIBROOT:[PLOT79.TEX.DVI]DVIHEAD.H;7
+ 338
+************
+
+Number of difference sections found: 1
+Number of difference records found: 3
+
+DIFFERENCES /IGNORE=()/MERGED=1-
+ SYS$LIBROOT:[PLOT79.TEX.DVI]DVIHEAD.H;8-
+ SYS$LIBROOT:[PLOT79.TEX.DVI]DVIHEAD.H;7
+diff dviterm.h
+************
+File SYS$LIBROOT:[PLOT79.TEX.DVI]DVITERM.H;10
+ 30 if (dvifp != (FILE*)NULL)
+ 31 (void)fclose(dvifp);
+ 32 if (plotfp != (FILE*)NULL)
+ 33 (void)fclose(plotfp);
+ 34
+******
+File SYS$LIBROOT:[PLOT79.TEX.DVI]DVITERM.H;9
+ 30 (void)fclose(dvifp);
+ 31 (void)fclose(plotfp);
+ 32
+************
+
+Number of difference sections found: 1
+Number of difference records found: 4
+
+DIFFERENCES /IGNORE=()/MERGED=1-
+ SYS$LIBROOT:[PLOT79.TEX.DVI]DVITERM.H;10-
+ SYS$LIBROOT:[PLOT79.TEX.DVI]DVITERM.H;9
+-------
diff --git a/dviware/beebe/updates/00mail.7 b/dviware/beebe/updates/00mail.7
new file mode 100644
index 0000000000..0c48285a7c
--- /dev/null
+++ b/dviware/beebe/updates/00mail.7
@@ -0,0 +1,73 @@
+20-Apr-87 18:08:57-MST,3550;000000000000
+Mail-From: BEEBE created at 20-Apr-87 18:08:49
+Date: Mon 20 Apr 87 18:08:48-MST
+From: "Nelson H.F. Beebe" <Beebe@SCIENCE.UTAH.EDU>
+Subject: DVI family update #7 -- Version 2.07 announcement
+To: beebe@SCIENCE.UTAH.EDU
+cc: texhax@SCORE.STANFORD.EDU, $90%dhdurz1.bitnet@WISCVM.WISC.EDU,
+ Anderson%URegina2.bitnet@WISCVM.WISC.EDU, AustinS%ucbcmsa.edu@CS.UTAH.EDU,
+ Berg-lists%gsb-why@SCORE.STANFORD.EDU,
+ Carvalho%ernie.Berkeley.EDU@CS.UTAH.EDU, CEL@CITHEX.CALTECH.EDU,
+ Celoni@SCORE.STANFORD.EDU,
+ Cmi011%uk.ac.soton.ibm%ukacrl.bitnet@WISCVM.WISC.EDU,
+ Crawford-J%ohio-state.arpa@CS.UTAH.EDU,
+ CRM8701%tamvenus.bitnet@WISCVM.WISC.EDU,
+ Dan%buchmd.bu-cs.arpa@CS.UTAH.EDU, David%ci-dandelion.uucp@EDDIE.MIT.EDU,
+ Gaspard%hroeur5.bitnet@WISCVM.WISC.EDU,
+ Goodall%admin.okanagan.bcc.cdn@RELAY.CS.NET, Grandi@NOAO.ARPA,
+ James%vaxe.coe.northeastern.edu@CS.UTAH.EDU, JRP%nplpsg.uucp@CS.UTAH.EDU,
+ Karney%ppc.mfenet@NMFECC.ARPA, Lamy%ai.toronto.edu@RELAY.CS.NET,
+ Math300%unlcdc3.bitnet@WISCVM.WISC.EDU,
+ MPC91B%dgogwd01.bitnet@WISCVM.WISC.EDU,
+ RJones%uwovax.bitnet@WISCVM.WISC.EDU, RS%gnome.cs.cmu.edu@CS.UTAH.EDU,
+ Simon%m_scrvx2%slb-test.csnet@csnet-relay,
+ SPQR%uk.ac.soton.cm@CS.UCL.AC.UK, Stone%ruthep.rutgers.edu@RUTGERS.EDU,
+ System%uvphys.bitnet@WISCVM.WISC.EDU,
+ Syvaxtgs%hheouh51.bitnet@WISCVM.WISC.EDU, Thobe@EE.UCLA.EDU,
+ Wendy%crnlgsm.bitnet@WISCVM.WISC.EDU, X854%ddagsi3.bitnet@WISCVM.WISC.EDU,
+ Zeffi%finabo.bitnet@WISCVM.WISC.EDU,
+ "*APS:<BEEBE.TEX.DVI>MAIL.TXT.1"@SCIENCE.UTAH.EDU
+X-US-Mail: "Center for Scientific Computation, South Physics, University of Utah, Salt Lake City, UT 84112"
+X-Telephone: (801) 581-5254
+Message-ID: <12296138989.18.BEEBE@SCIENCE.UTAH.EDU>
+
+I have completed today Version 2.07 of my DVI driver family,
+and updated all the source directories on SCIENCE.UTAH.EDU.
+Although this version supports one new device, and enhances
+the support for another, it does not provide any substantial
+change for users, so sites which have already received
+Version 2.06 should not feel compelled to do an immediate
+upgrade.
+
+The major changes are as follows:
+ * support for the KCC-20 compiler on TOPS-20;
+ * addition of a driver, DVIL75, for the DEC LA75
+ printer (thanks to John Sauter for this);
+ * substantially enhanced BBN BitGraph driver:
+ ** instant keyboard response during screen
+ update to support rapid screen
+ repositioning and document skimming
+ ** large characters now sent as downloaded fonts
+ instead of being sent as raster bitmaps
+ ** zoom up and down in magnification
+ ** coarse and fine control of screen positioning
+ ** now works with both white and black backgrounds
+ ** character overwrite at right margin no
+ longer happens (appears to be a BitGraph
+ internal bug)
+ * addition of a public-domain version of the Unix
+ Version 7 MAKE utility which supports six (yes, 6)
+ different operating systems (sources on
+ APS:<TEX.PUB.MAKE>), and Makefile's now used for
+ building the driver family on all supported machines;
+ * updated, extended, and INDEXED installer's manual
+ (dvidriver.*) (95 pages)
+ * dvijep (HP LaserJet Plus) now handles characters
+ too large to be sent as downloaded fonts
+ * BSD 4.1 core-dump-at-exit bug fixed (the bug was
+ in BSD, NOT the drivers)
+
+If you wish to retrieve these via Internet ANONYMOUS FTP,
+get the file 00README.TXT first; it tells where to find
+everything else.
+-------
diff --git a/dviware/beebe/updates/00mail.8 b/dviware/beebe/updates/00mail.8
new file mode 100644
index 0000000000..05215def84
--- /dev/null
+++ b/dviware/beebe/updates/00mail.8
@@ -0,0 +1,189 @@
+29-Apr-87 18:45:30-MDT,9269;000000000001
+Date: Wed 29 Apr 87 18:45:29-MDT
+From: "Nelson H.F. Beebe" <Beebe@SCIENCE.UTAH.EDU>
+Subject: DVI driver update #8
+To: beebe@SCIENCE.UTAH.EDU, $90%dhdurz1.bitnet@WISCVM.WISC.EDU, AbbottP%uk.ac.aston.mail%uk.ac.rl.gb@CS.UCL.AC.UK,
+ Anderson%URegina2.bitnet@WISCVM.WISC.EDU, AustinS%ucbcmsa.edu@CS.UTAH.EDU,
+ Berg-lists%gsb-why@SCORE.STANFORD.EDU, Brent%CSUFresno.edu@RELAY.CS.NET,
+ Carvalho%ernie.Berkeley.EDU@CS.UTAH.EDU, CEL@CITHEX.CALTECH.EDU,
+ Celoni@SCORE.STANFORD.EDU, Cmi011%uk.ac.soton.ibm%ukacrl.bitnet@WISCVM.WISC.EDU,
+ Crawford-J%ohio-state.arpa@CS.UTAH.EDU, CRM8701%tamvenus.bitnet@WISCVM.WISC.EDU,
+ Dan%buchmd.bu-cs.arpa@CS.UTAH.EDU, David%ci-dandelion.uucp@EDDIE.MIT.EDU,
+ French%TI-EG@RELAY.CS.NET, Friesland%rz.informatik.uni-hamburg.dbp.de%germany.csnet@RELAY.CS.NET,
+ Gaspard%hroeur5.bitnet@WISCVM.WISC.EDU, Goodall%admin.okanagan.bcc.cdn@RELAY.CS.NET,
+ Grandi@NOAO.ARPA, Harringt%irlearn.bitnet@WISCVM.WISC.EDU, James%vaxe.coe.northeastern.edu@CS.UTAH.EDU,
+ JRP%nplpsg.uucp@CS.UTAH.EDU, Karney%ppc.mfenet@NMFECC.ARPA, Kuo%sask.bitnet@WISCVM.WISC.EDU,
+ Lamy%ai.toronto.edu@RELAY.CS.NET, Math300%unlcdc3.bitnet@WISCVM.WISC.EDU,
+ Mcvax!ukc!sjl@SEISMO.CSS.GOV, MPC91B%dgogwd01.bitnet@WISCVM.WISC.EDU,
+ Radford%frgag51.bitnet@WISCVM.WISC.EDU, RJones%uwovax.bitnet@WISCVM.WISC.EDU,
+ Rohlicek%v1.bbn.com@CS.UTAH.EDU, RS%gnome.cs.cmu.edu@CS.UTAH.EDU,
+ Simon%m_scrvx2%slb-test.csnet@csnet-relay.CSNet, SPQR%uk.ac.soton.cm@CS.UCL.AC.UK,
+ Stone%ruthep.rutgers.edu@RUTGERS.EDU, System%uvphys.bitnet@WISCVM.WISC.EDU,
+ Syvaxtgs%hheouh51.bitnet@WISCVM.WISC.EDU, Thobe@EE.UCLA.EDU, Wendy%crnlgsm.bitnet@WISCVM.WISC.EDU,
+ U04z%cbebda3t.bitnet@WISCVM.WISC.EDU, X854%ddagsi3.bitnet@WISCVM.WISC.EDU,
+ Zeffi%finabo.bitnet@WISCVM.WISC.EDU, "*APS:<BEEBE.TEX.DVI>MAIL.TXT.1"@SCIENCE.UTAH.EDU
+X-US-Mail: "Center for Scientific Computation, South Physics, University of Utah, Salt Lake City, UT 84112"
+X-Telephone: (801) 581-5254
+Message-ID: <12298494041.11.BEEBE@SCIENCE.UTAH.EDU>
+
+Two bug fixes are reported in this note. The family has now
+been distributed to over 100 sites, and my secretary has
+been busy for several days getting packages mailed, with
+still a dozen or so to go out.
+
+I have received several reports of promising work in
+progress which is summarized in the following paragraphs.
+
+At least one site (Doug Henderson at Berkeley) is adapting
+dvialw to support the Mergenthaler Linotronic
+PostScript-based phototypesetter, and I hope to visit there
+next week.
+
+A couple of sites report work (or good intentions) on
+enhancing the dvialw special command support. Brendan McKay
+at The Australian National University in Canberra has done
+some very nice work adding PostScript support as TeX macros
+which result in \special{} commands, and has a port to the
+Amiga well on the way. He has also implemented the virtual
+font mechanism for VAX VMS. I hope he'll consider writing
+up the PostScript work for TUGBoat!
+
+Dean Guenther at Washington State University is implementing
+the family on IBM VM/CMS using the Waterloo C compiler.
+
+I also have first reports of use of dvialw with the TI
+OmniLaser, which sports version 45.0 of the PostScript
+interpreter (Apple's 2 LaserWriter models are versions 23.0
+and 38.0 respectively); the use of the "NOTE" paper type in
+the dvialw.ps /BOJ macro needs to be changed to LETTER,
+since the TI printer doesn't recognize that paper type.
+This can be handled portably by some inserting some
+PostScript code to check for the existence of that paper
+type, but I want to wait and see what changes are needed for
+the Mergenthaler before a new version of dvialw.ps is
+introduced.
+
+The HPLJ+ driver, dvijep, is known to work on the Personal
+Computer Products LaserImage 2000 (Ricoh engine), as well as
+on a MIL-STD clone, the Mitek 110T. Isaac Salzman at RDL is
+fighting the DataProducts LZR-1230, which is supposed to
+emulate the HPLJ+, but apparently has some problems.
+
+For the VAX VMS implementation, the suggestion was raised by
+Ned Freed at Harvey Mudd College of using a third parameter,
+"ctx=stm", to fopen(), which apparently gets around the need
+for special versions of fseek() and ftell() in vaxvms.c. I
+haven't done this for two reasons. First, the option is not
+documented; it was found in microfiche listings of the C
+runtime library, and could disappear, or be changed, in
+future versions of VMS C. Second, and most importantly, not
+all existing software on VMS knows how to handle stream mode
+files, which are new with VMS Version 4. In particular, the
+Kellerman and Smith TeX implementation and Imagen DVI driver
+and spooler program on which we rely heavily on our VMS
+systems do not, and require fixed blocked 512-byte binary
+records for DVI and font files. Changing to stream mode
+would be very awkward for us. The latest version of the K&S
+software with Metafont and enhanced support for our Imagen
+3320 printer is on order, and if it includes stream file
+support, I may change my position. I cannot think of
+anything good to say about record-structured file systems
+like VMS and IBM MVS; the MS-DOS, TOPS-20 and Unix view of
+files as simple byte streams makes life MUCH easier.
+
+John Pavel at NPL reported some typos in the latest edition
+of the DVI driver documentation in dvidriver.ltx and
+dviman.texinfo. I have fixed both of these, so some of you
+receiving later copies of Version 2.07 will have them
+incorporated. I regrettably forgot to rerun GNU EMACS
+texinfo-format-buffer on dviman.texinfo after I updated it,
+and consequently 3 errors slipped by. Here is VAX VMS style
+difference listing:
+
+************
+File SYS$LIBROOT:[PLOT79.TEX.DVI.DOC]DVIMAN.TEXINFO;5
+ 624 @item @b{@@}
+ 625 Redisplay current page with @i{startup} page positioning.
+******
+File SYS$LIBROOT:[PLOT79.TEX.DVI.DOC]DVIMAN.TEXINFO;3
+ 624 @item @b{@}
+ 625 Redisplay current page with @i{startup} page positioning.
+************
+************
+File SYS$LIBROOT:[PLOT79.TEX.DVI.DOC]DVIMAN.TEXINFO;5
+ 634 2, @dots{}. The @TeX{} page numbers are displayed in the
+ 635 status window. This is a recursive display; if you respond
+******
+File SYS$LIBROOT:[PLOT79.TEX.DVI.DOC]DVIMAN.TEXINFO;3
+ 634 2, @dots. The @TeX{} page numbers are displayed in the
+ 635 status window. This is a recursive display; if you respond
+************
+************
+File SYS$LIBROOT:[PLOT79.TEX.DVI.DOC]DVIMAN.TEXINFO;5
+ 917 EMAIL: Beebe@@Science.Utah.Edu (Internet)
+ 918 @end display
+******
+File SYS$LIBROOT:[PLOT79.TEX.DVI.DOC]DVIMAN.TEXINFO;3
+ 917 EMAIL: Beebe@Science.Utah.Edu (Internet)
+ 918 @end display
+************
+
+Number of difference sections found: 3
+Number of difference records found: 3
+
+DIFFERENCES /IGNORE=()/MERGED=1/OUTPUT=SYS$LIBROOT:[PLOT79.TEX.DVI.DOC]DVIMAN.DIF;1-
+ SYS$LIBROOT:[PLOT79.TEX.DVI.DOC]DVIMAN.TEXINFO;5-
+ SYS$LIBROOT:[PLOT79.TEX.DVI.DOC]DVIMAN.TEXINFO;3
+
+In dvidriver.sty for Version 2.07, you need to insert a
+missing macro which is used in the index file:
+
+ \newcommand{\FNNX}[1]{{\tt #1}}
+
+Finally, here are two bug fixes, both VMS-specific, and only
+one affects the driver family as currently distributed.
+
+[29-Apr-87] from Brendan Mackay (munnari!anucsd.oz!bdm@seismo.CSS.GOV)
+ In machdefs.h, change
+ #define REWIND(fp) fseek(fp,0L,0)
+ to
+ #define REWIND(fp) FSEEK(fp,0L,0)
+ This is not necessary for the family as distributed, but
+ Brendan has implemented the virtual font changes
+ necessary for VAX VMS; they should be incorporated in a
+ future release.
+
+[29-Apr-87] from Brendan Mackay (munnari!anucsd.oz!bdm@seismo.CSS.GOV)
+ The code for vms_read() [in vaxvms.c] has problems. One
+ is that you don't test for end of file. The other is
+ that there is a bug in the C library which prevents you
+ asking for more than 65535 bytes at a time. It is
+ documented that no more than 65535 bytes will be
+ returned, but not that you can't ask for more. If you
+ do, it reduces your request mod 65536! Here's a
+ replacement:
+
+/**********************************************************************/
+/*-->READ*/
+int
+READ(file_desc,buffer,nbytes)
+register int file_desc;
+register char *buffer;
+register int nbytes;
+{
+ register int ngot;
+ register int left;
+
+ for (left = nbytes; left > 0; /* NOOP */)
+ {
+ ngot = read(file_desc,buffer,(left > 65024 ? 65024 : left));
+ if (ngot < 0)
+ return (-1); /* error occurred */
+ if (ngot == 0) /* eof occurred */
+ return(nbytes-left);
+ buffer += ngot;
+ left -= ngot;
+ }
+ return(nbytes-left);
+}
+-------
diff --git a/dviware/beebe/updates/00mail.9 b/dviware/beebe/updates/00mail.9
new file mode 100644
index 0000000000..de81430507
--- /dev/null
+++ b/dviware/beebe/updates/00mail.9
@@ -0,0 +1,292 @@
+22-Jul-87 13:09:29-MDT,9242;000000000001
+Date: Wed 22 Jul 87 13:09:29-MDT
+From: "Nelson H.F. Beebe" <Beebe@SCIENCE.UTAH.EDU>
+Subject: DVI driver family update #9
+To: "DVI mailing list": ;
+cc: BEEBE@SCIENCE.UTAH.EDU
+X-US-Mail: "Center for Scientific Computation, South Physics, University of Utah, Salt Lake City, UT 84112"
+X-Telephone: (801) 581-5254
+Message-ID: <12320452968.12.BEEBE@SCIENCE.UTAH.EDU>
+
+ DVI Driver Family Update #9
+ [22-Jun-87]
+
+The University of Utah Mathematics Department purchased 12 Sun
+3/50's, a 3/110 color system (for me), and a 3/260 file server
+with 575Mb disk; 4 of these have been running now for 2 weeks,
+during which time I have been busy learning about them, and
+installing software on them.
+
+During the first week, I got jove and gnu emacs running, and as
+of 19-Jun-87 (Friday morning), TeX 2.2, plus AMSTeX, LaTeX,
+SLITeX, BibTeX, and all the DVI drivers are now operational. TeX
+2.2 was released 10-Jun-87 at Stanford, and most LaTeX .sty and
+.doc files were updated about the same time. I have updated our
+TOPS-20 system (SCIENCE.UTAH.EDU), plus 2 VAX VMS systems, plus
+the Sun's to this level.
+
+Metafont on the Sun's core dumps immediately; we are at Sun
+OS 3.2, and the TeX distribution tree I tar'ed over from
+CS.UTAH.EDU has only change files for Sun OS version 2, so I
+expect there is some incompatibility there, although nothing
+obvious showed up in the build process, which I repeated
+twice for checking purposes.
+
+What all of this means is that we now have our own local
+Unix systems besides TOPS-20, VMS, and MS-DOS available for
+development. Until last October, I had Eunice (4.1BSD under
+VAX VMS), but we upgraded the VAX 750 to an 8600, and the
+Eunice licensing for the 8600 is still under negotiation, so
+I have been without substantial Unix access for the last 8
+months. I do have guest accounts on several campus Unix
+machines, but cannot reasonably do any sofware development
+on them.
+
+The Sun installation necessitated a few changes, which are
+given by Unix diff listings below. For those unfamiliar
+with diff, a command
+
+diff oldfile newfile
+
+produces lines beginning "<" from the old file, and those
+following which begin with ">" are the replacement lines
+from the new file, so the listings have the same order as a
+Web
+
+@x
+old
+@y
+new
+@z
+
+change file sequence. Lines preceded by #1,a#2,#3 are to be
+added at line number #1. Similarly, #1,#2c#3,#4 represents
+a change of lines #1 through #2.
+
+========================================================================
+CLRBMAP.H: -- missing two typecasts
+
+17c17
+< p = BITMAP(y,0);
+---
+> p = (UNSIGN32*)BITMAP(y,0);
+44,45c44,45
+<
+< p = BITMAP(YBIT-1,XBIT-1); /* the last element */
+---
+> p = (UNSIGN32*)BITMAP(YBIT-1,XBIT-1); /* the last element */
+>
+
+========================================================================
+DVIALW.PS: -- fix error in /LEGAL macro; thanks to Ken Yap
+ (ken@cs.rochester.edu) for finding this one
+
+0a1,2
+> % <BEEBE.TEX.DVI>DVIALW.PS.14, 22-Jun-87 09:55:05, Edit by BEEBE
+> % Add missing "0 900 translate Mtrx currentmatrix pop" to /LEGAL
+194a197,198
+> 0 900 translate
+> Mtrx currentmatrix pop
+
+That is, it should read
+/LEGAL
+{
+ legal initmatrix
+ 72 Resolution div dup scale
+ 0 900 translate
+ Mtrx currentmatrix pop
+} bdf
+
+========================================================================
+DVIJEP.C: -- several expressions too complex for Sun cc compiler;
+ it is amazing that it could not even compile the
+ simple product 4.0*(tcharptr->tfmw)*conv!
+
+351a352,353
+> float temp;
+> INT16 ntemp;
+389,394c391,406
+< OUT16(MAX(-128,MIN(-(tcharptr->xoffp),127)));
+< OUT16(MAX(-128,MIN(tcharptr->yoffp,127)));
+< OUT16(MIN(128,tcharptr->wp));
+< OUT16(MIN(255,tcharptr->hp));
+< OUT16(ROUND(4.0*(tcharptr->tfmw)*conv)); /* delta x to nearest */
+< /* 1/4 dot */
+---
+> /* Apologies for the temporary variables; the Sun OS 3.2 cc could
+> not compile the original expressions. */
+> ntemp = MIN(-(tcharptr->xoffp),127);
+> ntemp = MAX(-128,ntemp);
+> OUT16(ntemp);
+> ntemp = MIN(tcharptr->yoffp,127);
+> ntemp = MAX(-128,ntemp);
+> OUT16(ntemp);
+> ntemp = MIN(128,tcharptr->wp);
+> OUT16(ntemp);
+> ntemp = MIN(255,tcharptr->hp);
+> OUT16(ntemp);
+> temp = tcharptr->tfmw;
+> temp = 4.0*temp*conv;
+> ntemp = ROUND(temp);
+> OUT16(ntemp); /* delta x to nearest 1/4 dot */
+
+
+========================================================================
+GETBMAP.H: -- optional; Sun cc will not accept the backslash line
+ continuation, most other compilers require it. A single long
+ line instead would solve the problem, but requires a line
+ which exceeds 80 characters, which is a portability no-no.
+
+27,28c27,28
+< bitmap = (UNSIGN32*)MALLOC( ((UNSIGN32)(XBIT)) * ((UNSIGN32)(YBIT)) * \
+< sizeof(UNSIGN32) );
+---
+> bitmap = (UNSIGN32*)MALLOC( ((UNSIGN32)(XBIT)) * ((UNSIGN32)(YBIT)) *
+> sizeof(UNSIGN32) );
+
+========================================================================
+MACHDEFS.H: -- Unix TeX from U of Washington does not follow the
+ Stanford directory naming conventions, sigh..., so we
+ change the SUBPATH default directory name. Also, the
+ tests for compile-time definition of FONTLIST, FONTPATH and
+ SUBPATH need #ifdef instead of #if.
+
+95d94
+< DECLN03PLUS -- DEC LN03-PLUS laser printer
+165c164
+< #define REWIND(fp) FSEEK(fp,0L,0)
+---
+> #define REWIND(fp) fseek(fp,0L,0)
+206d204
+< #define DECLN03PLUS 0
+225d222
+<
+285c282
+< #ifdef FONTLIST /* can be set at compile-time */
+---
+> #if FONTLIST /* can be set at compile-time */
+290c287
+< #ifdef FONTPATH /* can be set at compile-time */
+---
+> #if FONTPATH /* can be set at compile-time */
+303c300
+< #ifdef SUBPATH /* can be set at compile-time */
+---
+> #if SUBPATH /* can be set at compile-time */
+550c547
+< #ifdef FONTLIST /* can be set at compile-time */
+---
+> #if FONTLIST /* can be set at compile-time */
+555c552
+< #ifdef FONTPATH /* can be set at compile-time */
+---
+> #if FONTPATH /* can be set at compile-time */
+568,570c565,567
+< #ifdef SUBPATH /* can be set at compile-time */
+< #else
+< #define SUBPATH "/usr/lib/tex/macros/"
+---
+> #if SUBPATH /* can be set at compile-time */
+> #else
+> #define SUBPATH "/usr/lib/tex/inputs/"
+613a611,631
+> /* Avoid stupid undefined macro name warnings */
+> #ifndef FONTLIST
+> #define FONTLIST 0
+> #endif
+>
+> #ifndef FONTPATH
+> #define FONTPATH 0
+> #endif
+>
+> #ifndef SUBPATH
+> #define SUBPATH 0
+> #endif
+>
+> #ifndef TEXINPUTS
+> #define TEXINPUTS 0
+> #endif
+>
+> #ifndef TEXFONTS
+> #define TEXFONTS 0
+> #endif
+>
+621c639,640
+< #ifndef FONTLIST /* can be set at compile-time */
+---
+> #if FONTLIST /* can be set at compile-time */
+> #else
+625c644,645
+< #ifndef FONTPATH /* can be set at compile-time */
+---
+> #if FONTPATH /* can be set at compile-time */
+> #else
+644c664,665
+< #ifndef SUBPATH /* can be set at compile-time */
+---
+> #if SUBPATH /* can be set at compile-time */
+> #else
+648c669,670
+< #ifndef TEXINPUTS /* can be set at compile-time */
+---
+> #if TEXINPUTS /* can be set at compile-time */
+> #else
+652c674,675
+< #ifndef TEXFONTS /* can be set at compile-time */
+---
+> #if TEXFONTS /* can be set at compile-time */
+> #else
+
+========================================================================
+MAKEFILE.UNX: --optional; we insist that all local additions to our Unix
+ systems be placed ONLY under the tree /usr/local. The
+ Washington TeX distribution assumes fonts and input
+ files are under /usr/lib; the changes to CFLAGS provide
+ for this:
+
+12c12,14
+< CFLAGS = -DANSI=0 -DUNIX
+---
+> CFLAGS = -DANSI=0 -DUNIX \
+> -DFONTPATH="\"/usr/local/lib/tex/fonts/\"" \
+> -DSUBPATH="\"/usr/local/lib/tex/macros/\""
+18c20,22
+< RM = rm
+---
+> RM = /bin/rm
+>
+> C = .c
+30c34,35
+< # Targets
+---
+> # Targets (lw78 is excluded--most Unix sites have Transcript or devps
+> # which offer similar features)
+34,35c39,48
+< keytst lptops lw78 texidx tosprx
+<
+---
+> keytst lptops texidx tosprx
+>
+>
+> CLEAN:
+> $(RM) *.o
+> $(RM) -f 00arit \
+> dvialw dvibit dvican dvigd dviimp dvijep dvijet dvil75 \
+> dvim72 dvimac dvimpi dvio72 dvioki dviprx dvitos \
+> keytst lptops texidx tosprx
+>
+
+========================================================================
+TOSPRX.C: -- removed unused arguments
+
+58,60c58
+< main(argc,argv)
+< int argc;
+< char *argv[];
+---
+> main()
+
+========================================================================
+ [The End]
+
+-------