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" 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"); -------