29-Apr-87 18:45:30-MDT,9269;000000000001 Date: Wed 29 Apr 87 18:45:29-MDT From: "Nelson H.F. Beebe" 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: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); } -------