summaryrefslogtreecommitdiff
path: root/dviware/beebe/updates/00mail.12
diff options
context:
space:
mode:
Diffstat (limited to 'dviware/beebe/updates/00mail.12')
-rw-r--r--dviware/beebe/updates/00mail.12725
1 files changed, 725 insertions, 0 deletions
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.
+-------