diff options
Diffstat (limited to 'dviware/beebe/updates/00mail.12')
-rw-r--r-- | dviware/beebe/updates/00mail.12 | 725 |
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. +------- |