diff options
author | Norbert Preining <norbert@preining.info> | 2019-09-02 13:46:59 +0900 |
---|---|---|
committer | Norbert Preining <norbert@preining.info> | 2019-09-02 13:46:59 +0900 |
commit | e0c6872cf40896c7be36b11dcc744620f10adf1d (patch) | |
tree | 60335e10d2f4354b0674ec22d7b53f0f8abee672 /dviware/beebe/updates |
Initial commit
Diffstat (limited to 'dviware/beebe/updates')
-rw-r--r-- | dviware/beebe/updates/00mail.1 | 117 | ||||
-rw-r--r-- | dviware/beebe/updates/00mail.10 | 387 | ||||
-rw-r--r-- | dviware/beebe/updates/00mail.11 | 119 | ||||
-rw-r--r-- | dviware/beebe/updates/00mail.12 | 725 | ||||
-rw-r--r-- | dviware/beebe/updates/00mail.13 | 670 | ||||
-rw-r--r-- | dviware/beebe/updates/00mail.14 | 621 | ||||
-rw-r--r-- | dviware/beebe/updates/00mail.15 | 178 | ||||
-rw-r--r-- | dviware/beebe/updates/00mail.16 | 654 | ||||
-rw-r--r-- | dviware/beebe/updates/00mail.17 | 146 | ||||
-rw-r--r-- | dviware/beebe/updates/00mail.2 | 140 | ||||
-rw-r--r-- | dviware/beebe/updates/00mail.3 | 252 | ||||
-rw-r--r-- | dviware/beebe/updates/00mail.4 | 65 | ||||
-rw-r--r-- | dviware/beebe/updates/00mail.5 | 35 | ||||
-rw-r--r-- | dviware/beebe/updates/00mail.6 | 128 | ||||
-rw-r--r-- | dviware/beebe/updates/00mail.7 | 73 | ||||
-rw-r--r-- | dviware/beebe/updates/00mail.8 | 189 | ||||
-rw-r--r-- | dviware/beebe/updates/00mail.9 | 292 |
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 +¶m[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 = ¶m[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] + +------- |