texhax@cs.washington.edu (TeXhax Digest) (11/22/88)
TeXhax Digest Thursday, November 21, 1988 Volume 88 : Issue 101
Moderators: Tiina Modisett and Pierre MacKay
%%% The TeXhax digest is brought to you as a service of the TeX Users Group %%%
%%% in cooperation with the UnixTeX distribution service at the %%%
%%% University of Washington %%%
Today's Topics:
LaTeX singlespace environment
LaTeX and \raggedright
Advantages of LaTeX
"PostScript from Mac"
DVI driver for Apple Laser Writer (under MS-DOS) wanted
Driver for Epson LQ-500 printer
French quotes in TeX
PiCTeX manual needed
"turbo" PiCTeX
Chardx values in CM fonts
-----------------------------------------------------------------------------
%%% Moderators' note: We received several very helpful messages in
%% response to our first issue, especially about certain standards regarding
%% the burst lines and the use of the Keywords entry. We have followed
%% their recommendations in this issue. The burst line is provided with
%% a blank line above and below, and the keywords entry has been moved
%% into comformity with RFC 822. We appreciate the help, and your
%% patience with us as we learn.
------------------------------------------------------------------------------
Date: Mon, 7 Nov 88 16:58:18 CST
From: "George A Christensen" <GA.TEX%ISUMVS.BITNET@CUNYVM.CUNY.EDU>
Subject: TeXhax Digest v88#97 LaTeX notes
Keywords: LaTeX
The singlespace environment (from the doublespace style) evidently
left out \par at the beginning and end. Therefore it is necessary
to use singlespace inside another environment or leave a blank line
before invoking singlespace and another blank line after quitting
singlespace. Otherwise \LaTeX thinks it's still in the same
paragraph and single spaces everything from the last blank line
or \par before until the next blank line or \par after.
As an example, here is an environment which causes single-spaced
hanging indentation inside doublespace input and does not
offend paragraphs before and after. This is used for some
bibliography styles for theses.
\def\hangpar{\par \def\baselinestretch{1}\@normalsize
\raggedright \parindent=0pt \parskip=12pt
\everypar{\hangindent=24pt \hangafter=1}}
\def\endhangpar{\par}
George Christensen
-------------------------------------------------------------------------------
Date: Mon, 7 Nov 88 20:14:03 pst
From: rusty%garnet.Berkeley.EDU@violet.berkeley.edu
Phone-Number: (415) 643-9097
Reply-To: rusty@cartan.Berkeley.EDU
Subject: latex and \raggedright
Keywords: LaTeX
I would like to have an entire document set ragged-right.
First I tried putting \raggedright before the \begin{document}
command. That worked, except that (as explained on page 111 of the
Latex book) all of the paragraph indentation disappeared. No problem,
I figured, I'll just use \setlength{\parskip}{some_value}. That
worked ok, except that it added additional vertical space between each
entry in the table of contents, and there is additional vertical space
in various other places in the document (for example, after section
titles).
(1) Is there some other command or method that I should be using to
get my document set ragged-right?
(2) If the anser to (1) is "no" then it seems that I need to do some
.doc file hacking. Does anybody know what stuff I should modify?
What I'd really like is a raggedright \documentstyle option.
-------------------------------------------------------------------------------
Date: MON NOV 07, 1988 20.23.57
From: INHB%MCGILLC.BITNET@Forsythe.Stanford.EDU
Keywords: TeX, LaTeX
From: Michael Barr
inhb@mcgillc.bitnet
New address: inhb@musicc.mcgill.ca
I have been following the discussion of TeX journal publication with
great interest. I have some comments and some questions. First off,
there seems to be a strong current of ``Real men don't use LaTeX'' that
I find hard to understand. There are certainly things that can be done
in LaTeX that cannot be done in plain or AmSTeX. (If anyone is
interested in a set of macros for making commutative diagrams and isn't
afraid to be seen using LaTeX, just drop me a note and I will be glad to
send them on.) Of course ``cannot'' is too strong. Anyone who wants ot
import the LaTeX fonts and reinvent Leslie Lamport's wheel can certainly
do these things. One Berkeley mathematician told me that ``everyone''
there has a Macintosh and Apple Laser writer and does diagrams as
specials. Yes, they can be done that way, but can the results be called
TeX? Can they be sent over the network?
However, for most people that isn't the reason they use TeX. They use
LaTeX for the same reason other people have discovered that TeX is
better than your favorite wysiwyg editor; you can achieve a consistency
of output that cannot be gotten any other way. Now LaTeX is criticized
as being too inflexible. It isn't, a point I will return to later, but
let's suppose it were. Is that a disadvantage? Everyone appears to
accept that a journal can properly strive to achieve a consistent
appearance. Well, consistency and flexibility are sort of opposites,
aren't they? I mean if you use a list in LaTeX, you get numerical
labels in order, the same separation between items, etc and this in
every list. If the journal has a style file, all those parameters will
be set there. This can be done in plain TeX only by insisting that
every author adhere to a set of rigid specs that sets \vskip\itemsep
between all items and lets the journal specify the value. At this
point, it becomes similar in this respect to LaTeX, except it is more
work.
This example could be multiplied by as many procedures as there are
procedures in LaTeX. One author might put his title at \magstep2,
another at \magstep3. The journal might insist on a uniform size in its
style sheet. In LaTeX, the journal would merely have to insist on the
use of \title. And so on. At this point, the main difference is that
LaTeX is easier to use. Plus, of course, the things that only LaTeX can
do.
If you only read the LaTeX book, LaTeX is inflexible. If you read the
latex.tex and the various style files, you discover it is wonderfully
flexible. The \@startsection macro, for example, takes 8 parameters and
can be made to do almost anything you would want and many things you
wouldn't. I had to make a style for a rather persnickety publisher who
had rather exacting requirements and the only modification I had to make
to latex.tex was change an \emskip to an \enskip in the procedure
\@sect. I wanted to number figures in the same sequence as equations
and found that this could readily be done by changing ``figure'' to
``equation'' in five (consecutive) lines in the style file. The most
important of these is:
\def\figure{\@float{equation}}
which shows that you could define as many such procedures as you wanted,
each numbered in its own or some other sequence.
But this is all undocumented. There are innumerable comments in
latex.tex and these are helpful, but LaTeX cannot really demonstrate its
flexibility without a roadmap through this file. Has anyone prepared
such a map and if so how can I get it.
I have one little question unrelated to the above. Has anyone beside me
noticed that there appears to be an error in the tfm for the minus sign?
If you try to define \dotmin in the same way as \doteq, the dot comes
out way too high. The height of the minus is 7pt and of the equals is
4.4pt, despite the fact that the latter is actually quite a bit higher.
This is true in both the CM and AM fonts (from PC-Tex at least) and from
at least one mainframe version that I received.
-------------------------------------------------------------------------------
Date: 7 Nov 88 11:50:00 CDT
From: "CCSVAX::DSCARGO" <dscargo%ccsvax.decnet@cim-vax.honeywell.com>
Subject: RE: TeXhax Digest V88 #98
Keywords: PostScript, MacDraw
We have recently acquired ArborText's DVILASER/PS device driver. The
process of printing MacDraw documents by converting them to PostScript
is tedious. Looking at TUGboat back issues I came across Alec Dunn's
article in Vol. 8, No. 2, July, 1987. He mentions a program called
"PostScript from Mac" that simplifies the process of producing "well-
behaved" PostScript files from MacDraw documents. Is that program available
for FTP from anywhere?
David S. Cargo (DSCARGO@CIM-VAX.HONEYWELL.COM)
-------------------------------------------------------------------------------
Date: 8 Nov 88 18:38:40 EDT
From: "Kostas Karanasios - Postmaster" <POSTMAST%GRPATVX1.BITNET@Forsythe.Stanford.EDU>
Subject: DVI driver for Apple LaserWriter (under MS-DOS) wanted.
Keywords: dviware, PostScript
Hi all,
we are planning to use an IBM AT personal computer along with
an Apple LaserWriter II NTX in order to print .DVI files from
PC TeX. So, we have to find a DVI driver for the ALW.
Is there anybody who can send us such a driver for MS-DOS ?
We have been told that there is one in the University of Utah
which uses GF, PK or PXL files and C source code is available.
Is it public domain ? Where can I find it ?
%%%% Moderators' note: Get in touch with Beebe@Science.Utah.Edu
%%%% to find out whether his free software driver can be
%%%% adapted to DOS. Otherwise, consult the PCTeX people.
%%%% or see the message above which mentions the ArborText driver.
We are running JNET 3.1 and I would appreciate any kind of help.
Thank you in advance.
Kostas Karanasios.
Systems Programmer,
Computer Center of Computer Technology Institute.
POSTMAST@GRPATVX1.BITNET
-------------------------------------------------------------------------------
Date: 08 NOV 88 08:45:19
From: Z3000JD%AWITUW01.BITNET@Forsythe.Stanford.EDU
Subject: Re: Driver for Epson LQ-500 Printer
Keywords: dviware
I have developed a DVI-Driver for the Epson LQ500 printer with
support of all 24 pins.
It is based on the Beebe Drivers. I have modified some of *.h files
of the Beebe Driver and written a new main-program for the Epson LQ500.
Unfortunatly there are still some errors in my program.
Johannes Demel,
Technical University Vienna
Z3000JD@AWITUW01.BITNET
-------------------------------------------------------------------------------
Date: Wed, 9 Nov 88 12:20:55 EST
From: Scott Bodarky <bodarky@umbc3.UMD.EDU>
Keywords: TeX, macros
Hi, I've already submitted this twice, and it hasn't appeared in TeXhax.
Is this because it is not getting through, or are you folks not printing
it for some reason? If the latter is the case, please respond, so I
know that there is no e-mail problem.
I have here what I think is a real mind bender for TeX (at least to me),
so I thought I would toss it out into TeXland to see if anyone had done
anything like it before, or even had a suggestion or two.
We are typesetting articles from musicology journals of the 19th century
in French. Given a paragraph of text in which a quotation occurs, the
standard practice of the time was to have a left quote running down the
left side of the text on each line of the quote, like so:
...A paragraph of text in which <<French quotes
<< occur should have left French quotes running
<< down the left side of the page on each line
<< that is included in the quotation.>> When the
quotation ends, the running quotes end...
I have written a translator program in SNOBOL4 to take the articles,
as input by musicologists using text editors, and AUTOMATICALLY
generate TeX code for these articles. So what I need is a macro like
this:
...A paragraph of text in which \frenchq{French quotes
occur should have left French quotes running
down the left side of the page on each line
that is included in the quotation.} When the
quotation ends, the running quotes end...
that will make the paragraph look like it does up above, with running quotes.
It strikes me that I need to access the lines of text after TeX's line-
breaking algorithm has had them, but I know of no provision for this.
So, does anybody have suggestions, or at the very least, does anybody
think it can be done at all?
Thanx,
Scott Bodarky
bodarky@umbc3.UMD.EDU
Organization: University of Maryland, Baltimore County
------------------------------------------------------------------------------
Date: Mon, 7 Nov 88 13:47 EST
From: P150BK19@VB.CC.CMU.EDU
Subject: PiCTeX manual
Keywords: PiCTeX
This is probably a stupid question, but I haven't found the answer in any
TeXHaX digests that I've looked over. I've managed to ftp the PiCTeX .TEX
files from svax.cs.cornell.edu or june.cs.washington.edu (though not
a.cs.uiuc.edu, as advertized in a recent digest). The README accompanying
the .tar.Z file at washington simply said that the manual exists, and the
.tar file at cornell contained cornerrules.dvi, which consisted of three
pages from the preface, one page from the introduction, and the table of
contents, which indicates that the manual is about 60 pages. Is the
complete manual publicly accessible? I'm assuming the author doesn't want
a deluge of requests unless he wants money for it...
%%%% Moderator's note. The author did, in fact, specifically request
%%%% that all requests for the manual be directed to:
%% Michael Wichura
%% Department of Statistics
%% University of Chicago.
%% (312) 702-8329
%% Wichura@Galton.Uchicago.EDU
Brad Keister
Physics Department
Carnegie Mellon U
P150BK19@CMCCVB (BITNET)
p150bk19@vb.cc.cmu.edu (internet)
-------------------------------------------------------------------------------
Date: Wed, 9 Nov 88 11:51:03 CST
From: grunwald@m.cs.uiuc.edu (Dirk Grunwald)
Subject: "turbo" PiCTeX
Office: 72 DCL (217) 333-1925
Reply-To: grunwald@m.cs.uiuc.edu
Reply-To: grunwald%guitar.cs.uiuc.edu@a.cs.uiuc.edu
Keywords: PiCTeX, macros
%%%Moderator's note: To avoid confusion, we have omitted the possibly incorrect
%%%versions of texpictex.tex referred to by Dirk Grunwald.
Attached is yet another copy of texpictex.tex. I noticed that when I specified
the conversion factor as ``0.001in'', I would get alignment problems, because
the 0.001in gets converted to something a smidge under the 0.07227 points
that are needed.
As weird as this sounds, this causes real problems when you draw figures
about 5 by 5 inches on edge.
So, at the expense of another dimen, the following version draws computes
\!tpu, so that it's much more exact, and then uses this to convert units.
%
% texpictex.tex -- The following macros over-ride certain definitions in the
% PiCTeX macro package. The net effect is that line-drawing is done using
% the \special's used by texpic (tpic). Several DVI printers understand
% and handle these specials.
%
% Currently, only straight lines are translated. If people extend this to
% included elliptic circles and quadratics, please forward the extensions
% to me (quads are used in the \arrow macro, making them very slow).
%
% Dirk Grunwald
% Univ. of Illinois
% grunwald@m.cs.uiuc.edu
%
\def\makebangletter{\catcode`\!=11\relax}
\def\makebangother{\catcode`\!=12\relax}
%
\makebangletter
%
% The units that texpic deals in. You should define it this way instead
% of simply saying ``0.001in'' because the difference in resolution
% actually makes a big difference
%
\newdimen\!tpu
\!tpu=1in
\divide\!tpu by 1000
%%%
%% \!maptpus -- map a PiCTeX dimension to a TeXPiC dimension
%% using the \!tpu conversion factor.
%%
%% uses: dimen0
%%
\def\!maptpus#1#2 {\dimen0=#1\divide \dimen0 by \!tpu #2=\dimen0}
%
% ** \setplotsymbol ({PLOTSYMBOL} [ ] < , >)
% ** Save PLOTSYMBOL away in an hbox for use with curve plotting routines
% ** See Subsection 5.2 of the manual.
\def\setplotsymbol(#1#2){%
\!setputobject{#1}{#2}
\setbox\!plotsymbol=\box\!putobject%
\!plotsymbolxshift=\!xshift
\!plotsymbolyshift=\!yshift
%
% Additions: compute size of dot, convert to TPUs and issue a pensize
%
\!dimenB=\wd\!plotsymbol
\!dimenC=\ht\!plotsymbol
\advance\!dimenC by \dp\!plotsymbol
\ifdim\!dimenB<\!dimenC \!dimenF=\!dimenC \else \!dimenF=\!dimenB\fi
\!maptpus{\!dimenF}{\!countC}
\special{pn \the\!countC}
\ignorespaces}
\setplotsymbol({\fiverm .})% ** initialize plotsymbol
% ** The following routine is used to draw a "solid" line between (xS,yS)
% ** and (xE,yE). Points are spaced nearly every \plotsymbolspacing length
% ** along the line.
%
% Texpic has increasing origin in the upper left corner, while
% pictex has origin in bottom left corner. Ergo, we flip the signs
% for y-coordinates.
%
\def\!linearsolid{%
%
% from-X
%
\!maptpus{\!xS}{\!countC}
\!maptpus{\!yS}{\!countD}
\!countD=-\!countD%
\special{pa \the\!countC \space \the\!countD}%
%
% to-X
%
\!dimenE=\!xS \advance \!dimenE by \!xdiff%
\!dimenF=\!yS \advance \!dimenF by \!ydiff%
\!maptpus{\!dimenE}{\!countC}
\!maptpus{\!dimenF}{\!countD}
\!countD=-\!countD%
\special{pa \the\!countC \space \the\!countD}\special{fp}%
\ignorespaces}
%
\makebangother
-------------------------------------------------------------------------------
Date: Wed, 09 Nov 88 17:53:14 GMT
From: CET1%phoenix.cambridge.ac.uk@NSS.Cs.Ucl.AC.UK
Subject: Extraordinary chardx values in CM fonts
Keywords: fonts, tfmwidths, dviware
GF and PK files, unlike PXL files, have a "pixel width" (METAFONT's
chardx value) for each character. A (good) DVI-interpreting program
is meant to respect these values for the placing of successive
characters, unless the accumulated error becomes too large, in
accordance with the "DVItype rules". The pixel width value is not
necessarily the scaled TFM width rounded to the nearest integer; for
example METAFONT's "change_width" command will change it to the next
nearest integer. This means the deviation can be as large as 1 pixel:
however, there is a sort of implication in DVItype that deviations
larger than this are not to be expected:
> A warning message may also be desirable in the case that at least one
> character is found whose pixel width differs from |conv*width| by more
> than a full pixel.
I am in the process of converting a DVI driver to accept GF and PK
files as well as PXL files. (I know, that shows how backward we are
here!) This driver obeys DVItype rules, or attempts to. Comparing the
output generated, I noticed some anomalies to do with the letter `m'.
It turns out that the `m' in cmr10 (at 300dpi, unmagnified) has a "pixel
width" of 36 pixels, which is 1.41 pixels larger than the scaled TFM
width. This causes odd things to happen, especially in words with more
than one `m': the "maxdrift" part of the DVItype algorithm starts
operating rather early.
I have obtained a list of all characters in the Computer Modern fonts
in the modes (lowres and a mode equivalent to imagen from waits.mf) and
magnifications (the usual ones) that we generate, that have a deviation
of the pixel width from the scaled TFM width of more than 1 pixel. They
fall into two classes:
1. The character `m' in many of the roman fonts (including slanted, bold
and sans serif, but not italic or monospaced). Most of the deviations
are less than 1.5 pixels, but there is a scattering of higher values
(from the bolder fonts and the higher magnifications) with an extreme
value of 3.49 pixels for cmb10.360gf! The deviations are all positive
(pixel width larger than TFM width) except for a couple of cases of
cmff10 (a font ``funny'' in more than one respect, obviously).
2. A large set of characters in the math symbol fonts, at many sizes.
'004 Elementary division operator (symbol.mf)
'005 Diamond operator (sym.mf)
'064 Large triangle (symbol.mf)
'065 Large inverted triangle (symbol.mf)
'070 Universal quantifier (sym.mf)
'076 Lattice top (symbol.mf)
'077 Perpendicular sign or lattice bottom (symbol.mf)
'171 Dagger mark (symbol.mf)
'172 Double dagger mark (symbol.mf)
'174 Club suit (symbol.mf)
'175 Diamond suit (symbol.mf)
'176 Heart suit (symbol.mf)
'177 Spade suit (symbol.mf)
The two characters from sym.mf also appear in the cmtex fonts, as
characters '033 and '024. The pattern is similar; most deviations
are below 1.5 pixels, but others (from the higher magnifications of
cmsy5, for some reason) go as high as 3.32 pixels. This time, the
smaller deviations are a mixture of positive and negative, but all
the deviations that are more than 1.5 pixels are negative.
I suspect that these anomalous pixel widths are indicative of bugs
in the generating METAFONT programs. (I am prepared to be informed
otherwise, of course!) In particular, it is notable that the programs
for all these characters (in romanl.mf, sym.mf & symbol.mf) do special
fiddling with the the "l" and "r" values, *without* using (the cmbase.mf
version of) the "change_width" command. This generally takes the form of
"r:=2*<good.x value with respect to something>(w)", or the equivalent.
The `m' program adds a "-l", for reasons that are obscure to me. These
certainly don't seem right, in view of the fact that the chardx value
ends up as "r+shrink_fit-l", and shrink_fit is 0, 1 or 2 (never
negative). However, I thought I should post this before diving much
further into the analysis!
Chris Thompson
JANET: cet1@uk.ac.cam.phx
ARPA: cet1%phx.cam.ac.uk@nss.cs.ucl.ac.uk
-------------------------------------------------------------------------------
%%% The TeXhax digest is brought to you as a service of the TeX Users Group
%%% in cooperation with the UnixTeX distribution service at the
%%% University of Washington
%%%
%%% Concerning subscriptions, address changes, unsubscribing:
%%% BITNET: send a one-line mail message to LISTSERV@UWAVM.ACS.WASHINGTON.EDU
%%% SUBSCRIBE TEXHAX <your name> % to subscribe
%%%
%%% All others: send mail to
%%% TeXhax-request@cs.washington.edu
%%% please send a valid internet address!!
%%% in the form name@domain or name%routing@domain
%%%
%%%
%%% All submissions to: texhax@cs.washington.edu
%%%
%%% Back issues available for FTPing as:
%%% machine: directory: filename:
%%% JUNE.CS.WASHINGTON.EDU pub/TeXhax/TeXhaxyy.nn
%%% yy = last two digits of current year
%%% nn = issue number
%%%\bye
%%%
------------------------------
End of TeXhax Digest
**************************
-------