22-Nov-88 12:49:30-MST,15692;000000000001 Date: Tue 22 Nov 88 12:49:29-MST From: "Nelson H.F. Beebe" Subject: DVI driver family update #18 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: <12448648668.45.BEEBE@SCIENCE.UTAH.EDU> DVI Driver Family Update #18 [22-Nov-88] ============ INTRODUCTION ============ This newsletter has probably been too long in preparation, but I've just had too many things to occupy my time with to get it out earlier. A great many people have corresponded with me about the driver family, and I thank them for their feedback. There are several new drivers in the works for the next release; news about them will follow in two newsletters mailed shortly after this one. ================= DVI FAMILY ACCESS ================= This mailing list now reaches 250 sites. Here are some file access counts that reflect how often people are accessing our TOPS-20 master file repository via ANONYMOUS FTP to SCIENCE.UTAH.EDU: @file-access-count (of files) anon:*.* File Read Access Listing (Sorted by Name) 22-Nov-88 11:33:11 ------------------------------------------------------------------ File | Reads | Age | Reads/Day ------------------------------------------------------------------ PS:00PCDOS.TXT.1 407 403 1.00 PS:00README.TXT.38 217 44 4.93 PS:00TOPS20.TXT.7 214 653 .32 PS:00VMSSETUP.TXT.3 240 462 .51 ------------------------------------------------------------------ @file-access-count (of files) td:*.tar* File Read Access Listing (Sorted by Name) 22-Nov-88 11:33:38 ------------------------------------------------------------------ File | Reads | Age | Reads/Day ------------------------------------------------------------------ DVI.TARZ.1 379 371 1.02 DVI.TARZ-001.1 15 48 .31 DVI.TARZ-002.1 9 48 .18 DVI.TARZ-003.1 12 48 .25 DVI.TARZ-004.1 9 48 .18 DVI.TARZ-005.1 10 48 .20 DVI.TARZ-006.1 11 48 .22 DVI.TARZ-007.1 13 48 .27 DVI.TARZ-008.1 9 48 .18 DVI.TARZ-009.1 10 48 .20 DVI.TARZ-010.1 8 48 .16 DVI.TARZ-011.1 10 48 .20 ------------------------------------------------------------------ Other operating systems do not maintain file reference counts, and VAX VMS doesn't even support a last read date for files, so it is not possible to tell how often other repositories are being accessed. Still, the above figures, together with our tape and floppy shipments, and the availability of the drivers at 8 other sites, leads me to estimate that well over 1000 sites are now using them. As can be seen from the last list above, the compressed dvi.tarz file is now also available in pieces (each 102400 bytes, and less for the last one) which can be appended into a single larger file which can be run through uncompress and tar to unbundle. This was precipitated by problems several people have reported in sustaining Internet FTP connections long enough to get the complete file. The particular parcel size of 102400 was chosen to be a multiple of 512 bytes, so that retrievals to VAX VMS systems do not corrupt the pieces by padding to disk block boundaries. Since the NFSnet backbone came on-line a couple of months ago (it runs at T1 speed (1.5Mbs) instead of 56Kbs), I have noticed a definite improvement in Internet access. I'm now able to work on a machine in San Francisco almost as if it were local, whereas prior to the upgrade, on some days, I could wait 30 sec for a character echo. I extend deepest thanks to the net architects and authorities, and to the government funding agencies, for making this possible. ================= VERSION NUMBERING ================= You will note in the 00revhst.txt entries given below that the version numbers now carry a minor edit number. The current version of the drivers in my development directories is 2.10.14, which reflects 14 changes (in the entire family) since 2.10 was released. You will not see these edit numbers in the 2.10 distribution, although the sources in all the official distribution channels are now up to that level. Version 2.11 incorporates a version.h file which is included by the dvi*.c files, and is updated whenever any edit is applied to the family. This should make it easier in the future to determine whether reported problems have been fixed in the version you are running at your site. =========== TURBO C 2.0 =========== Several people have inquired whether Turbo C can be used for the DVI drivers on the IBM PC. In newsletter #16, I reported that Turbo C version 1.5 was completely unusable for the drivers, but that Borland had fixed in their in-house development version all the errors I reported. Somehow, their promise to make me a beta test site for 2.0 was not carried out, and I only got the 2.0 update (with Pascal 5.0, the new Turbo Assembler, and the windowing debugger) in mid Nov-88. I am now engaged in attempting to make the drivers work under 2.0. The good news so far is that I've succeeded in getting 2 test pages to print successfully. The bad news is that there are still problems. ungetc() on the last byte of the file leaves the file pointer at end-of-file, instead of at the last character, breaking the font loading. A work-around has been applied, and it produced some correct output. However, when run without debugging statements, the drivers go into an infinite loop in a call to strrchr("hello",'/'). It will likely take several more evenings of work to track this down; in the meantime, cross your fingers that I find the bugs. ========== DEC LPS-40 ========== [20-Sep-87] Somehow an important contribution from John Sauter in Dec-87 slipped through the cracks. dvialw with minor changes can be made to run on the DEC LPS-40, a 40 page/minute PostScript printer (currently the faster PostScript printer on the market). The first problem is that the LPS-40 does not use the serial line protocol, and gets very unhappy when the Ctl-D marking the end-of-PostScript-file is found. Rather than change dvialw.c, it is easiest to include a macro that turns Ctl-D into a no-op; just before the line /TeXdict 200 dict def % dictionary for these definitions in dvialw.ps, install the following 11 lines, and if you have an LPS-40, remove the %%% prefixes. % control D (EOT) -- do nothing. % Usage -- for PostScript printers that do not use the LaserWriter's % serial protocol, the ^D described above will be sent to the % interpreter for execution. Make sure that it does nothing. This % definition must be outside TeXdict since it is invoked at the end of % file, after TeXdict is removed from the stack by EOJ. % % Remove the following 3 %%% lines for such printers. %%%(\004) cvn %%%{ %%%} def The second problem is that the LPS-40 knows about neither note nor letter paper sizes, so replace the /BOJ macro by /BOJ { 72 Resolution div 72 Resolution div scale userdict /note known {NOTE} % default page format for ALW {userdict /letter known {LETTER} % default page format for others {Mtrx currentmatrix pop} ifelse} % if letter unknown, use current ifelse } bdf This definition can be used with any PostScript printer. John also comments further: >> The LPS40 is driven by a fast serial interface with an unusual >> protocol. It uses a multidrop line driven at 10 megabits per >> second. The protocol involves packets containing device >> addressing and error checking information, so control D is not >> used as a job terminator; job separation is done using flags >> in the packets which are distinguished by the packet format >> from the data stream. >> >> The short answer is: The LPS40 is driven by DECnet over >> Ethernet. >> >> The engine is manufactured for Digital by Ricoh, the Japanese >> company that also manufactures the LN03 engine. I don't know >> whether it is write-white or write-black, but I do observe >> that Computer Modern fonts which have been tuned for the LN03 >> provide satisfactory results on the LPS40. I have not tried >> fonts tuned for the Imagen. In tests to determine the printer name from the PostScript interpreter itself, John also discovered that the LPS-40 has no interactive mode, which is invoked by the `executive' command on the Apple LaserWriter. Both the `executive' and Ctl-D generate undefined command errors on the LPS-40. John suggested that the Ctl-D macro above might be usable (i.e. harmless) on any PostScript printer, but I think it may be undesirable to define it for serial printers. In the best of all possible worlds, dvialw would produce PostScript output that had no terminal Ctl-D, because that would be supplied by the spooler program at the end of every job send to a serial PostScript device. The Ctl-D is ESSENTIAL, because it is the synchronizing character PostScript uses to find the end of the current job when an error occurs; without it, all following jobs would be flushed in an error situation. Many people, however, particularly in the personal computer environment, drive PostScript printers directly using simple COPY commands (e.g. `COPY foo.alw PRN' on MS-DOS). In those, there is no spooler to provide the Ctl-D, and it would be extremely frustrating for a user unfamiliar with the printer to have an error early on cause all subsequent output to be lost. I therefore elected to have dvialw and lptops terminate their output files with Ctl-D. On systems with PostScript spoolers, the extra Ctl-D doesn't hurt; PostScript just sees an empty job between the two Ctl-D's, and ignores it. One possibility would be to test the printer name, and define the Ctl-D macro only for those that require it: statusdict begin product % this gets printer name (PrintServer 40) eq % if DEC LPS-40 {(\004) cvn{ } def} % then make Ctl-d a no-op {} % else do nothing ifelse end The Apple LaserWriter Plus returns (LaserWriter Plus) in response to a `product' command. I am interested in hearing from people who can try this on other printers; if it works, I will incorporate it in dvialw.ps as a standard feature. I have installed it in our local dvialw.ps without ill effects (it has been running for 2 months as of 22-Nov-88). ================ REVISION HISTORY ================ Here are the 00revhst.txt change log entries since 31-May-88, when newsletter #17 was issued: [27-Oct-88] 2.10.14 {Thanks to Daniel Ridings } Daniel kindly provided me with two 256-character Greek font files and a couple of test .tex files for displaying the font tables. I have used this to verify that dvialw functions correctly with 256-character fonts. This revealed a bug with PCC-20, which has an incorrect isprint() function that caused erroneous output. The fix is to insert in main.h after the #include the following statements: #if PCC_20 /* PCC-20's definition of isprint() incorrectly identifies characters outside the range 0..0177 as printable, but since text output is only 7-bit data, the result is incorrect output in dvialw for such characters. This erroneous output happens if 256-character fonts are used. Such an error will not impact machines with 8 or more bits per character. */ #undef isprint #define isprint(c) (((_ctype_+1)[c]&(_P|_U|_L|_N)) && !(c & ~0177)) #endif /* PCC_20 */ With this fix, dvialw produces a correct 256-character font table. However, the test files print only the first 128 characters when run with dviimp or dvijep. Imagen imPress has a limitation of 128 characters per font. The Hewlett-Packard LaserJet Plus supports 8-bit fonts (and dvijep uses them), but allows entries only for 192 of the positions. The Series II supports 2 types of 256-character fonts, one with 192 entries, and one with 245 entries. For both dvijep and dviimp, therefore, recoding will be necessary to split 256-character fonts into two fonts. For all of the dot-matrix printers, for which a bitmap is constructed in memory, the drivers should support 256-character fonts without further changes. [15-Sep-88] 2.10.13 {Thanks to Bob Desinger } Change page count typeout in readpost.h to use singular instead of plural if the_page_count < 2. [01-Sep-88] 2.10.12 {Thanks to Francois Chahuneau} Change dvialw.ps NF macro to make BitMaps have 256 instead of 128 entries to support extended character sets. [16-Aug-88] 2.10.11 {Thanks to Benjamin Yu } In initglob.h about line 51, change size_limit = 255; /* largest character size */ to size_limit = 128; /* largest character size */ The HP LaserJet Plus has a character cell height and width range limitation of 1..255, but further restricts individual character dimensions to 0..128. This bug is exposed if you attempt to print characters at size magstep 4 or larger, such as the following test TeX file supplied by William E. Anderson : \magnification=\magstep4 $$f(x)=\int{g(x)\over x}\,dx$$ \vfill\eject\bye for which the integral sign will be lost without the fix, and will appear once the fix is applied. =============================THE END============================= -------