TeXhax Digest Friday, October 21, 1988 Volume 88 : Issue 93 Moderator: Malcolm Brown Today's Topics: Re: UNIX, typesetter & DVI padding format Re: UNIX, typesetter & DVI padding format re: no numbers allowed in latex commands Journals that accept/request/require TeX input (bucket of water) four column page RE: TEX file repository for Europe Printing out box coordinates Utility for conversion from LaTeX to troff wanted RE: texhax #90 v88 TeX driver for NEC/EsNEXT/EDIT Information wanted Padding of DVI files ---------------------------------------------------------------------- Date: Sat, 15 Oct 88 17:29:13 CDT From: William LeFebvre Subject: Re: UNIX, typesetter & DVI padding format > For whatever reasons, at least one common VMS TeX has chosen to violate > the proper DVI file encoding. A DVI file is supposed to end with > between 4 and 7 bytes of 223's. Although I can't say that you're completely wrong, you are being a little misleading. In both dvitype.web and tex.web, in the sections that describe the DVI format, it very clearly states: An identification byte, |i|, comes next; this currently equals 2, as in the preamble. The |i| byte is followed by four or more bytes that are all equal to the decimal number 223 (i.e., 337 in octal). \TeX\ puts out four to seven of these trailing bytes, until the total length of the file is a multiple of four bytes, since this works out best on machines that pack four bytes per word; but any number of 223's is allowed, as long as there are at least four of them. In effect, 223 is a sort of signature that is added at the very end. So, although TeX is documented to put out between 4 and 7 trailer bytes, the documentation *clearly* states that any number of bytes greater than or equal to 4 is allowed. If a VMS TeX puts out more than 7 trailer bytes, it is not violating the DVI spec. It is not behaving as documented by the original tex.web, but it is still following the DVI format. Because of the peculiarities of the VMS environment, I think that this sort of "system dependent" variation is perfectly acceptable. I know (from experience) that your "iptex" will not handle it, however (or at least it didn't at one time). William LeFebvre Department of Computer Science Rice University ------------------------------ Date: Sun, 16 Oct 88 00:40:23 EDT From: Chris Torek Subject: Re: UNIX, typesetter & DVI padding format In article <2774.phil.titan@Rice> William LeFebvre notes that >So, although TeX is documented to put out between 4 and 7 trailer >bytes, the documentation *clearly* states that any number of bytes >greater than or equal to 4 is allowed. If a VMS TeX puts out more than >7 trailer bytes, it is not violating the DVI spec. Oops. Phil is, of course, correct. I found out about the extra trailers on VMS the hard way, after having read the DVI description and assumed the number would be between 4 and 7. >I know (from experience) that your "iptex" will not handle >it, however (or at least it didn't at one time). It does now (that was how I found out about it). Chris ------------------------------ Date: Sun 16 Oct 88 15:25:42-EDT From: b beeton Subject: re: no numbers allowed in latex commands g.j. stemerdink had a problem when he tried to create and use commands of the form \mc1 , \mc2 , etc. the rules defining what a command name may look like are basic to tex, and followed by latex. this is the description from the latex manual, page 33: Command names consist of either a single special character like ~, a \ followed by a single nonletter (as in \@), or a \ followed by a string of letters. since numerals are nonletters, they fall into the second group described above. one can define a command \1 , \2 , etc., but not (under normal circumstances -- in tex, there are exceptions to almost anything if you want to try hard enough!) a command of the form attempted by mr. stemerdink. -- barbara beeton ------------------------------ Date: Sun, 16 Oct 88 21:20:04 CDT From: J E PITTMAN Subject: Journals that accept/request/require TeX input (bucket of water) There have been a few flames lately about journals that use TeX for their type- setting. I, for one, wish to loudly and enthusiastically applaud all such journals, even those that use LaTeX. Consider, if you will, the old alternative of: To submit an article, an author must type the text into a precise format; mail it, with graphics, to the journal; wait while the journal typesets the material onto odd-sized sheets of paper called galley proofs; wait until the journal editor reviews it; wait until it is mailed back; make corrections; mail it back; wait while the journal puts the correction in; wait...; wait...; wait....................!!!!!!!!! Now consider, if you will, the alternative of: To submit an article, an author must type the text into a precise format on a computer; typeset and print it on a low-grade (300dpi) printer; proof and correct it; mail it electronically to the journal and mail the graphics separately; wait until the journal mails (electronically = fast) their editorial comments; respond iteratively to the comments; wait until the article is published. I, for one, prefer the fastest route from draft to publication. My only major criterians are that the output should look professional (between typed and book quality, preferably close the the latter) and that I should not have to wait, and wait, and wait, and wait, and wait...................... TeX (and LaTeX, for people that can't handle TeX) meet these criterian. J E Pittman User Services Group Computing Services Center Texas A&M University Bitnet: JEPTeX@TAMVenus Internet: JEPTeX@Venus.TAMU.Edu ------------------------------ Date: Mon, 17 Oct 88 10:17 GMT From: SCCS6038%IRUCCVAX.UCC.IE@Forsythe.Stanford.EDU Subject: four column page Hi there, I am wondering if anybody has implemented a hack to enable four (4) columns of text on a page. I am aware of LaTeX's \twocolumn command and also of the file twocolumn.sty, however, I am unable to 'double up' the effect of these facilities. Any help would be greatly welcomed. Thanks a lot in advance, Aidan Delaney sccs6038%iruccvax.bitnet@cunyvm.cuny.edu ------------------------------ Date: 17 Oct 88 03:19 PDT From: Hans-Georg Kerkhoff Subject: RE: TEX file repository for Europe Hi Malcolm, enclosed you find an extract of an answer by Michael DeCorte to my question regarding to an European TEX Archive Server. You may post it to the list, because it may be of general interest to Europen users who have no FTP access. %%% %%% OK! here goes... %%% ============================================================================== extract from readme of archive-server@clarkson.edu . . . 4) Keepers of Slave Repositories of the LaTeX Style Collection UK users: Aston University maintains a TeX archive covering all aspects of TeX/LaTeX/Metafont and ancilliary software. UKTeX (like TeXhax) digests are distributed from Aston. For users with Colour book software `FTP' access is available, for all users mail access is available. Send enquires in the first instance to info-tex@uk.ac.aston (via internet use pabbott@nss.cs.ucl.ac.uk). . . . Michael DeCorte // (315)268-2292 // P.O. Box 652, Potsdam, NY 13676 Internet mrd@sun.soe.clarkson.edu // Bitnet mrd@clutx.bitnet Clarkson Archiver Server archiver-server@sun.soe.clarkson.edu archive-server%sun.soe.clarkson.edu@omnigate.bitnet dumb1!dumb2!dumb3!smart!sun.soe.clarkson.edu!archive-server ------------------------------ Date: Mon, 17 Oct 88 10:42:18 EDT From: ajb%cornea.mitre.org@gateway.mitre.org Subject: Printing out box coordinates I would like to present the following problem as a puzzle for all TeXhax'ers. I've been trying to solve this one for some time; although I'm sure the solution must be possible and probably trivial. Given some text with a box built around it (e.g. vbox or hbox), I would like to have TeX (or Latex) print out the physical coordinates of the box as it will be printed on the paper. That is, I would like to have TeX print the x,y coordinates of one of the corners of the box (in any unit) relative to the physical page. Also, I'd like to print out the dimensions of the box, but I believe this to be a simple matter. Can anyone help ? Alan Broder ajb@mitre.arpa Image Processing Technology Center The MITRE Corporation ------------------------------ From: Michael Mertens Date: Mon, 17 Oct 88 15:13:45 +0100 Subject: Utility for conversion from LaTeX to troff wanted Does anyone know about a utility for conversion from LaTeX format to troff format? Thanks in advance Michael Mertens Lehrstuhl Informatik 1 Universitaet Dortmund West Germany ------------------------------ Date: Mon, 17 Oct 88 12:30:16 MET From: SCHRAMA --TUDGV1 Subject: RE: texhax #90 v88 Dear TeX users, The following VAX/VMS fortran source code enables you to read any tape (provided it on a reel, magnetic and 9 track). I hope it helps Chris Torek who addressed tape problems on VAX/VMS systems in texhax #90 88. Please use the routines as they are. Please do feel free to modify the tape_assign subroutine. The routines seem to do well on most binary tapes we receive on our VAX. Reading the VMS manuals (which are awfully difficult to understand) might help occasionally. ============================== cut here ============================== c----------------------------------------------------------------------- c *** Tape handling routines *** c c Only for operating system VMS 3.1/4.1/4.2 VAX 751 c c Programmer: Ejo Schrama c Last revision date: 19-1-1987 c c TUD ZWO 1985,1986,1987,1988 c----------------------------------------------------------------------- c c TAPELIB.FOR contains routines for tape handling. Use is made of qiow c routines (see opsys manuals) which perform direct access to tapes. c c In this subroutine library the following routines are defined: c c -1 tape_getblk <-- gets a block regardless size from tape c -2 tape_putblk <-- puts a block regardless size to tape c -3 tape_assign <-- assigns the tapeunit to an channel (always needed) c -4 tape_rewind <-- rewinds the tape to a starting position c -5 tape_putmrk <-- writes an end of file marker on tape c c The blocksize must be in the range of 14 to 65,535 bytes since c this is the acceptable boundary for the tape controller. Blocks c smaller than 14 bytes will be seen as "noise blocks" and are there- c fore ignored by the controller. Blocks larger than 65,535 cause c a data overrun message in the error handling. It is advisable to c use a blocksize of some 8k. c c The initializing routine tape_assign has to be used. The tape must be c mounted as a foreign tape by means of the DCL command MOUNT/FOR MT: c c All routines use common block /tape_info/ internally. Please do not c affect or use the common block. c---------------------------------------------------------------------- c Error handling, most routines return the variables: c c -1 status (i*4) ... This variable indicates whether the system c service utility was succesful. It might be c tested as a variable (if it is 1 then routine c was called succesfully). If it is not 1 it can c be tested with the rtl routine lib$signal as c call lib$signal(%val(status)) which causes an c echo on the screen. c c -2 code (i*2) ..... This code can be tested on the condition that c it should be equal to ss$_normal. If not, you c can check it by trying other ss$_ checks. (the c ss$_ macros are imported by the include stmnt.) c c Variable status should be used as a first level check, variable code c as a second level check. The following program is worthwhile to con- c sider as a typical example: c c c include '($ssdef)' c . c . c len=65535 c call tape_getblk(block,len,status,code) c c if (status.ne.1) then ! routine not serviced properly? c call lib%signal(%val(status))! check what went wrong c stop ! prevent further continuation. c endif c c if (code.ne.ss$_normal) then ! the system request was fulfilled c ! however something unusual occurred c if (code.eq.ss$_parity) then c . c . c . c else if (code.eq.ss$_endoffile) then c . c . c . c else etc. c c----------------------------------------------------------------------- subroutine tape_assign(status) implicit none include '($ssdef)' integer*4 channel,status,sys$assign common /tape_info/ channel status = sys$assign('mta0',channel,,,) ! mta0 is the logical name ! for the tape unit, this ! is installation dependent! return end c------------------------------------------------------------------------ c c rewinds a tape in fast reverse mode c c------------------------------------------------------------------------ subroutine tape_rewind(status,code) implicit none external io$_rewind include '($ssdef)' integer*4 channel,status,sys$qiow integer*2 func1,iosb(4),code common /tape_info/ channel func1=%loc(io$_rewind) status=sys$qiow(,%val(channel),%val(func1),iosb,,,,,,,,) code=iosb(1) return end c------------------------------------------------------------------------ c c subroutine tape_getblk(block,len,status,code) c c this routine reads variable length blocks from a tape that is c assigned by tape_assign in this library c c "Block" equals to a byte array. Declare it as "byte block(65535)" c to prevent that data overflow occurs during reading the tape c c len is an output parameter for the amount of bytes transferred at c the read operation. (integer*4) c c------------------------------------------------------------------------ subroutine tape_getblk(block,len,status,code) implicit none external io$_readvblk,io$m_datacheck include '($ssdef)' integer*4 channel,status,len,sys$qiow integer*2 func1,func2,iosb(4),code byte block(1) common /tape_info/ channel func1=%loc(io$_readvblk) func2=%loc(io$m_datacheck) status=sys$qiow(,%val(channel),%val(func1+func2),iosb,,, - block,%val(65535),,,,) code = iosb(1) ! compare code with the ss$ macros len = iosb(2) ! length of variable block read return end c------------------------------------------------------------------------ c subroutine tape_putblk(block,len,status,code) c c this routine writes variable blocks on a tape that is assigned c using routine tape_assign of this library c c "block" is an byte array, the size of it must be eq to at least "len" c c "len" is an input parameter for the amount of bytes to transferred c during the write operation. (integer*4) c c after calling this routine it is set to the amount of bytes trans- c ferred. c------------------------------------------------------------------------ subroutine tape_putblk(block,len,status,code) implicit none external io$_writevblk,io$m_datacheck include '($ssdef)' integer*4 channel,status,len,sys$qiow integer*2 func1,func2,iosb(4),code byte block(1) common /tape_info/ channel func1=%loc(io$_writevblk) func2=%loc(io$m_datacheck) status = sys$qiow(,%val(channel),%val(func1+func2),iosb,,, - block,%val(len),,,,) code =iosb(1) ! status word len =iosb(2) ! length of variable block written return end c------------------------------------------------------------------------ c c Write a tapemark at the current tape position (file separation is c usually 1 mark, end of tape = 2 marks) c c------------------------------------------------------------------------ subroutine tape_putmrk(status,code) implicit none external io$_writeof include '($ssdef)' integer*4 channel,status,sys$qiow integer*2 func1,iosb(4),code common /tape_info/ channel func1=%loc(io$_writeof) status = sys$qiow(,%val(channel),%val(func1),iosb,,,,,,,,) code = iosb(1) return end ============================== cut here ============================== Ejo Schrama, Department of Geodesy TU Delft Thijjseweg 11 2629 JA Delft The Netherlands Bitnet: gdfgejo@hdetud1 surfnet: tudgv1::schrama ------------------------------ Date: Sat, 15 Oct 88 23:06 5 From: LINGFUYUN@nuhub.acs.northeastern.edu Subject: TeX driver for NEC/EsNEXT/EDIT Dear TEXHAX editor: Below is the readme file of my newly derived NEC/Epson LQ printer driver for TeX dvi files. I guess somebody else may also interested in it. Sincerely Yours Fuyun Ling A TeX Driver for NEC-Pinwriter/Epson-LQ Printers by Fuyun Ling This is, I believe, the first non-commercial TeX driver for Epson LQ compatible printers. It prints at 360x180 dpi density. I don't aware if there exists any other, commercial or non-commercial, Epson-LQ TeX driver has the ability to print at such a resolution. I developed this driver for my NEC-P2200 printer, although I believe it can also be used for other Epson LQ compatible printers. I did not test it on an LQ printers though, because I don't have one. Please let me know how it works if anyone tests it. This driver uses laser printer fonts. These fonts are widely available in public domain. The only problem is that it uses the magstep 1 fonts of the laser printer as its magstep 0 fonts. As a result, the magstep half (394dpi) fonts are not easy to find. If anyone has METAfont program and will to generate as set of fonts at that resolution, please let me know. This will definitely make this driver more useful. As I mentioned above, this driver is adopted from Dr. Beebe's (University of Utah) driver family. To be precise, it is derived from DVITOS - the driver for Toshiba printer. The manual for the DVITOS driver can be used for this driver. Since this driver need a big bitmap (about 800k) that is beyond the capability of a PC's ram, I used two different techniques: 1) The output is directly sent to LPT1: for printing. You may have to reroute the output if you don't hook the printer to this port. 2) To construct a bitmap for each page, I use the hard disk or EMS memory as a scratch pad. So you need 800k EMS or free hard disk space to use this driver. It will first check the EMS memory. If the EMS memory does not exist or it is not sufficient, the program will use the hard disk. The speed of this driver is pretty good. I have used it on my NEC-P2200 printer and my 8 Mhz XT clone. When the EMS memory is used, it takes 3-6 minutes to print a full page of double spaced or single spaced text. 3 to 4 minutes more will be needed if there is no EMS memory. If you use a fast printer or an AT the speed will even better. If you interrupt this program use control-C, please reboot the system to free the EMS, or use chkdsk/f to free any disk space that might still be locked. In order to use this driver, as I mentioned before, you need the fonts at 360dpi, [394dpi], 432dpi, 518dpi, and 622dpi. I have included a batch file that I used on my computer. Of cause, in order to use this batch file, you need to set the directory path as mine. That is the font files are in \tex\pixel\dpiXXX where XXX is either 360, [394], 432, 518, 622 for different font size. Since this driver is derived from the Beebe's driver family, I feel the right place of this driver is in public domain. You can use it or distribute as you wish. The only requirement is you must also distribute this file and it can not be used for any commercial purpose. Of cause, any contribution will not be denied and greatly appreciated, if you feel this program is useful to you. If you have any comments or suggestions or problem, please send a message to me. You have three choices if you want to contact me. You can leave a message on the Boston Channel 1 bulletin board to me. The telephone number of Channel 1 is (617)354-8873. If you are connected to any university computer you can send a E-mail to LINGFUYUN@nuhub.acs.northeastern.edu. Or finally, you can send a letter to me to the address given below. The following files are included: dvineclq.exe; readme; nec.bat. I wish you like this program. I wish my efforts in the past three months will be useful beyond my own use. Fuyun Ling 202 Chestnut Ave. Jamaica Plain, Mass. 02130 or lingfuyun@nuhub.acs.northeastern.edu ------------------------------ Date: Mon, 17 Oct 88 13:46:05 PDT From: Don Watts Subject: Information wanted I would appreciate some information. I purchased a copy of tex from Addison Wesley publishers, and although their version of tex is written for pc.dos, my system is ms.dos. The program works most of the time, but I do get some errors and improper behavior. Is there an ms.dos version of tex? especially one which is not too expensive? And if I get an ms.dos version, will I be able to use my Addison Wesley preview and dvihp programs with it? Thanks. ------------------------------ Date: Mon, 17 Oct 88 21:41:52 BST From: CET1%phoenix.cambridge.ac.uk@NSS.Cs.Ucl.AC.UK Subject: Padding of DVI files In TeXhax #90, among much sound stuff, Chris Torek writes: > ... For whatever reasons, at least one common VMS TeX has chosen to > violate the proper DVI file encoding. A DVI file is supposed to end > with between 4 and 7 bytes of 223's. This is tendentious. The specification from tex.web (or dvitype.web) says > ... TeX puts out four to seven of these trailing bytes, until the > total length of the file is a multiple of four bytes, since this works > out best on machines that pack four bytes per word; but any number of > 223's is allowed, as long as there are at least four of them. Thus, it is certainly not true that "any DVI file must end with (only) 4 to 7 bytes of 223s", and I don't think it was Donald Knuth's intention to imply "a DVI file written by any implementation of TeX must end with (only) 4 to 7 bytes of 223s". The constraints of one's operating system and filing system may require one to pad the DVI file to a 60-bit word, a 512-byte block, an 80-byte card image, or whatever; and there is a defined way of doing it. My implementation of TeX under IBM's MVS operating system, for example, writes only the 4 to 7 bytes if the record format of the DVI output file is variable-length or undefined-length (RECFM=V or RECFM=U to IBM buffs) but pads to the next record boundary if the format is fixed-length (RECFM=F). How could it be correct to do otherwise? The filing system is going to put something in those bytes, whether you like it or not! (For somewhat historical reasons, my local implementation also defaults the DVI file to having fixed length records of length (guess!) 80. We used to send them to output devices by pouring them down virtual card punches.) Similar remarks apply to GF and PK files (one of the curses of PXL files is that there is no proper way to pad them). In fact, in early versions of the specification of PK format, Tomas Rokicki specified that there should be (only) 0 to 4 246s following the 245 (pk_post), but this was later liberalised to allow any number. (I take some credit for persuading him to make this change.) Chris Thompson JANET: cet1@uk.ac.cam.phx ARPA: cet1%phx.cam.ac.uk@nss.cs.ucl.ac.uk ------------------------------ %%% %%% Concerning subscriptions, address changes, unsubscribing: %%% BITNET: send a one-line mail message to LISTSERV@TAMVM1.BITNET: %%% SUBSCRIBE TEX-L % to subscribe %%% %%% All others: send mail to %%% texhax-request@score.stanford.edu %%% please send a valid arpanet address!! %%% %%% %%% All submissions to: texhax@score.stanford.edu %%% %%% Back issues available for FTPing as: %%% machine: directory: filename: %%% [SCORE.STANFORD.EDU]TEXHAXnn.yy %%% nn = issue number %%% yy = last two digits of current year %%%\bye %%% ------------------------------ End of TeXhax Digest ************************** -------