TeXhax@Score.Stanford.EDU (TeXhax Digest) (10/21/88)
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 <phil@rice.edu>
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
<phil@Rice.edu>
------------------------------
Date: Sun, 16 Oct 88 00:40:23 EDT
From: Chris Torek <chris@mimsy.umd.edu>
Subject: Re: UNIX, typesetter & DVI padding format
In article <2774.phil.titan@Rice> William LeFebvre <phil@rice.edu> 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 <BNB@SEED.AMS.COM>
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 <JEPTEX@star.tamu.edu>
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 <kerkhoff%exp.bessy.dbp.de@RELAY.CS.NET>
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 <unido!unidocv.ls1.informatik.uni-dortmund.de!mertens@uunet.UU.NET>
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 <wattsdg%bernoulli@hub.ucsb.edu>
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 <chris@mimsy.umd.edu>
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 <your name> % 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]<TEX.TEXHAX>TEXHAXnn.yy
%%% nn = issue number
%%% yy = last two digits of current year
%%%\bye
%%%
------------------------------
End of TeXhax Digest
**************************
-------