TeXhax@cs.washington.edu (TeXhax Digest) (12/03/89)
TeXhax Digest Friday, Decemmber 1, 1989 Volume 89 : Issue 107
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:
Line numbers in draft documents
Looking for beta testers for new LaTeX verbatim
Re: CM fonts --- should they be extended ?
Need recommendations on spelling checkers
Further problems with the `where am I?' service at Uk.Ac.Aston.TeX
Do we need \everyline in v3.0?
Re: TeX 3.0: What now?
Why has LPLAIN.TEX changed to direct opposite of PLAIN.TEX?
---------------------------------------------------------------------
Date: Fri, 24 Nov 89 07:22:06 est
From: mary mccaskill <mkm@uxv.larc.nasa.gov>
Subject: Line numbers in draft documents
Keywords: TeX, line numbers
We have need of plain TeX macros to place line numbers to the left of
each line of a draft document. Would anyone be willing to share such
macros with us?
Thanks.
Mary McCaskill
mary@teb.larc.nasa.gov
--------------------------------------------------------------------------
Date: Thu, 23 Nov 89 18:24:16 CET
From: Rainer Schoepf <BK4%DHDURZ1@UWAVM.ACS.WASHINGTON.EDU>
Subject: Looking for beta testers for new LaTeX verbatim
Keywords: LaTeX, verbatim, beta testers
Dear fellow TeXers,
during the last few months I've been spending some time on a
re-implementation of the LaTeX verbatim environment. This
is now ready for beta testing. I'm now looking for a moderate
number (say 20--30) people that are willing to test the code,
to look at the documentation, and to tell me what's wrong with
it. I'm addressing *all* people, not only the TeX masters or
TeXnicians.
New features of this implementation are:
- No limit on the size of the verbatim text
- Limited capability to use verbatim inside of other environments
- \verbatimfile command to input a file verbatim
- comment environment that discards all TeX text in its body
- verbatimwrite environment that writes the text in its body to
a file without interpreting it.
If you're interested, send a short message saying so to the BITnet
address given. I can send the files in three possible ways:
1) Via BITnet/EARN File transfer
2) As ordinary mail messages (no protection against corruption)
3) All files put in one .ARC file that is sent UUencoded.
(probably as several files)
What I want from you:
You must promise not to give away the files. I'm rather sure
that most of the bugs have been found but I don't want this to be
given to the public until I'm sure. And I want you to report to me
what you think about it --- if you're happy with, a `It's fine!' will
do. If not, I want to know why.
It's up to you now...
Rainer
Rainer Schoepf
Institut fuer Theoretische Physik
der Universitaet Heidelberg These are the days
Philosophenweg 16 of miracle and wonder...
D-6900 Heidelberg
Federal Republic of Germany
Email: <BK4@DHDURZ1.BITNET>
-----------------------------------------------------------------------------
Date: Thu, 23 NOV 89 12:09:22 BST
From: CHAA006%vaxa.rhbnc.ac.uk@NSFnet-Relay.AC.UK
Reply-To: Philip Taylor (RHBNC) <P.Taylor%vaxa.rhbnc.ac.uk@NSFnet-Relay.AC.UK>
Subject: Re: CM fonts --- should they be extended ?
Keywords: fonts, CM fonts
Dominik Wujastyk's message re Tor Lillqvist's suggestion [... with TeX 3
coming soon, we should start thinking about extending the CM fonts to 256
characters...] gave me great pleasure (thank you, Dominik), but there are
a couple of points which I would like to take up:
>>> The change in TeX 3 does not concern fonts, but *character input*.
Not strictly, if I understand Knuth correctly. Yes, there are
eigh-bit extensions to TeX (and the entire WEB family), but TeX V3
goes much further: a new, extended font-metric file format will be
supported, which will allow the creation of `virtual fonts'. A
`virtual font' may contain characters from many physical fonts, but to
TeX they will appear to reside in a single font. [I have a feeling
that a virtual font may contain somewhere between 16384 and 65536
glyphs, but I may be mistaken here; I can find no evidence of this
claim]. That being the case, surely what is needed is a whole series
of new Computer Modern fonts, containing all useful combinations of
characters and diacritics; there will need to be at least one new font
for each `base' Computer Modern font (e.g. CMR, CMBX, CMSL, CMTI,
CMTT, CMSS, etc), and if the total number of letter/diacritic
combinations exceeds 256, then two or more new fonts will be needed
for each base font. The new extended font metric files will then
allow all the fonts from a single base to be merged into a single
virtual font.
Dominik then said
>>> But *don't* call it CM! CM is what it is. Basta!
>>> (Unless Don decides to extend it himself, of course.)
But is this true ? If I were to take (say) CMR10.MF and build (say)
CMR-WITH-ACCENTS10.MF, by painstakingly ensuring that each base character and
accent was identical with its counterpart in CMR10, then should the new font
{\it not} be called CM<something> ? It is intended to be totally compatible
with Computer Modern, and indeed, is intended to be a member of the Computer
Modern family, so what else should it be called ? New-Computer-Modern ?
Extended-Computer_Modern ? It surely needs the words `Computer Modern'
somewhere in its name, to identify its family membership.
Similarly, I have just built *CMBXCSC10 [(not) Computer Modern Bold Extended
Caps and Small Caps Ten Point], which is {\it directly} derived from the
definitions of CMBX10 and CMCSC10. If I {\it don't} include Computer Modern
somewhere in its name, how is its family membership to be determined ?
Philip Taylor
Royal Holloway and Bedford New College.
------------------------------------------------------------------------------
Date: Mon, 20 Nov 89 17:22:08 GMT
From: Irene Orr <irene%epistemi.edinburgh.ac.uk@NSFnet-Relay.AC.UK>
Subject: Need recommendations on spelling checkers
Keywords: Spelling checkers
I am looking for input on spelling checkers, preferably DAs, to
use on a Mac with TeXtures and/or OzTeX. Of the ones I have looked at,
the only one I have a postive recommendation for is Thunder.
Others are Liberty Spell II,Spellcheck, Spelling Coach (previously
know as MacLightning), Spellswell. Our preference is for software which
comes with a site license if possible, and which is MultiFinder and Hypercard
compatible, and which will run on a Mac Plus or better.
Please respond by e-mail, and thanks in advance,
Irene Orr
(irene@uk.ac.ed.cogsci, irene@uk.ac.ed.epistemi)
----------------------------------------------------------------------------
Date: Wed, 22 NOV 89 20:34:59 GMT
From: TEX%rmcs.cranfield.ac.uk@NSFnet-Relay.AC.UK
Subject: Further problems with the `where am I?' service at Uk.Ac.Aston.TeX
Keywords: 'where am I?', Uk.Ac.Aston.TeX
Service from Aston TeXserver, and the `where am I?' facility under the account
rmcs_tex@uk.ac.aston.tex has been somewhat sketchy over the past week, due to
perennial Colour Book Software problems. DEC have now supplied the new (v5.2)
edition, and it claims to be less likely to crash, so perhaps things will look
up again henceforth.
Since the new CBS went up on 22nd Nov, the server has replied to many `where
am I?' requests (presumably stuck in machines all over the world, waiting for
Aston to listen). Unfortunately, due to a residual bug in the way the CBS
installs its database of site names, many relay sites have been falsely
identified to the server under the names of other sites. The database is
being corrected, but please treat with suspicion any rather strange sitename
found to the right of the `@' in the response to the `where am I?' request.
Some of those known to have been specified in error are as follows:
Bad name Correct name
UK.CO.NETWORKING-CENTRE UK.AC.UKC
UK.CO.SUN-MICROSYSTEMS UK.AC.EAN-RELAY
UK.CO.TOPEXPRESS UK.AC.UKC
UK.AC.RUTHERFORD.MAIL UK.AC.EARN-RELAY
UK.AC.NSF.SUN UK.AC.NSFNET-RELAY
UK.AC.UCL.CS.VS2 UK.AC.UCL.CS
(Some of these are merely synonyms for the more usual name of the gateway
machine, or another machine at the same site, through which traffic could
probably be routed. However, those with the UK.CO. prefix are just ordinary
end-nodes, who happen to be reachable via UK.AC.UKC, but get given the
latter's mantle by virtue of being entered into the database in later lexical
order!)
Brian {Hamilton Kelly}
(p.p. Aston Archivists)
----------------------------------------------------------------------------
Date: Thu, 23 Nov 89 18:43:25 EST
From: Clement Pellerin <clement@opus.cs.mcgill.ca>
Subject: Do we need \everyline in v3.0?
Keywords: TeX, \everyline
At the 1988 TUG meeting in Montreal, a few of the participants
complained that it was difficult to build TeX macros to support change
bars. The proposed solutions only worked MOST of the time. The
idealistic solution needed something like \everyline to be a TeX primitive.
Has someone found a way to satisfactorily implement change bars?
If not, can we implement \everyline in v3.0? If someone succeeded,
can you see another reason why we would need \everyline in v3.0?
Flames welcome if \everyline was implemented between v2.93 and v2.992.
(I'm only suggesting an improvement, please don't send your macros.)
Clement Pellerin, McGill University, Montreal, Canada
clement@opus.cs.mcgill.ca
---------------------------------------------------------------------------
Date: Wed, 22 Nov 89 23:30:14 -0500
From: Ken Yap <ken@cs.rochester.edu>
Subject: Re: TeX 3.0: What now?
Keywords: TeX 3.0, PostScript
> I have one more suggestion: Many people are using (for better or
> worse) PostScript printers as their TeX output device. These printers
> have the advantage (or disadvantage) of containing several resident
> PostScript fonts. Unfortunally, several of the special characters and
> accents are in differnt location from those in the Computer Modern
> scheme. This makes life difficult for those who write device drivers,
> and for those who want to use the resident PostScript fonts.
This is no problem for us at all. We use a PS driver that maps those
characters that have TeX representations to their usual positions in
the CM map. It's Stephan Bechtolsheim's TPS driver by the way. Some
drivers do the mapping earlier in the game, by macro definitions. Take
your pick.
> If I remember correctly, the PostScript coding scheme is based on a
> standard something like ISO Latin 1. If the computer modern fonts are
> going to be extended in any way, I think is only makes sense that they
> be extended towards a standard. Using ISO Latin 1 has the added
> advantage of making life easier for the many people who use PostScript
> with TeX.
> There are several empty slots in the ISO standard that could be used
> for the CM characters that are not found in the ISO standard (like
> greek letters, etc.). Most of these special characters are accessed
> via control sequences defined in plain.tex, so putting them at
> different locations should not create too many problems. And, as was
> already mentioned, the common accented characters would be treated as
> a "real" character, and not as a letter with an accent.
No, the PS coding scheme is not ISO Latin or 8859 as some like to call
it. For one thing, positions 128 to 159 in 8859 are for additional
control characters.
I believe it is a mistake to confuse the input scheme with the output
map. 8859 is an information interchange standard. Presumably 8859 users
will (have) defined chardefs such that the o umlaut character has the
same effect as \"o. Whether this is printed as a single glyph or by
overstriking depends on the font. Extending the CM fonts is a separate
issue.
X-Uucp: ..!rochester!ken Internet: ken@cs.rochester.edu
X-Snail: CS Dept., U of Roch., NY 14627. Voice: Ken!
X-Phone: (716) 275-1448 (office) Fax: (716) 461-2018
-----------------------------------------------------------------------------
Date: Wed, 22 NOV 89 21:47:41 GMT
From: TEX%rmcs.cranfield.ac.uk@NSFnet-Relay.AC.UK
Subject: Why has LPLAIN.TEX changed to direct opposite of PLAIN.TEX?
Keywords: TeX, plain.tex, lplain.tex
Can any fellow hackers out there help to resolve a puzzle regarding the real
latest version of LPLAIN.TEX?
When I ported the new TeX v2.992 to VMS, and installed it on our system a
couple of weeks back, I decided to generate an updated LPLAIN.TEX from our
existing one, adding appropriate lines (cribbed from DEK's new PLAIN.TEX) that
specify such things as \lefthyphenmin, etc., introduced for TeX v3.
A couple of days later, when I was collecting the MF v1.8 sources from
Labrea.Stanford.edu, I decided to check whether there was an official updated
LPLAIN.TEX; the directory entry at Labrea looked like this:
%-rw-rw-r-- 1 0 5 46034 Feb 25 1989 lplain.tex
so it obviously wasn't yet updated for TeX v2.992. However, I collected it
anyway, because it's newer than ours. Naturally, I ran a diff program to see
what else had changed apart from the bits I'd added to our LPLAIN, and found,
as I had anticipated, that the heading had changed to reflect the update:
************
File DISK$VMSUSER6:[TEX]LPLAIN.TEX;1 --- our old one
2 % - Last modified 24 July 1987
3 %
******
File DISK$VMSUSER6:[PUBLIC.TEX_V3.LATEX]LPLAIN.TEX;1 --- from Labrea
2 % - Last modified 20 October 1988 to take into account
3 % changes to PLAIN.TEX reported by Arthur Ogawa
4 %
************
However, I was somewhat surprised to see that these differences existed:
************
File DISK$VMSUSER6:[TEX]LPLAIN.TEX;1 --- remember, this is the old one
961 \mathchardef\ldotp="613A % ldot as a punctuation mark
962 \mathchardef\cdotp="6201 % cdot as a punctuation mark
******
File DISK$VMSUSER6:[PUBLIC.TEX_V3.LATEX]LPLAIN.TEX;1
960 \mathchardef\ldotp="602E % ldot as a punctuation mark
961 \mathchardef\cdotp="6201 % cdot as a punctuation mark
************
************
File DISK$VMSUSER6:[TEX]LPLAIN.TEX;1 --- remember, this is the old one
1007 \def\arrowvert{\delimiter"33C000 } % arrow without arrowheads
1008 \def\Arrowvert{\delimiter"33D000 } % double arrow without arrowheads
1009 \def\bracevert{\delimiter"33E000 } % the vertical bar that extends braces
1010 \def\Vert{\delimiter"26B30D } \let\|=\Vert
******
File DISK$VMSUSER6:[PUBLIC.TEX_V3.LATEX]LPLAIN.TEX;1
1006 \def\arrowvert{\delimiter"33C } % arrow without arrowheads
1007 \def\Arrowvert{\delimiter"33D } % double arrow without arrowheads
1008 \def\bracevert{\delimiter"33E } % the vertical bar that extends braces
1009 \def\Vert{\delimiter"26B30D } \let\|=\Vert
************
I was surprised, because I'd only recently seen that Knuth had made exactly
the reverse changes in his new PLAIN.TEX:
************
File DISK$USER3:[TEX.INPUTS]PLAIN.TEX;1 --- that's our old one
296 % \tracingonline=0
******
File DISK$USER3:[TEX.SOURCES.TEXWARE.V3]PLAIN.TEX;1 --- and Knuth's new one
296 % \holdinginserts=0
297 % \tracingonline=0
************
************
File DISK$USER3:[TEX.INPUTS]PLAIN.TEX;1 --- remember, this is the old one
305 \uchyph=1
306 % \globaldefs=0
******
File DISK$USER3:[TEX.SOURCES.TEXWARE.V3]PLAIN.TEX;1
306 % \language=0
307 \uchyph=1
308 % \lefthyphenmin=2 \righthyphenmin=3 set below
309 % \globaldefs=0
************
************
File DISK$USER3:[TEX.INPUTS]PLAIN.TEX;1 --- remember, this is the old one
323
******
File DISK$USER3:[TEX.SOURCES.TEXWARE.V3]PLAIN.TEX;1
326 \errorcontextlines=5
327
************
************
File DISK$USER3:[TEX.INPUTS]PLAIN.TEX;1 --- remember, this is the old one
911 \mathchardef\ldotp="602E % ldot as a punctuation mark
912 \mathchardef\cdotp="6201 % cdot as a punctuation mark
******
File DISK$USER3:[TEX.SOURCES.TEXWARE.V3]PLAIN.TEX;1
915 \mathchardef\ldotp="613A % ldot as a punctuation mark
916 \mathchardef\cdotp="6201 % cdot as a punctuation mark
************
************
File DISK$USER3:[TEX.INPUTS]PLAIN.TEX;1 --- remember, this is the old one
951 \def\arrowvert{\delimiter"33C } % arrow without arrowheads
952 \def\Arrowvert{\delimiter"33D } % double arrow without arrowheads
953 \def\bracevert{\delimiter"33E } % the vertical bar that extends braces
954 \def\Vert{\delimiter"26B30D } \let\|=\Vert
******
File DISK$USER3:[TEX.SOURCES.TEXWARE.V3]PLAIN.TEX;1
955 \def\arrowvert{\delimiter"33C000 } % arrow without arrowheads
956 \def\Arrowvert{\delimiter"33D000 } % double arrow without arrowheads
957 \def\bracevert{\delimiter"33E000 } % the vertical bar that extends braces
958 \def\Vert{\delimiter"26B30D } \let\|=\Vert
************
************
File DISK$USER3:[TEX.INPUTS]PLAIN.TEX;1
1202 \input hyphen
******
File DISK$USER3:[TEX.SOURCES.TEXWARE.V3]PLAIN.TEX;1
1206 \lefthyphenmin=2 \righthyphenmin=3 % disallow x- or -xx breaks
1207 \input hyphen
************
************
File DISK$USER3:[TEX.INPUTS]PLAIN.TEX;1
1220 \def\fmtname{plain}\def\fmtversion{2.3} % identifies the current format
******
File DISK$USER3:[TEX.SOURCES.TEXWARE.V3]PLAIN.TEX;1
1225 \def\fmtname{plain}\def\fmtversion{3.0} % identifies the current format
************
Now what's going on? Why should Knuth move over to using, for example
\def\arrowvert{\delimiter"33C000 } % arrow without arrowheads
instead of
\def\arrowvert{\delimiter"33C } % arrow without arrowheads
only a few months after someone (presumably Ogawa) had replaced
\def\arrowvert{\delimiter"33C } % arrow without arrowheads
with
\def\arrowvert{\delimiter"33C000 } % arrow without arrowheads
(That's right, they're the exact reversal of each other.)
Did Ogawa make/recommend that lplain should fall into line with plain, or what?
Any advice would be greatly appreciated!!
Brian {Hamilton Kelly}
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ JANET: tex@uk.ac.cranfield.rmcs +
+ BITNET: tex%uk.ac.cranfield.rmcs@ac.uk +
+ INTERNET: tex%uk.ac.cranfield.rmcs@nsfnet-relay.ac.uk +
+ UUCP: ...!mcvax!rmcs.cranfield.ac.uk!tex +
+ OR ...!ukc!rmcs.cranfield.ac.uk!tex +
+ Smail: School of Electrical Engineering & Science, Royal Military +
+ College of Science, Shrivenham, SWINDON SN6 8LA, U.K. +
+ Phone: Swindon (0793) 785252 (UK), +44-793-785252 (International) +
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
P.S. Incidentally, Clarkson has an lplain.tex identical to that now at Labrea:
it's directory entry reads:
25 Feb 1989 46034 lplain.tex
The version of lplain.tex in the Aston archive is still the same as my old one.
---------------------------------------------------------------------------
%%% Further information about the TeXhax Digest, the TeX
%%% Users Group, and the latest software versions is available
%%% in every tenth issue of the TeXhax Digest.
%%%
%%% Concerning subscriptions, address changes, unsubscribing:
%%%
%%% BITNET: send a one-line mail message to LISTSERV@xxx
%%% SUBSCRIBE TEX-L <your name> % to subscribe
%%% or UNSUBSCRIBE TEX-L
%%%
%%% Internet: send a similar one line mail message to
%%% TeXhax-request@cs.washington.edu
%%% JANET users may choose to use
%%% texhax-request@uk.ac.nsf
%%% All submissions to: TeXhax@cs.washington.edu
%%%
%%% Back issues available for FTPing as:
%%% machine: directory: filename:
%%% JUNE.CS.WASHINGTON.EDU TeXhax/TeXhaxyy.nn
%%% yy = last two digits of current year
%%% nn = issue number
%%%
%%%\bye
%%%
End of TeXhax Digest
**************************
-------