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.8 |
Initial commit
Diffstat (limited to 'dviware/beebe/updates/00mail.8')
-rw-r--r-- | dviware/beebe/updates/00mail.8 | 189 |
1 files changed, 189 insertions, 0 deletions
diff --git a/dviware/beebe/updates/00mail.8 b/dviware/beebe/updates/00mail.8 new file mode 100644 index 0000000000..05215def84 --- /dev/null +++ b/dviware/beebe/updates/00mail.8 @@ -0,0 +1,189 @@ +29-Apr-87 18:45:30-MDT,9269;000000000001 +Date: Wed 29 Apr 87 18:45:29-MDT +From: "Nelson H.F. Beebe" <Beebe@SCIENCE.UTAH.EDU> +Subject: DVI driver update #8 +To: beebe@SCIENCE.UTAH.EDU, $90%dhdurz1.bitnet@WISCVM.WISC.EDU, AbbottP%uk.ac.aston.mail%uk.ac.rl.gb@CS.UCL.AC.UK, + Anderson%URegina2.bitnet@WISCVM.WISC.EDU, AustinS%ucbcmsa.edu@CS.UTAH.EDU, + Berg-lists%gsb-why@SCORE.STANFORD.EDU, Brent%CSUFresno.edu@RELAY.CS.NET, + Carvalho%ernie.Berkeley.EDU@CS.UTAH.EDU, CEL@CITHEX.CALTECH.EDU, + Celoni@SCORE.STANFORD.EDU, Cmi011%uk.ac.soton.ibm%ukacrl.bitnet@WISCVM.WISC.EDU, + Crawford-J%ohio-state.arpa@CS.UTAH.EDU, CRM8701%tamvenus.bitnet@WISCVM.WISC.EDU, + Dan%buchmd.bu-cs.arpa@CS.UTAH.EDU, David%ci-dandelion.uucp@EDDIE.MIT.EDU, + French%TI-EG@RELAY.CS.NET, Friesland%rz.informatik.uni-hamburg.dbp.de%germany.csnet@RELAY.CS.NET, + Gaspard%hroeur5.bitnet@WISCVM.WISC.EDU, Goodall%admin.okanagan.bcc.cdn@RELAY.CS.NET, + Grandi@NOAO.ARPA, Harringt%irlearn.bitnet@WISCVM.WISC.EDU, James%vaxe.coe.northeastern.edu@CS.UTAH.EDU, + JRP%nplpsg.uucp@CS.UTAH.EDU, Karney%ppc.mfenet@NMFECC.ARPA, Kuo%sask.bitnet@WISCVM.WISC.EDU, + Lamy%ai.toronto.edu@RELAY.CS.NET, Math300%unlcdc3.bitnet@WISCVM.WISC.EDU, + Mcvax!ukc!sjl@SEISMO.CSS.GOV, MPC91B%dgogwd01.bitnet@WISCVM.WISC.EDU, + Radford%frgag51.bitnet@WISCVM.WISC.EDU, RJones%uwovax.bitnet@WISCVM.WISC.EDU, + Rohlicek%v1.bbn.com@CS.UTAH.EDU, RS%gnome.cs.cmu.edu@CS.UTAH.EDU, + Simon%m_scrvx2%slb-test.csnet@csnet-relay.CSNet, SPQR%uk.ac.soton.cm@CS.UCL.AC.UK, + Stone%ruthep.rutgers.edu@RUTGERS.EDU, System%uvphys.bitnet@WISCVM.WISC.EDU, + Syvaxtgs%hheouh51.bitnet@WISCVM.WISC.EDU, Thobe@EE.UCLA.EDU, Wendy%crnlgsm.bitnet@WISCVM.WISC.EDU, + U04z%cbebda3t.bitnet@WISCVM.WISC.EDU, X854%ddagsi3.bitnet@WISCVM.WISC.EDU, + Zeffi%finabo.bitnet@WISCVM.WISC.EDU, "*APS:<BEEBE.TEX.DVI>MAIL.TXT.1"@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: <12298494041.11.BEEBE@SCIENCE.UTAH.EDU> + +Two bug fixes are reported in this note. The family has now +been distributed to over 100 sites, and my secretary has +been busy for several days getting packages mailed, with +still a dozen or so to go out. + +I have received several reports of promising work in +progress which is summarized in the following paragraphs. + +At least one site (Doug Henderson at Berkeley) is adapting +dvialw to support the Mergenthaler Linotronic +PostScript-based phototypesetter, and I hope to visit there +next week. + +A couple of sites report work (or good intentions) on +enhancing the dvialw special command support. Brendan McKay +at The Australian National University in Canberra has done +some very nice work adding PostScript support as TeX macros +which result in \special{} commands, and has a port to the +Amiga well on the way. He has also implemented the virtual +font mechanism for VAX VMS. I hope he'll consider writing +up the PostScript work for TUGBoat! + +Dean Guenther at Washington State University is implementing +the family on IBM VM/CMS using the Waterloo C compiler. + +I also have first reports of use of dvialw with the TI +OmniLaser, which sports version 45.0 of the PostScript +interpreter (Apple's 2 LaserWriter models are versions 23.0 +and 38.0 respectively); the use of the "NOTE" paper type in +the dvialw.ps /BOJ macro needs to be changed to LETTER, +since the TI printer doesn't recognize that paper type. +This can be handled portably by some inserting some +PostScript code to check for the existence of that paper +type, but I want to wait and see what changes are needed for +the Mergenthaler before a new version of dvialw.ps is +introduced. + +The HPLJ+ driver, dvijep, is known to work on the Personal +Computer Products LaserImage 2000 (Ricoh engine), as well as +on a MIL-STD clone, the Mitek 110T. Isaac Salzman at RDL is +fighting the DataProducts LZR-1230, which is supposed to +emulate the HPLJ+, but apparently has some problems. + +For the VAX VMS implementation, the suggestion was raised by +Ned Freed at Harvey Mudd College of using a third parameter, +"ctx=stm", to fopen(), which apparently gets around the need +for special versions of fseek() and ftell() in vaxvms.c. I +haven't done this for two reasons. First, the option is not +documented; it was found in microfiche listings of the C +runtime library, and could disappear, or be changed, in +future versions of VMS C. Second, and most importantly, not +all existing software on VMS knows how to handle stream mode +files, which are new with VMS Version 4. In particular, the +Kellerman and Smith TeX implementation and Imagen DVI driver +and spooler program on which we rely heavily on our VMS +systems do not, and require fixed blocked 512-byte binary +records for DVI and font files. Changing to stream mode +would be very awkward for us. The latest version of the K&S +software with Metafont and enhanced support for our Imagen +3320 printer is on order, and if it includes stream file +support, I may change my position. I cannot think of +anything good to say about record-structured file systems +like VMS and IBM MVS; the MS-DOS, TOPS-20 and Unix view of +files as simple byte streams makes life MUCH easier. + +John Pavel at NPL reported some typos in the latest edition +of the DVI driver documentation in dvidriver.ltx and +dviman.texinfo. I have fixed both of these, so some of you +receiving later copies of Version 2.07 will have them +incorporated. I regrettably forgot to rerun GNU EMACS +texinfo-format-buffer on dviman.texinfo after I updated it, +and consequently 3 errors slipped by. Here is VAX VMS style +difference listing: + +************ +File SYS$LIBROOT:[PLOT79.TEX.DVI.DOC]DVIMAN.TEXINFO;5 + 624 @item @b{@@} + 625 Redisplay current page with @i{startup} page positioning. +****** +File SYS$LIBROOT:[PLOT79.TEX.DVI.DOC]DVIMAN.TEXINFO;3 + 624 @item @b{@} + 625 Redisplay current page with @i{startup} page positioning. +************ +************ +File SYS$LIBROOT:[PLOT79.TEX.DVI.DOC]DVIMAN.TEXINFO;5 + 634 2, @dots{}. The @TeX{} page numbers are displayed in the + 635 status window. This is a recursive display; if you respond +****** +File SYS$LIBROOT:[PLOT79.TEX.DVI.DOC]DVIMAN.TEXINFO;3 + 634 2, @dots. The @TeX{} page numbers are displayed in the + 635 status window. This is a recursive display; if you respond +************ +************ +File SYS$LIBROOT:[PLOT79.TEX.DVI.DOC]DVIMAN.TEXINFO;5 + 917 EMAIL: Beebe@@Science.Utah.Edu (Internet) + 918 @end display +****** +File SYS$LIBROOT:[PLOT79.TEX.DVI.DOC]DVIMAN.TEXINFO;3 + 917 EMAIL: Beebe@Science.Utah.Edu (Internet) + 918 @end display +************ + +Number of difference sections found: 3 +Number of difference records found: 3 + +DIFFERENCES /IGNORE=()/MERGED=1/OUTPUT=SYS$LIBROOT:[PLOT79.TEX.DVI.DOC]DVIMAN.DIF;1- + SYS$LIBROOT:[PLOT79.TEX.DVI.DOC]DVIMAN.TEXINFO;5- + SYS$LIBROOT:[PLOT79.TEX.DVI.DOC]DVIMAN.TEXINFO;3 + +In dvidriver.sty for Version 2.07, you need to insert a +missing macro which is used in the index file: + + \newcommand{\FNNX}[1]{{\tt #1}} + +Finally, here are two bug fixes, both VMS-specific, and only +one affects the driver family as currently distributed. + +[29-Apr-87] from Brendan Mackay (munnari!anucsd.oz!bdm@seismo.CSS.GOV) + In machdefs.h, change + #define REWIND(fp) fseek(fp,0L,0) + to + #define REWIND(fp) FSEEK(fp,0L,0) + This is not necessary for the family as distributed, but + Brendan has implemented the virtual font changes + necessary for VAX VMS; they should be incorporated in a + future release. + +[29-Apr-87] from Brendan Mackay (munnari!anucsd.oz!bdm@seismo.CSS.GOV) + The code for vms_read() [in vaxvms.c] has problems. One + is that you don't test for end of file. The other is + that there is a bug in the C library which prevents you + asking for more than 65535 bytes at a time. It is + documented that no more than 65535 bytes will be + returned, but not that you can't ask for more. If you + do, it reduces your request mod 65536! Here's a + replacement: + +/**********************************************************************/ +/*-->READ*/ +int +READ(file_desc,buffer,nbytes) +register int file_desc; +register char *buffer; +register int nbytes; +{ + register int ngot; + register int left; + + for (left = nbytes; left > 0; /* NOOP */) + { + ngot = read(file_desc,buffer,(left > 65024 ? 65024 : left)); + if (ngot < 0) + return (-1); /* error occurred */ + if (ngot == 0) /* eof occurred */ + return(nbytes-left); + buffer += ngot; + left -= ngot; + } + return(nbytes-left); +} +------- |