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.16 |
Initial commit
Diffstat (limited to 'dviware/beebe/updates/00mail.16')
-rw-r--r-- | dviware/beebe/updates/00mail.16 | 654 |
1 files changed, 654 insertions, 0 deletions
diff --git a/dviware/beebe/updates/00mail.16 b/dviware/beebe/updates/00mail.16 new file mode 100644 index 0000000000..746e9f8d84 --- /dev/null +++ b/dviware/beebe/updates/00mail.16 @@ -0,0 +1,654 @@ +26-May-88 18:15:50-MDT,26245;000000000001 +Date: Thu 26 May 88 18:15:48-MDT +From: "Nelson H.F. Beebe" <Beebe@SCIENCE.UTAH.EDU> +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 <sys/xxx.h> files, <signal.h> 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:<TEX.PUB.LOCAL-GUIDE>. 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 <stdio.h> + #include <ctype.h> + ++ #define READ read ++ #define EXIT exit ++ + #ifdef KCC_20 + #include <file.h> + #define tops20 +*************** +*** 57,62 **** +--- 60,69 ---- + #else + #ifdef OS_VAXVMS + #include <file.h> ++ #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. */ +------- |