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/00mail.14 |
Initial commit
Diffstat (limited to 'dviware/beebe/updates/00mail.14')
-rw-r--r-- | dviware/beebe/updates/00mail.14 | 621 |
1 files changed, 621 insertions, 0 deletions
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 + +------- |