TeXhax@Score.Stanford.EDU (TeXhax Digest) (10/05/88)
TeXhax Digest Wednesday, October 5, 1988 Volume 88 : Issue 86
Moderator: Malcolm Brown
Today's Topics:
DVI output on the HP DeskJet (why you probably don't want it)
TeX Users Group Meeting Inquiry
TeX/LaTeX math <=> Macsyma
Form letters
RE: PSPRINT and DVITOVDU
Re: BibTeX documentation
Bug in good.top and good.bot?
Unix TeX in C
Re: Problem installing TeX (V88 #80): compiler limits
Re: Postscript, figures, and typesetters
small caps (TeXhax Digest V88 #84)
Page Make-up Chalenge
----------------------------------------------------------------------
Date: Sat 24 Sep 88 18:58:13-MDT
From: "Nelson H.F. Beebe" <Beebe@SCIENCE.UTAH.EDU>
Subject: DVI output on the HP DeskJet (why you probably don't want it)
In TeXhax Digest V88 #83, Mary Coventry
<COVENTRY%UWACHEM.BITNET@Forsythe.Stanford.EDU> writes:
>> Is there a driver for the HP Deskjet printer yet?
Since I have received a few phone calls and Email queries about
this same question, it seems worthwhile to repeat what I told
them. The following text is lifted from one of my recent replies
(14-Sep-88):
>> I talked last week to David Babcock at HP Palo Alto about
>> the DeskJet. He has a driver running for it, but doesn't
>> view it as a satisfactory TeX output device. The problem is
>> that it is a 300dpi printer, but has no memory of any
>> consequence. It supports only 4 downloaded fonts, but has
>> no page bitmap to record characters in, so it cannot do TeX
>> that way. Although many of its commands are compatible with
>> the HPLJ, its font download sequence is different. The only
>> way then to drive it is via full-page bitmaps sent from the
>> host. 8.5 x 11 x 300 x 300 / 8 = 1.05Mb; 6.5 x 9 x 300 x
>> 300 / 8 = 658Kb. Thus at 9600 baud, or 960 char/sec, it
>> will take 685 to 1090 sec (10 - 20 minutes) per page, which
>> is just plain awful. The HPLJ Plus or II will do about 7
>> pages/minute with my drivers. If you really want to go
>> ahead, use dvijet.c (NOT dvijep.c), and change the
>> resolution from 100dpi to 300dpi (XDPI and YDPI), and adjust
>> the resolution in the raster header.
That is, a TeX DVI driver for the DeskJet is not at all
impossible, but will not likely be satisfactory.
------------------------------
Subject: TeX Users Group Meeting Inquiry
Date: 24 Sep 88 22:09:20 EDT (Sat)
From: encore!cloud9!jjmhome!lmann@bu-cs.bu.edu (Laurie Mann)
I gave a paper at the recent TUG meeting on macros for
conditionalized text. At the conference, about 10 people
gave me their business cards, and I said I'd be happy
to send them the macros.
Unfortunately, I went on vacation the week after
the conference, and have been unable to find the
business cards I collected. If you are interested in
the single-sourcing macros, please write to me
or send me E-mail and I'll get them to you.
/*Common gopher button at Nolacon: It's not MY convention, monkey boy!*/
Hacking net address: {harvard,ulowell}!m2c!jjmhome!lmann ** lmann@jjmhome.UUCP
Working net address: harvard!anvil!es!Laurie_Mann (Stratus Computer)
uS(n)ail: Laurie Mann, Stratus, M22PUB, 55 Fairbanks Blvd,
Marlboro, MA 01752
------------------------------
Date: Sun, 25 Sep 88 21:06:04 EDT
From: Mark W. Eichin <eichin@ATHENA.MIT.EDU>
Subject: TeX/LaTeX math <=> Macsyma
Does anyone have code or ideas for easily converting from Macsyma
equation output (any form) to LaTeX or TeX mathematical input? I would
guess that this could take the form of lisp code for Macsyma, or
gnuemacs-lisp code to convert while editing the document, or maybe a
standalone processing program. I'd also be interested in information
on other conversion to or from TeX/LaTeX math representation.
Mark Eichin
<eichin@athena.mit.edu>
SIPB Member & Project Athena ``Watchmaker''
ps. Please reply by email; we haven't gotten any digests since August.
------------------------------
Date: 26 Sep 88 0:34 -0500
From: Michael Doob <mdoob@ccu.umanitoba.ca>
Subject: Form letters
MURALI@TAMLSR in TeXhax vol. 81 asks how to do form letters. The
following setup will handle form letters that are not too bizarre:
(1) Put your macros (perhaps \today and such) in one file, say
lmacs.tex.
(2) Put your form in a file, say lform.tex. It might contain a
fragment of the following type:
\vglue .5in
\leftskip \longindentation \today
\vskip \baselineskip
\begingroup
\obeylines
\parindent=0pt
\sal\ \firstname\ \lastname
\address
\city
\vskip \baselineskip
Dear \sal\ \lastname,
\vskip \baselineskip
\endgroup
... Continue with the body of the letter .
\vfill \eject
(3) Now make the file of records to be inserted into the form:
\input lmacs
\def\sal{Mr.}
\def\firstname{John}
\def\lastname{Doe}
\def\address{123 Main Street}
\def\City{Smalltown, AA 12345}
\input lform
\def\sal{Ms.}
\def\firstname{Jane}
\def\lastname{Roe}
\def\address{341 Oxford Street}
\def\city{Bigcity, ZZ 54321}
\input lform
This last file is run through TeX to get the processed list.
Michael
------------------------------
Date: Fri, 23 Sep 88 16:28 EDT
From: Ted Nieland - SRL <@WPAFB-AAMRL.ARPA:TNIELAND@FALCON>
Subject: RE: PSPRINT and DVITOVDU
Newer version of PSPRINT and DVITOVDU have made it to America. Our friends
from Italy sent a copy over. The new versions are PSPRINT 2.0 and
DVITOVDU 2.0.
This material is available on the new DECUS TeX Distibution Tape. It is
available from the DECUS Library. I am willing to get the PSPRINT and
DVITOVDU to some site who would like to make it available for anonymous FTP.
I can either deposit on such a system or send them a tape with the material.
I did send a copy of the DECUS distribution to TUG (via Barbara Beeton).
NOTE: The new DECUS TeX Collection will be made available through DECUS LUGS
at a later date as part of the 1988 Language and Tools Collection. The DECUS
TeX Tape is VMS based, but does include material for UNIX and MS-DOS. It is a
fairly complete TeXware collection and contains the following:
TeX 2.93 TR2TEX
LaTeX 2.09 PSPRINT 2.0
AMSTEX DVITOVDU 2.0
TeXsis DVI2PS
PICTeX PSFIG
RNOtoTEX GLOTeX
DVI2LN3 IDXTeX
The Utah DVI Driver Collection MAKEINDEX
MetaFont 1.5 LN03 PK Fonts
LSE Template DVIDIS
CDVI for MS-DOS DVIEW for MS-DOS
DVIVGA for MS-DOS PK Fonts for MS-DOS
LaTeX Style Collection
SPELL (VMS Spelling checker that knows TeX and LaTeX)
Any suggestions for additions to the DECUS TeX Collections should be sent
to TNIELAND@WPAFB-AAMRL.ARPA.
| M. Edward (Ted) Nieland - Systems Analyst
| US Snail: | Arpa Internet: |
| Systems Research Laboratories, Inc. | TNIELAND@WPAFB-AAMRL.ARPA
| 2800 Indian Ripple Road WP 196 | TNIELAND%FALCON@WPAFB-AAMRL.ARPA
| Dayton, OH 45440 |
| A T & T: (513) 255-8846/8760/5156
------------------------------
Mail-From: PATASHNIK created at 26-Sep-88 06:23:58
Date: Mon 26 Sep 88 06:23:57-PDT
From: Oren Patashnik <PATASHNIK@Score.Stanford.EDU>
Subject: Re: BibTeX documentation
> From: toms@ncifcrf.gov
> Subject: Re: yaffb (yet another format for bibtex)
> Fortunately, I contacted Stephen Gildea, who kindly sent documentation
> to me (it is called btxdoc.tex), and so I could finish the task.
That was very nice of Stephen, but he shouldn't have had to do that.
The file BTXDOC.TEX resides in BibTeX's standard distribution area
<TEX.BIBTEX> on SCORE.STANFORD.EDU, and it should be distributed along
with the rest of the BibTeX software. If there's something missing on
your system you should complain to your system's LaTeX/BibTeX
installer or to whoever sends you your distribution tapes (and/or
FTP it from SCORE.STANFORD.EDU).
> Oren Patashnik, your long letters were useless, though your un-named
> language is lovely. If you had simply said
> 'Well, I understand your desire for switches, but it is much more powerful
> to define a whole language! Here is the document for the language.'
> it would have kept me (and probably lots of other people) out of a bunch
> of blind alleys.)
Gee, I just reread the message I sent you, and I think it was pretty
informative. In particular it said:
There are infinitely many possible bibliography styles, but a set of
switches can produce only finitely many styles, so this scheme isn't
general enough. You need a programming language for full flexibility,
which is why the .BST language exists.
So I had said, in essence, what you just asked for.
> I think that this language should be documented in the LaTeX book.
I doubt Leslie Lamport wants to include the documentation in his book;
it exists, however, in the files BTXBST.DOC and BTXHAK.TEX, which are
in BibTeX's standard distribution area.
I understand the frustration of trying to work without adequate
documentation. But in this case the documentation exists, and it's
just a matter of making sure that users *know* of its existence. I
suggest, if they haven't already done it, that BibTeX installers state
in their _Local Guide_ exactly where on their system the BibTeX
documentation resides.
--Oren Patashnik
------------------------------
Date: Mon, 26 Sep 88 15:43:05 BST
From: CET1%phoenix.cambridge.ac.uk@NSS.Cs.Ucl.AC.UK
Subject: Bug in good.top and good.bot?
In the following definitions from plain.mf (or p.273 of the MFbook)
vardef good.lft primary z = save z_; pair z_;
(z_+(pen_lft,0))t_=round((z+(pen_lft,0))t_); z_ enddef;
vardef good.rt primary z = save z_; pair z_;
(z_+(pen_rt,0))t_=round((z+(pen_rt,0))t_); z_ enddef;
vardef good.top primary z = save z_; pair z_;
(z_+(pen_top,0))t_=round((z+(pen_top,0))t_); z_ enddef;
vardef good.bot primary z = save z_; pair z_;
(z_+(pen_bot,0))t_=round((z+(pen_bot,0))t_); z_ enddef;
surely the last two are wrong? Should the quantities added to z_
not be (0,pen_top) and (0,pen_bot) respectively? Certainly use of
good.top and good.bot seems to give me anomalous results.
It seems that the CM definitions use only good.x and good.y.
Chris Thompson
JANET: cet1@uk.ac.cam.phx
ARPA: cet1%phx.cam.ac.uk@nss.cs.ucl.ac.uk
------------------------------
Date: Mon, 26 Sep 88 13:42:04 EDT
From: russ@baklava.mitre.org (Russell Leighton)
Subject: Unix TeX in C
Could someone please tell me where I can obtian
a C TeX version for our Unix systems?
Please email: russ@mitre.arpa
Thanks, Russ
ARPA: russ@mitre.arpa
Russell Leighton
M.S. Z406
MITRE Signal Processing Lab
7525 Colshire Dr.
McLean, Va. 22102
USA
------------------------------
Date: Mon, 26 Sep 88 14:09:29 EDT
From: Chris Torek <chris@mimsy.umd.edu>
Subject: Re: Problem installing TeX (V88 #80): compiler limits
Pierre is right about it being hard to diagnose this error at a
distance, but in this case I know something about the implementations
of both the compiler on the 3B2/400 and the Unix `yacc' utility. The
3B2 compiler is a variant of a descendent of PCC. PCC generates
switch/case statements by accumulating the case constants in a table
of---alas!---fixed size. The table is then sorted, and one of three
switch algorithms is used depending on the density and number of cases
(direct jump, heap comparison, or direct comparsion). The switch table
overflow means that this table has been filled, not that the parser has
run out of space; breaking up the cases (without doing anything about
the switch itself) will have no effect.
The problem with yacc, on the other hand, is that the *parser* runs out
of stack space. Yacc produces a conventional LALR(1) parser. It too
has a fixed array for its parse stack. Alas, it does not even check
for overflow, and simply misbehaves by overwriting whatever is in the
memory beyond the parse stack. (There may be some yaccs that check,
but I have not heard about them.) The solution for this is to shun
right recursion in yacc grammars.
The real fix, of course, is not to use fixed-size tables. But then,
even TeX itself has fixed-size arrays. There is an excuse for this in
Pascal: new and dispose are, for some reason, considered `unnecessary'
by many compiler writers, and if implemented at all, often poorly
so---I know of several Pascals in which `dispose' is a no-op.
So it goes. Even compilers without built-in limits are limited by the
environment in which they are run. And TeX certainly stresses these
limits!
Incidentally, GF and DVI utilities could make use of a scheme I use in
my own file reading software. Compilers often limit code more than
they do data. (`No one would ever write 165 cases! It would take too
long to type! ... What's a macro?') The trick is to use a table to
compress the 256 opcodes into a smaller number of classes. Instead of
case opcode in
four_cases(X): code for X;
sixty_three_cases(Y): code for Y;
...
end;
one writes
var class_table : array [0..255] of class_type;
...
case class_table[opcode] in
class_X: code for X;
class_Y: code for Y;
...
end;
Curiously, the result often runs faster.
Chris
------------------------------
Date: Mon, 26 Sep 88 16:26:20 CDT
From: William LeFebvre <phil@rice.edu>
Subject: Re: Postscript, figures, and typesetters
> The output [from the typesetter] was fine except that the only PS
> figure was rotated 90 degrees and translated into the wrong column of
> the two column output....Has anyone patched dvi2ps to work on both LWs
> and some PS typesetter?
[ duck....there's sarcasm ahead... ]
Silly me! I thought PostScript was supposed to be universal. I
thought it was supposed to produce the same results on all printers
that supported it. I guess I was mistaken.
[ Is it now my turn to duck? ]
William LeFebvre
Department of Computer Science
Rice University
<phil@Rice.edu>
------------------------------
Date: Mon, 26 Sep 88 16:22:33 PDT
From: mackay@june.cs.washington.edu (Pierre MacKay)
Subject: small caps (TeXhax Digest V88 #84)
The computer modern basic set has cmcsc10.mf and cmtcsc10.mf (typewriter CSC)
The file csc.mf shows how the game is played, so other sizes could be generated
without too much hacking. This version of caps and small caps e x t e n d s
the small caps, and we have found it necessary, in an environment where we
need to use a lot of csc, that we had to make up a wmcscc? set
(Washington Modern small caps condensed). This is effectively the same
as eight point caps beside ten-point caps. We feel it works better
on a page where there are many small caps entries (Middle East Studies
Association Bulletin -- Conferences and News of Members).
There is presumably a converter from gf files to whatever you are
using for your output device. It won't give you postscript, though.
what you get is rasterized, and is fed to postscript as a hardwired
bitmap.
If you have any use for wmscc?? you are most welcome. All in the family,
as we might say.
What are you using for Greek? Adobe's largely unaccented Greek or
Silvio Levy's fully accented set?
Email: mackay@june.cs.washington.edu Pierre A. MacKay
Smail: Northwest Computer Support Center TUG Site Coordinator for
Lewis Hall, Mail Stop DW10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-6259
------------------------------
Date: Sat, 24 Sep 88 16:11:49 EDT
From: "David F. Rogers" <dfr@USNA.MIL>
Subject: Page Make-up Chalenge
Below is a copy of a paper that will appear in the next TUGboat. It is
included here (with Barbara Beeton's permission) to insure wide distribution
(some people who get texhax do not belong to TUG) and so that all you
macro and output routine wizards can get a head start on the Challenge.
Really, what is needed is a good constructive discussion of possible
solutions to the problem outlined below.
A Page Make-up Challenge
The Problem
I have been involved with typesetting relatively complex mathematical and
engineering textbooks using TeX since late 1982. These are books that are
typically 5-600 pages long with an average of more than a figure per page.
Further, the text is liberally endowed with large complex display equations
and tables both normal and turned. TeX's page make-up abilities are woefully
lacking for this application. This lack is perhaps understandable since
Knuth's design goal was to develop a system capable of consistently and
beautifully typesetting the volumes of the Art of Computer Programming. Art
of Computer Programming volumes contain few figures, large display
equations or turned tables in the text.
Publishers impose rather stringent page make-up requirements for figure
placement in engineering, science and mathematical textbooks. Typical
requirements in priority order are:
1. Numbered figures must be inserted in numerical sequence.
2. Numbered figures must be inserted after the first reference
to the figure.
3. Numbered figures are to be placed flush left at the top or bottom of
the page with minimum 1 1/2 pc and maximum 2 1/2 pc above
and/or below to text.
4. Numbered figures should be visible from the first reference.
5. If page make-up places a numbered figure several pages after it's
first reference, then and {\it only} then, may it be placed {\it before}
it's first reference. However, it {\it must} be visible from
it's first reference.
Figure caption rules somewhat further complicate the problem.
Examples for a standard 29 pc page width are:
1. Numbered figures 19 to 29 pc wide have the figure caption positioned
flush left 1 pc below the figure by the page measure (\hsize)
2. Numbered figures less than 19 pc wide have the figure caption
positioned 1 pc to the right of the figure by the remainder
of the page width and based-aligned with the figure.
3. Sequentially numbered figures less than 13 pc wide are placed
side-by-side in 13 pc wide boxes separated by a 3 pc space.
Figure captions are placed flush left 1 pc below each box.
Considering that TeX 's output routines do not look ahead very well, it is
easy to see that such page make-up rules seriously complicate the task of
typesetting and making-up a book of this nature.
The Current Solution
In applications of this nature both Plain TeX's \topinsert and \midinsert
commands are known not to work. Further, LaTeX 's floating insert commands
also do not work. Consequently, it is necessay to essentially do the page
make-up by hand {\it using a computer}! The technique (TeXnique??) is
conceptually simple and very labor intensive. The manuscript is broken up
into 30-50 page segments within chapter boundaries (a chapter is assumed to
always begin on a recto page). The segment is TeX'd. For the pages
preceeding the first figure reference, white space is inserted or deleted to
both balance the length of facing pages and to keep the page length within
acceptable parameters. No, TeX does not always do it quite correctly, i.e.
according to the page make-up rules. Immediately after the first figure
reference, white space equal to the figure size is inserted along with the
figure caption. If there is sufficient space at the bottom of the page
containing the figure reference, called the current page, it is inserted
there, if not, it is moved to the top of the next page.
To reiterate, conceptually this technique is quite easy, in practice it is
quite difficult. Adding white space and the figure caption to the bottom of
the current page must be done by measuring up from the bottom of the page,
finding the exact end of line corresponding to the required figure space plus
the space occupied by the figure caption and inserting the white space and
figure caption at that point in the manuscript. To prevent TeX from
reformating the pages to this point a \vfill\eject is placed at the bottom
of the previous page. This, of course, does not always work. TeX
occasionally decides that the previous material is best presented with an
incomplete last line! When this happens material is moved -- word-by-word --
from the current page to ahead of the \vfill\eject on the previous page
until the result is correct. A similar technique is used when the figure is
placed at the top of a page. A combination of the techniques is used when
both a top and bottom figure appear on the same page. The {\it fun} really
begins when a page contains large display equations or large numbers of
display equations and both top and bottom figures. The result is a long,
possibly nonconverging, iteration process.
As Reference 1 illustrates, doing a book of this type with TeX is quite
possible. It is just a bit painful. Unfortunately, it is also not cost
effective. Currently, it is less expensive for a book publisher to simply
typeset the manuscript using TeX without including figure captions or spaces
and use the traditional Xacto knife and glue pot page make-up technique.
That offends me, as I am sure it does you.
The Challenge
My initial thought was to simply write a \bottominsert macro similar to the
\topinsert and \midinsert macros. However, discussions with output routine
guru's at the recent Montreal TUG meeting have convinced me that this will
not work, at least not very well.
The Challenge then is for the output macro guru's to write a figure placement
macro that incorporates items 1--3 above (4 and 5 can be handled manually).
The suggested calling sequence for the macro is
\figplace#1#2#3#4
where
#1 is the vertical dimension of the white space to be left for the figure.
#2 is the horizontal dimension of the white space to be left for the figure.
#3 is the figure number.
#4 is the figure caption.
The assumption is that a custom figure caption macro is used within the
figure placement macro. A sample figure caption macro might be:
% define a figure caption macro
% #1 is the figure number #2 is the caption
% the caption is to be set in a `box' left and right justified 1em to
% the right of the figure number
% the size to the box containing the word Figure, its number and the 1em
% skip is found in box0
% box1 is \hsize less the width of box0.
% a \vtop is used along with an \halign to obtain the flush left and right
% effect.
\def\figcap#1#2{{%
\setbox0=\hbox{{\bf Figure #1}\hskip 1em}%
\setbox1=\vtop{\advance \hsize by -\wd0 \noindent
\spaceskip=.3em plus .2em minus.2em
#2}
\halign{## & ## \cr
\box0 & \box1 \cr}}
\bigskip % put some space below the figure caption
}
Unfortunately, other commitments as well as my current level
of expertise prevents me from attempting this job.
References
1. Rogers, David F. Procedural Elements for Computer Graphics, McGraw-Hill
Book Co., New York, 1985.
COMMENTS to date:
Upon receiving the paper Barbara Beeton commented (\it summarized):
If you want to force a line to the full width at the end of a paragraph, you
can say \parfillskip=0pt\endgraf and it will happen. You have to reset
\parfillskip to the default, or bury the whole mess in a group, to get the
following paragraphs to end normally. Note -- the \endgraf freezes whatever
\parfillskip is in effect when the \endgraf happens; that means you can't
separate the \parfillskip from the \endgraf by a }.
How about
\newskip\normalparfillskip
\normalparfillskip=\parfillskip
\def\MidParPageBreak{
\unskip \parfillskip=0pt\endgraf
\eject \parfillskip=\normalparfillskip }
Then you'd only have to move one `whatever' in case you had to adjust.
With the \unskip, \MidParPageBreak could be put on a line by itself
with a string of %%% following it so it can be spotted easily.
dfr replied (expanded a bit here):
This will work provided that the line is only 1 or 2 words short. However,
if TeX is being obstreperous and ends the paragraph in the middle of the
last line, then using \parfillskip=0pt results in a poorly set paragraph.
For example, Knuth discusses doing this in the first paragraph on page 100
of the TeXbook. However, I mildly object to the setting of this paragraph.
Notice the extra space (about 3 pts) before the You at the end of the third
line from the bottom of the paragraph. Compare with the You in the next to
last line 3 paragraphs below.
Further, this only helps make using the Current Solution easier. It
doesn't solve the fundamental problem. Let's keep the comments about
this aspect of the problem to a minimum.
So all you output and macro guru's have at it.
Professor David F. Rogers
Aerospace Engineering Department
U.S. Naval Academy
Annapolis, MD 21402
USA
Tel: 301-267-3283/4/5
INTERNET: dfr@usna.mil
UUCP: ~uunet!usna!dfr
------------------------------
%%%
%%% 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
**************************
-------