TeXhax Digest Wednesday, March 16, 1988 Volume 88 : Issue 26
[SCORE.STANFORD.EDU]<TEX.TEXHAX>TEXHAX26.88
Editor: Malcolm Brown
Today's Topics:
PATGEN
Addison-Wesley and MicroTeX and TeXtures
New bibtex.web
TeXhax
Makeindex (TeXhax Digest V88 #22)
NEWFFC for the LN03
Varying the Numbering Style in Enumerate Environments.
overfull hboxes and "nroff"
A-problem-with-\immediate-and-\write-in-TeX (TeXhax Digest V88 #22)
LaTeX-3Jan_to_22Feb.diffs
making fonts for ln03
Additions to TEXFONT.MEMO
----------------------------------------------------------------------
Date: Fri, 11 Mar 88 10:59 N
From: <POPPELIE%HUTRUU51.BITNET@forsythe.stanford.edu> (Nico Poppelier)
Subject: PATGEN
Last week I obtained PATGEN.WEB from a VMS distribution tape (and
after minor changes implemented it on an Atari 1040ST. In case anyone
is interested: I produced working versions of TANGLE and WEAVE for the
Atari, with reasonably small change files). The .TEX file extracted
with WEAVE produces output starting at page 45 and apparently
PATGEN.TEX is the Appendix of a bigger document.
Question: Where can I get the other pages, pp. 1--45, and what is in it?
Nico Poppelier
(BITNET address: Poppelier@Hutruu51)
------------------------------
Date: 11 Mar 1988 09:59:18 EST
From: Irvin.Lustig%BASIE.Princeton.EDU@Princeton.EDU
Subject: Addison-Wesley and MicroTeX and TeXtures
Not only has Addison-Wesley stopped supporting MicroTeX for the PC's,
they are also discontinuing support of TeXtures for the Macintosh family.
However, Kellerman and Smith, the authors of TeXtures, have taken over
support of all users and future sales. So at least Addison-Wesley
hasn't left everybody in the dark.
By the way, the latest version of TeXtures (1.01) supports typesetting
in the backround under Multifinder. Hence, one can type one document or
work in another program while typesetting a document. The $25 upgrade price is
definitely worth it.
-Irv Lustig
Assistant Professor
Dept. of Civil Engineering and Operations Research
Princeton University
irv%basie@princeton.edu
------------------------------
Date: 11-MAR-1988 11:13:19 GMT
From: ABBOTTP%aston.ac.uk@NSS.Cs.Ucl.AC.UK
Subject: New bibtex.web
I am trying to ftp a copy of bibtex.web from score.stanford.edu for the UK
community but due to its size I have time out problems. Is there any chance
that the file could be split into smaller parts for ftp purposes.
I connect to score through several systems each with different time out
parameters and I have no batch ftp facilities only interactive.
As a result of the last TUGBOAT several people have asked to be added to
the UKTeX distribution list. I have acknowledged all the requests and asked
for acknowledgement that I have the correct address. Some have not replied
so if you have asked to be added and are not receiving the digests please
send again.
Peter Abbott
______________________
Computing Service JANET abbottp@uk.ac.aston
Aston University ARPA pabbott@nss.cs.ucl.ac.uk
Aston Triangle or abbottp%uk.ac.aston@nss.cs.ucl.ac.uk
Birmingham B4 7ET UUCP ...!ukc!aston!abbottp
U.K. BITNET abbottp%uk.ac.aston@ac.uk
Tel (+44) 21 359 5492
------------------------------
Date: Fri, 11 Mar 88 08:06:43 PST
From: mackay@june.cs.washington.edu (Pierre MacKay)
Subject: Makeindex (TeXhax Digest V88 #22)
Since Makeindex is part of UCBerkeley's VorTeX, and subject to license,
it has not been possible to put it out for general distribution.
(I have never actually seen it myself.) Recent correspondence
with Berkeley suggests that it may be possible to arrange for
Makeindex to be separated from the rest of VorTeX, and added to
public network software and packages like the Unix TeX distribution.
Pierre A. MacKay
TUG Site Coordinator for
Unix-flavored TeX
------------------------------
Date: Fri, 11 Mar 88 08:32 PST
From: SHECTMAN%SETI@icdc.llnl.gov
Subject: NEWFFC for the LN03
Here at Lawrence Livermore Labs, we locally distribute TeX with a bunch
of command files and additional programs that cause pixel files to be
created the first time they are encountered in a DVI file (yes, I remember
that I said I would post these changes to TeXhax, and I will when I get
time to fill out the paper work necessary). A system
manager bringing up TeX for the first time on a group of systems
that only had LN03's for output devices encountered the problem that
only the file owners could reference the pixel files created by NEWFFC.
They checked the sources, and found that NEWFFC creates files with
only OWNER access. Enclosed is the differences file that shows the
minor change to create the pixel files with the current default protection.
It could just as easily have been set to give the world access. It is not
clear why the originator of NEWFFC chose to be so restrictive.
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
From: VAXPM::ELLIS "Phone 2-5952" 11-MAR-1988 08:17
To: SETI::SHECTMAN
Subj: TEX
Bob, I found in newffc.c where the file protection was being set. Following
is the differences between the two source files.
************
File SYS$SYSDEVICE:[ELLIS]NEWFFC.C;1
1258 strf = creat(fs,0700);
1259 if (strf == -1) {
******
File SYS$SYSDEVICE:[ELLIS]NEWFFC.C;2
1258 /* strf = creat(fs,0700); */
1259 strf = creat(fs,0000); /* R.Palasek LLNL for Tom 3/9/88 */
1260 if (strf == -1) {
************
Number of difference sections found: 1
Number of difference records found: 2
DIFFERENCES /IGNORE=()/MERGED=1/OUTPUT=SYS$SYSDEVICE:[ELLIS]NEWFFCDIF.TXT;1-
SYS$SYSDEVICE:[ELLIS]NEWFFC.C;1-
SYS$SYSDEVICE:[ELLIS]NEWFFC.C;2
------------------------------
Subject: Varying the Numbering Style in Enumerate Environments.
Date: Fri, 11 Mar 88 12:47:48 PST
From: Robert Kasper <kasper@vaxa.isi.edu>
In TexHax V88 #22 HANCHE%NORUNIT.BITNET@CUNYVM.CUNY.EDU writes:
> Date: Fri, 26 Feb 88 21:10:17 ECT
> From: HANCHE%NORUNIT.BITNET@CUNYVM.CUNY.EDU
> Subject: Varying the Numbering Style in Enumerate Environments.
>
> Sub-Title: LaTeX Manual Baby Bug
>
> A student wanted roman numerals numbering the items in his enumerate
> environments. Neither he nor I could find out how to do that from the
> LaTeX Manual. It did not take much poking around, however, to discover
> that the solution is to issue the command
>
> \renewcommand{\labelitemi}{\roman{itemi}}
>
> (Replace the two occurences of itemi by itemii, itemiii, or itemiv
> whenever appropriate.)
>
> This seems to be such a useful thing that it should have been mentioned
> in the LaTeX manual. Leslie, please take note in case there will be a
> second edition. Others might want to scribble a note on the bottom of
> p.165 in their own copies...
We have also tried to change the numbering style for the items
of enumerate environments with no success. We tried redefining
\theenumi according to the instructions given in Section 5.3 (p. 92)
of the LaTex manual as follows:
--- BEGIN EXAMPLE ---
\renewcommand{\theenumi}{\roman{enumi}}
\begin{enumerate}
\item asserting or retracting a unary predicate on $I$;
\item changing the value of one of $I$'s roles;
\item changing the type of an individual adjacent to $I$.
\end{enumerate}
\renewcommand{\theenumi}{\arabic{enumi}}
--- END EXAMPLE ---
This did not have any effect; the items are still labeled
with arabic numerals.
Changing the \labelitem command by:
\renewcommand{\labelitemi}{\roman{itemi}}
did not have any effect either. (I would only expect it to
control the labeling of itemized lists, not enumerated lists).
Why are these commands not behaving as documented?
-- Bob Kasper
Arpanet: VAXA.ISI.EDU
------------------------------
Date: Fri, 11 Mar 88 16:54:55 EST
From: Bernie Cosell <cosell@WILMA.BBN.COM>
Subject: overfull hboxes and "nroff"
I've been shifting my habits and using TeX for more-and-more of
my typesetting chores (I still have to use troff a fair amount (man pages and
the like)). I like TeX quite a lot: I find it predictable and easy to use,
and I'm always impressed by the top-notch job it does. ON THE OTHER HAND...
(you _knew_ this was going to be a flame, right?? :-) TeX does have a couple
of quirks that I find maddening... even more so considering the care and
completeness that has been lavished on so much of it. Lemme roll out my two
biggest nuisances... if there are tricks and such for dealing with them I
would VEYR much like to know, since it would make my life a bunch more
pleasant:
1) overfull hboxes. I just got bonged, _again_, by making a minor
change to a document (I replaced "the file" with "{\tt
<therealfilename>}") and getting bagged by an overfull hbox. It
basically trashed the document (unless you like things sticking out
1/2" into the right margin). This leads me to three inquiries:
a) Is there some magical way to parse the cryptic (to say the least) info
in the log file to figure out HOW to fix the overfull box? Aside
from giving me the offending box (which was what was obvious), I'm
not sure how to fix it. I've been spraying negative penalties around
earlier in the paragraph to get it to loosen things up a bit (my
current opinion -- to be confirmed by looking at the doc if I can
ever get it to work..:-( is to set the previous three or four lines a
bit loose and so move the {\tt} to the next line, instead of having
all-good lines and then a HUGE whitespace on the one line). How can
I figure out how much negative penalty I'll need to "tune" that
paragraph up? Which leads me to my second problem:
b) How can I fix it so it _stays_ fixed? Assume I brute-force stick in
enough penalty-tuning to get TeX to respect the margins. Now I edit
the paragraph a little bit. Now all of those penalties are
inappropriate. How will I know? Should I hope that I'll get some
kind of _underfull_ box complaint and then go through numerous rounds
of tuning and tweaking again to get the paragraph to look OK? Is
there some automatic way to "patch" this in a way that won't haunt me
for the entire life of the document.
c) I _really_ thought you could run TeX in a mode where its action on
overfull boxes was to complain to the log, and THEN begin relaxing
its fussiness criteria so that it would do "as well as it could" to
get the paragraph set. I've pawed through my TeX book some now and I
can't find it -- did I imagine (or maybe "hope for") that mode, or
did I just miss seeing how to get it set up.
2) nroff. I'm having a VERY hard time coping with a laserprinter-only
typesetting world. Yes, I know, a monospaced document is trash and
doesn't deserve to live. But still... I find that I now essentially
_can't_ work on documents from home any more. There's no decent way to
preview things short of driving into work and picking up a draft off the
laserwriter (this is true even on my SUN here at work: we long ago
shifted to having LaTeX use the built-in fonts on the laserwriter.... of
course now there aren't any appropriate fonts on-line, and so dvi2sun
doesn't work). And back in my t/nroff days I actually used nroff to DO
monospace formatting - on-line documentation for programs, chunks of
stuff to be distributed by email. Is there some hackery I can use to get
TeX to set up monospace, ASCII compatible documents?
Thanks for your patience...
/Bernie\
ps, on a related note, are there any plans to "civilize" *running* TeX? One
comment that seems to be a VERY common one we get when we try to get TeX more
widely used around the company is that it is AWFUL to use - apparently the
simplest of typos touches off a barrelfull of incomprehensible error
messages. Even when you can figure out what what error it is telling you
about, it all feels much harsher and less-nicely-engineered than it could be.
Mostly i don't have a lot of trouble with this (aside from trying to figure
out how to finesse overfull hboxes... :-), but it sure is forboding for the
non-technically-inclined. /B\
__
/ ) Bernie Cosell
/--< _ __ __ o _ BBN Labs, Cambridge, MA 02238
/___/_(<_/ (_/) )_(_(<_ cosell@bbn.com
------------------------------
Date: Fri, 11 Mar 88 14:29:05 PST
From: mackay@june.cs.washington.edu (Pierre MacKay)
Subject: A-problem-with-\immediate-and-\write-in-TeX (TeXhax Digest V88 #22)
The problem is not with either \immediate or \write. If you consider
the page-breaker in "How TeX breaks lines up into pages" you will see
that the results you are getting are inevitable. You may be able
to fine tune them a bit, but a section header that comes before the
page breaker has been triggered is bound to think it is on the previous
page.
The safest approach, if your submission deadline is approaching, is
to be prepared to do a bit of hand editing on the contents file for
the final draft. You may have to anyway. You could also look at the
value in \pagedepth, adjusted as sugggested on TeXbook p. 123, and
modify your page-number accordingly. But I should think that
with a clearly defined feature such as a section head, you could
usually force TeX to consider the possibility of page-breaking before
it does the \write. I have one format that writes headers dependent on
the content of the page for continuous text. It gets things right
about 90% of the time, and I confess I have never felt it worth the
time to try for any greater consistency. On the last pass, I do some
hand editing. Unless you have an absolutely HUGE table of contents,
I would suggest that hand editing is the most expeditious way to meet
a deadline.
Pierre A. MacKay
TUG Site Coordinator for
Unix-flavored TeX
------------------------------
Date: Fri, 11 Mar 88 14:35:06 PST
From: mackay@june.cs.washington.edu (Pierre MacKay)
Subject: LaTeX-3Jan_to_22Feb.diffs
Here are the diffs for a set of new files which I got from Score just
before TeXhax went on vacation.
Pierre A. MacKay
TUG Site Coordinator for
Unix-flavored TeX
%%% Pierre's submission is too long (34K) for digest distribution. You
%%% can FTP it from SCORE.STANFORD.EDU by getting the file
%%% mkdiffs.txh
%%% As usual, a copy has been forwarded to TEX-L for BITNET distribution.
%%% Malcolm
------------------------------
Date: Fri, 11 Mar 88 18:27:59 EST
From: crl@maxwell.physics.purdue.edu (Charles R. LaBrec)
Subject: making fonts for ln03
As someone who has been playing with LN03's for quite a while, I
thought that I should speak up at last. My time for playing with it
is decreasing at a rather rapid rate, so I have not tested things out
extensively.
For those of you who are not familiar with it, the LN03 uses a
write-white engine. It does not register single-pixel width lines
very reliably (actually, close to not at all). Metafont does not deal
with such beasts very well. If you make blacker great enough to
eliminate single pixel-width lines, you greatly distort the
characters.
My first attempt was to use the write-white changes suggested in the
Metafont distribution. This involved adding some "max(x,2)" to
strategic places in cmbase.mf . However, I quickly learned that these
were not good enough. In particular, "o"s had gaps where a pixel
didn't register. If memory serves, the top looked something like:
#####
.#####.
## ##
where "." shows the pixel that burned off.
From this, I decided that the write-white fixes didn't go far enough,
and so performed some wholesale surgery on cmbase. I believe that
diffs are available from the Metafont directory in the file labrec.txh .
The problem was that I feel the "fixes" are a gigantic kluge that best
be left unseen. However, they did produce acceptable results, and
from this success I created a set of "cm" fonts for ditroff that we
are now using for our LN03's.
Besides being a kluge, the "fixes" create a cmmf that can only be used
with a write-white engine, thus eliminating the advantages of modes.
I have recently started toying with a new idea. I have added a new
mode-specific internal called blacker_min and redefined
define_whole_blacker_pixels and define_whole_vertical_blacker_pixels
to use this value instead of (effectively) 1. I felt that this would
have the desired effect, since most line widths are set using these
macros. Here is the addition to our local.mf:
newinternal blacker_min;
def define_whole_blacker_pixels(text t) =
forsuffixes $=t: $:=hround($.#*hppp+blacker);
if $<=blacker_min-1: $:=blacker_min; fi endfor enddef;
def define_whole_vertical_blacker_pixels(text t) =
forsuffixes $=t: $:=vround($.#*hppp+blacker);
if $<=blacker_min-1: $:=blacker_min _o_; fi endfor enddef;
% Here are conventions for local output devices:
% decln mode: for the DEC LN03 (Ricoh engine, a write-white device)
mode_def declniii = %
proofing:=0; % no, we're not making proofs
fontmaking:=1; % yes, we are making a font
tracingtitles:=0; % no, don't show titles in the log
pixels_per_inch:=300;
blacker:=0.2; % make pens a bit blacker
blacker_min:=2; % most everything should be at least 2 pixels wide
fillin:=-0.2; % darken diagonals a bit
o_correction:=0.5; % don't overshoot as much
enddef;
Initial results have been encouraging, but fall far short of being
"exhaustive" tests. Strokes seem to be sufficiently broad to avoid
gaps due to pixel burn-off. However, I have seen one distortion in
characters: the bar in the "e" is one pixel row too high. The
problem is that the vertical placement of the bar in romanl.mf uses
good.y bar_height (using pen tiny.nib), but doesn't draw it with
tiny.nib. The actual width is .6[thin_join,vair]. It turns out that
for cmr12, tiny.nib is 1 and thin_join and vair are 2. Thus good.y
puts the bar at a half-integral y coord, when it should be drawn on an
integral one. I would almost want to classify this as a bug in
romanl.mf, but I'm not sure. I'll let others more familiar with the
fonts to ponder it.
So, here is my two cents worth. Do with it what you will, and tell me
if the solution is a good one, bad one, or something in between.
Charles LaBrec
crl @ maxwell.physics.purdue.edu
------------------------------
Date: Fri, 11 Mar 88 22:03:59 EST
From: dow@wjh12.harvard.edu (Dominik Wujastyk)
Subject: Additions to TEXFONT.MEMO
TEXFONT.MEMO
[An index at the end of this document lists the fonts discussed.]
Introduction, History and Revision notes
This memorandum seeks to give a reasonably complete survey of the fonts
that are available for use with the TeX typesetting software. I would be
grateful for any relevant information that you may have that is not already
mentioned. While keeping the memo concise, I have given all the
information that I currently have. In other words, this is it: there is
probably nothing more to be learned by contacting me directly than is
already in the memo. I have also given everything I know about how to get
more information about each font, so follow those leads rather than
contacting me.
I first started compiling this Memorandum late in 1987, as a note to myself
and my immediate Indological colleagues. But it seemed little extra work
to include more information in it about other fonts I have heard of, and
doing this has greatly widened its usefulness to TeX users in general. As
this memo has grown beyond its original purpose, and more people are
requesting it, I think it is now worth adding the following notes giving a
date for the current revision. I shall post these revision notes to TeXhax
from time to time, and send the latest version of the memo to
score.stanford.edu. This way people will know whether there is enough new
stuff in it to be worth downloading it (again).
Revision Notes
March 10, 1988:
Added information on Listserve access to Goldberg's Arabic; Knuth's
Devanagari la; Billawala's Pandora; new person may work on Tamil;
Icelandic; Times Roman in Metafont; two people may work on Telugu;
IPA now available from Washington; Bitstream font family for TeX;
HP2TeX conversion of HP soft fonts to TeX fonts.
Since the tail has started to wag the dog, I have reformatted the memo
slightly, removing some of the bias towards Indic matters, to make it a
more general note about TeX fonts. Index added. General tidy up and
removal of infelicities.
%%% The update to Dominik's memo is now available for FTPing. You can
%%% `get' the file from the machine [SCORE.STANFORD.EDU] via anonymous
%%% FTP. The file is stored as
%%% <tex.texhax>wujastyk.txh
%%% A copy of the revision has been forwarded to TEX-L for BITNET. The
%%% memo is now roughly 50K in length.
%%% Malcolm
------------------------------
%%%
%%% subscriptions, address changes to: texhax-request@score.stanford.edu
%%% please send a valid arpanet address!!
%%%
%%% BITNET distribution: subscribe by sending the following
%%% line to LISTSERV@TAMVM1.BITNET:
%%% SUBSCRIBE TEX-L <your name>
%%%
%%% submissions to: texhax@score.stanford.edu
%%%
%%%\bye
%%%
------------------------------
End of TeXhax Digest
**************************
-------