Subject: TeXhax Digest V89 #107 From: TeXhax Digest Errors-To: TeXhax-request@cs.washington.edu Maint-Path: TeXhax-request@cs.washington.edu To: TeXhax-Distribution-List:; Reply-To: TeXhax@cs.washington.edu 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 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 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: ----------------------------------------------------------------------------- Date: Thu, 23 NOV 89 12:09:22 BST From: CHAA006%vaxa.rhbnc.ac.uk@NSFnet-Relay.AC.UK Reply-To: Philip Taylor (RHBNC) 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 ? 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 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 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 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 % 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 ************************** -------