26-May-88 18:15:50-MDT,26245;000000000001 Date: Thu 26 May 88 18:15:48-MDT From: "Nelson H.F. Beebe" 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 files, 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:. 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 #include + #define READ read + #define EXIT exit + #ifdef KCC_20 #include #define tops20 *************** *** 57,62 **** --- 60,69 ---- #else #ifdef OS_VAXVMS #include + #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. */ -------