summaryrefslogtreecommitdiff
path: root/dviware/beebe/updates/00mail.16
diff options
context:
space:
mode:
authorNorbert Preining <norbert@preining.info>2019-09-02 13:46:59 +0900
committerNorbert Preining <norbert@preining.info>2019-09-02 13:46:59 +0900
commite0c6872cf40896c7be36b11dcc744620f10adf1d (patch)
tree60335e10d2f4354b0674ec22d7b53f0f8abee672 /dviware/beebe/updates/00mail.16
Initial commit
Diffstat (limited to 'dviware/beebe/updates/00mail.16')
-rw-r--r--dviware/beebe/updates/00mail.16654
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. */
+-------