11-Jan-1994 14:21:21-GMT,1475;000000000001 Return-Path: Received: from vs3002.ams.org by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA07116; Tue, 11 Jan 94 07:21:15 MST Received: from taptet.sscl.uwo.ca by MATH.AMS.ORG (PMDF #2306 ) id <01H7JULHBOG0PBI0KR@MATH.AMS.ORG>; Tue, 11 Jan 1994 09:12:27 EST Date: 11 Jan 1994 09:15:47 -0500 (EST) From: Chet Creider Subject: explanation of "Improper setbox" error message in 3.141 To: tex-implementors@MATH.AMS.ORG Message-Id: <9401111415.AA16786@taptet.sscl.uwo.ca> Content-Transfer-Encoding: 7BIT I would be very grateful for an explanation of why tex was changed between 3.14 and 3.141 such that common (at least to linguists, but I would think also for mathematicians) diacritic combinations such as \'{\c{o}} are disallowed (eliciting an Improper \setbox error and the followiing explanation (from tex.web): " Sorry, \setbox is not allowed ... between \accent and an accented character." This is extremely inconvenient and although fixes with sed scripts are possible (for some reason the reversed order \c{\'{o}} is all right), the only real solution is to back up to 3.14. Not very good to do in the long run. I would be very grateful if a design reconsideration could be made, but I suppose that is not likely for such a little thing (for me, however, it is not little as I'm editing a manuscript with something like 10,000 of these constructions). With thanks, Chet Creider 12-Jan-1994 2:05:25-GMT,4322;000000000001 Return-Path: Received: from vs3002.ams.org by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA21584; Tue, 11 Jan 94 19:03:18 MST Received: from ppsw1.cam.ac.uk (gray.csi.cam.ac.uk) by MATH.AMS.ORG (PMDF #2306 ) id <01H7KHGY50Y8PBHYQZ@MATH.AMS.ORG>; Tue, 11 Jan 1994 20:07:42 EST Received: from phx.cam.ac.uk by ppsw1.cam.ac.uk with GB-CAM (PP-6.0) as ppsw.cam.ac.uk id <18057-0@ppsw1.cam.ac.uk>; Wed, 12 Jan 1994 01:07:16 +0000 Date: 12 Jan 1994 01:07:10 +0000 (GMT) From: Chris Thompson Subject: Re: [explanation of "Improper setbox" error message in 3.141] In-Reply-To: <9401111415.AA16786@taptet.sscl.uwo.ca> To: tex-implementors@MATH.AMS.ORG Cc: Chet Creider , Robert Hunt Message-Id: Content-Transfer-Encoding: 7BIT Chet Creider asks for an explanation of change 399 (tex82.bug numbering), applied in TeX 3.141, that introduced the error: Sorry, \setbox is not allowed after \halign in a display, or between \accent and an accented character. This was a fix for a bug discovered by Robert Hunt. (I cannot find its history in Barbara's numbered message sequence, by the way.) The problem is that \setbox, alone of the commands processed by |prefixed_command|, can leave the semantic nest at a different level when it returns. This is because the parsing occurs only up to the "{" in "\setbox0=\hbox{...}", a new horizontal (or vertical, for \vbox) mode level has been created, and notes left on the save stack to say what to do at "}" time: namely store the result in a specific box register, possibly \global'ly. In the two situations described in the message, TeX allows any number of "assignments" (via routine |do_assignments|, which calls |prefixed_command| as long as the next command is of the right sort). This allows things like changing TeX parameters that are acted on at closing-$$ time, in the first case, or changing font between an accent and the character it is applied to, in the second. But in both cases TeX expects the semantic nest (and current list) to be untouched by this process. If the commands included \setbox's, this wasn't true, and one could get various "This can't happen" errors. My recollection is that Robert discovered the math mode \halign situation first, and that we then found the \accent problem by inspection of the code. In TeX 3.14 or earlier, \'{\setbox0=\vbox{o}} (which is not so different from Chet's example) will generate ! This can't happen (vpack). \setbox 0=\vbox {o} \'#1->{\accent 19 #1 } <*> \'{\setbox0=\vbox{o}} I'm broken. Please show this to someone who can fix can fix Now Chet quite reasonably thinks that as \'{\c{o}} was apparently working in TeX 3.14, he shouldn't have to rewrite all the occurrences as \c{\'{o}} (which works because it is \' that uses \accent, and \c that uses \setbox). But it turns out that TeX manged to avoid disaster in this case only accidentally: effectively it was turning it into \c{\'{o}} internally (as an inspection of \showlists output will reveal). Here is what happened: \' is expanded to yield {\accent 19 \c{o}}. \accent reads the 19, remembers the accenting character, and then calls |do_assignments|. \c is expanded to yield \setbox0\hbox{o}...... |prefixed_command| parses up to the "\hbox{": it has created a new horizontal mode level and notes on the save stack. "o" isn't an assignment, so |do_assignments| returns to \accent processing, which is unaware of the change to the semantic nest. \accent sees the "o" and applies the accent to it, and adds the resulting construct to the current list: it thinks it is the original one, but actually it is the new one (luckily they are both horizontal lists!) The "}" terminates the new horizontal mode level, boxes the \'{o} that is in there, and puts it in \box0. The rest of the expansion of \c now creates the effect of \c{\'{o}}. I think that it would be really quite hard for TeX to identify the cases in which it can `get away' with a \setbox in this way! Chris Thompson Cambridge University Computing Service Internet: cet1@phx.cam.ac.uk JANET: cet1@uk.ac.cam.phx 12-Jan-1994 17:54:56-GMT,2093;000000000001 Return-Path: <@AWIUNI11.EDVZ.UNIVIE.AC.AT:A8131DAL@AWIUNI11.EDVZ.UNIVIE.AC.AT> Received: from vs3002.ams.org by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA04877; Wed, 12 Jan 94 10:52:43 MST Received: from AWIUNI11.EDVZ.UniVie.AC.AT (helios.edvz.univie.ac.at) by MATH.AMS.ORG (PMDF #2306 ) id <01H7LB48HI40PBI664@MATH.AMS.ORG>; Wed, 12 Jan 1994 10:16:30 EST Received: from AWIUNI11.EDVZ.UNIVIE.AC.AT by AWIUNI11.EDVZ.UniVie.AC.AT (IBM VM SMTP V2R2) with BSMTP id 3180; Wed, 12 Jan 94 16:15:53 MEZ Received: from AWIUNI11.EDVZ.UNIVIE.AC.AT (NJE origin A8131DAL@AWIUNI11) by AWIUNI11.EDVZ.UNIVIE.AC.AT (LMail V1.1d/1.7f) with BSMTP id 8997; Wed, 12 Jan 1994 16:15:50 +0100 Date: Wed, 12 Jan 94 16:10:19 MEZ From: Peter Schmitt Subject: Re: [explanation of "Improper setbox" error message in 3.141] In-Reply-To: Message of 12 Jan 1994 01:07:10 +0000 (GMT) from To: tex-implementors@MATH.AMS.ORG Cc: Chet Creider Message-Id: <01H7LB49B8PEPBI664@MATH.AMS.ORG> Content-Transfer-Encoding: 7BIT >Chet Creider asks for an explanation of change 399 (tex82.bug > >Now Chet quite reasonably thinks that as \'{\c{o}} was apparently >working in TeX 3.14, he shouldn't have to rewrite all the occurrences >as \c{\'{o}} (which works because it is \' that uses \accent, and \c >that uses \setbox). But it turns out that TeX manged to avoid disaster I cannot comment on implementational details but I have a suggestion: Instead of rewriting it should be possible to solve the problem on the macro level -- has this already be considered? Peter Schmitt a8131dal@awiuni11.edvz.univie.ac.at schmitt@awirap.bitnet ----------------------------------------------------------------------------- Institute of Mathematics Strudlhofgasse 4 University of Vienna A-1090 Wien Austria 12-Jan-1994 18:42:25-GMT,1985;000000000001 Return-Path: Received: from vs3002.ams.org by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA05944; Wed, 12 Jan 94 11:42:14 MST Received: from taptet.sscl.uwo.ca by MATH.AMS.ORG (PMDF #2306 ) id <01H7LHASGCM8PBI302@MATH.AMS.ORG>; Wed, 12 Jan 1994 13:13:39 EST Date: 12 Jan 1994 10:40:58 -0500 (EST) From: Chet Creider Subject: Re: [explanation of "Improper setbox" error message in 3.141] To: A8131DAL@AWIUNI11.EDVZ.UniVie.AC.AT Cc: tex-implementors@MATH.AMS.ORG Message-Id: <9401121540.AA19609@taptet.sscl.uwo.ca> Content-Transfer-Encoding: 7BIT > >Chet Creider asks for an explanation of change 399 (tex82.bug > > > >Now Chet quite reasonably thinks that as \'{\c{o}} was apparently > >working in TeX 3.14, he shouldn't have to rewrite all the occurrences > >as \c{\'{o}} (which works because it is \' that uses \accent, and \c > >that uses \setbox). But it turns out that TeX manged to avoid disaster > > I cannot comment on implementational details but I have a suggestion: > Instead of rewriting it should be possible to solve the problem on the > macro level -- has this already be considered? > > > Peter Schmitt a8131dal@awiuni11.edvz.univie.ac.at Chris Thompson's explanation has satisfied my intellectual curiousity, and sed has taken care of my practical problems. (I am almost certain as well that a rewrite of the macro for \c could solve the problem, but I haven't done this yet.) As someone from the `other side of the fence' in a certain sense (I am very fond of and a heavy user of troff and groff), I would like to thank the readers of tex-implementors@mat.ams.org for their kind interest and concern with my `Improper setbox' problem. Your expertise leaves me breathless as well! I hope there won't be a next time, but it seems to be in the nature of things that there will be, so let me sign off with `until next time': Until next time, Chet 12-Jan-1994 19:00:43-GMT,1985;000000000001 Return-Path: Received: from vs3002.ams.org by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA06083; Wed, 12 Jan 94 12:00:35 MST Received: from taptet.sscl.uwo.ca by MATH.AMS.ORG (PMDF #2306 ) id <01H7LBUQL88GPBI70E@MATH.AMS.ORG>; Wed, 12 Jan 1994 10:37:50 EST Date: 12 Jan 1994 10:40:58 -0500 (EST) From: Chet Creider Subject: Re: [explanation of "Improper setbox" error message in 3.141] To: A8131DAL@AWIUNI11.EDVZ.UniVie.AC.AT Cc: tex-implementors@MATH.AMS.ORG Message-Id: <9401121540.AA19609@taptet.sscl.uwo.ca> Content-Transfer-Encoding: 7BIT > >Chet Creider asks for an explanation of change 399 (tex82.bug > > > >Now Chet quite reasonably thinks that as \'{\c{o}} was apparently > >working in TeX 3.14, he shouldn't have to rewrite all the occurrences > >as \c{\'{o}} (which works because it is \' that uses \accent, and \c > >that uses \setbox). But it turns out that TeX manged to avoid disaster > > I cannot comment on implementational details but I have a suggestion: > Instead of rewriting it should be possible to solve the problem on the > macro level -- has this already be considered? > > > Peter Schmitt a8131dal@awiuni11.edvz.univie.ac.at Chris Thompson's explanation has satisfied my intellectual curiousity, and sed has taken care of my practical problems. (I am almost certain as well that a rewrite of the macro for \c could solve the problem, but I haven't done this yet.) As someone from the `other side of the fence' in a certain sense (I am very fond of and a heavy user of troff and groff), I would like to thank the readers of tex-implementors@mat.ams.org for their kind interest and concern with my `Improper setbox' problem. Your expertise leaves me breathless as well! I hope there won't be a next time, but it seems to be in the nature of things that there will be, so let me sign off with `until next time': Until next time, Chet 12-Jan-1994 19:00:51-GMT,5657;000000000001 Return-Path: Received: from VS3002.AMS.ORG by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AB06083; Wed, 12 Jan 94 12:00:46 MST Received: from MATH.AMS.ORG by MATH.AMS.ORG (PMDF #2306 ) id <01H7L5YQ5FHCP2R15G@MATH.AMS.ORG>; Wed, 12 Jan 1994 10:46:52 EST Date: 12 Jan 1994 10:46:39 -0500 (EST) From: bbeeton Subject: Re: [explanation of "Improper setbox" error message in 3.141] In-Reply-To: <01H7LB49B8PEPBI664@MATH.AMS.ORG> To: A8131DAL@AWIUNI11.EDVZ.UniVie.AC.AT Cc: tex-implementors@MATH.AMS.ORG, creider@taptet.sscl.uwo.ca Message-Id: <758389599.449825.BNB@MATH.AMS.ORG> Content-Transfer-Encoding: 7BIT Mail-System-Version: regarding \c{\'{o}}, it is well known by old-time texers that there has always been a prohibition on direct input of multiple accents on one character outside of math mode. i thought that this was explicit in the texbook, but when i look into my copy (admittedly still the first edition, and i haven't been diligent in posting errata and updates) all i find is this statement on p.54: (excerpted from the file texbook.tex; please observe that this is copyright) \ddanger Appendix B shows that plain \TeX\ handles most of the accents by using \TeX's ^|\accent| primitive. For example, |\'#1| is equivalent to |{\accent19 #1}|, where |#1| is the argument being accented. The general rule is that |\accent|\ puts an accent over the next character; the \ tells where that accent appears in the current font. The accent is assumed to be properly positioned for a character whose height equals the ^{x-height} of the current font; taller or shorter characters cause the accent to be raised or lowered, taking due account of the slantedness of the fonts of accenter and accentee. The width of the final construction is the width of the character being accented, regardless of the width of the accent. Mode-independent commands like font changes may appear between the accent number and the character to be accented, but grouping operations must not ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ intervene. If it turns out that no suitable character is present, the ^^^^^^^^^ accent will appear by itself as if you had said |\char|\ instead of\/ |\accent|\. For example, |\'{}| produces \'{}. the highlighted text covers the territory in question, i believe, although, to someone not familiar with the innards of tex, it certainly isn't crystal clear. i've had discussions on this with knuth, but at the moment can't find anything in writing. his belief is that languages that require more than one accent on particular letters should have fonts constructed explicitly for that purpose. this is an extension of his position that under-accents aren't handled in a more graceful manner for the same reason, and his justification is that designed accent-letter combinations usually look significantly better, i.e. more normal to a literate native, than piece accents. (nobody disagrees, but it's certainly more than a little inconvenient.) i'm quite sure that he didn't consider the requirements of linguistic transcription. i did discuss the matter of under-accents with him over a period of several years, and never managed to provide a convincing argument for an \underaccent primitive; i'm afraid that my failed attempts may have helped harden his position so that no one else was able later to obtain his agreement, even with better arguments than i could muster. here's the next double-danger paragraph from the same page: \ddanger It's important to remember that these conventions we have discussed for accents and special letters are not built into \TeX\ itself; they belong only to the plain \TeX\ format, which uses the Computer Modern fonts. Quite different conventions will be appropriate when other fonts are involved; format designers should provide rules for how to obtain accents and special characters in their particular systems. Plain \TeX\ works well enough when accents are infrequent, but the conventions of this chapter are by no means recommended for large-scale applications of \TeX\ to other languages. For example, a well-designed \TeX\ font for ^{French} might well treat accents as ligatures, so that one could |e'crire de cette manie`re nai"ve en franc/ais| without backslashes. (See the remarks about Norwegian in Chapter~8.) ^^{foreign languages} at the math society, we have implemented multiple accents with macros. here are several examples of "weird" accents, alone and in combination: % % both acute and under-dot \def \acudot#1{{\oalign{\accent19 #1\crcr\hidewidth.\hidewidth}}} % % both circumflex and under-dot \def \cfudot#1{{\oalign{\accent94 #1\crcr\hidewidth.\hidewidth}}} % Smashes repeated from AMS-TeX; PLAIN implements only full \smash . \newif\iftop@ \newif\ifbot@ \def\topsmash{\top@true\bot@false\smash@} \def\botsmash{\top@false\bot@true\smash@} \def\smash{\top@true\bot@true\smash@} \def\smash@{\relax\ifmmode\def\next{\mathpalette\mathsm@sh}% \else\let\next\makesm@sh\fi \next } \def\finsm@sh{\iftop@\ht\z@\z@\fi\ifbot@\dp\z@\z@\fi\box\z@} \def\smash@cc#1{\botsmash{\lower1ex\hbox{#1}}} % Under-accents designed, and normally used, as over-accents. \def \udr@cc#1#2{\ifmmode\udr@cc@{#1}{$#2$}\else\udr@cc@{#1}{#2}\fi} \def \udr@cc@#1#2{{\lineskiplimit\z@ \oalign{#2\crcr\hidewidth\smash@cc{#1}\hidewidth}}} \def \utilde#1{\udr@cc{\rm\char"7E}{#1}} \def \uarc#1{\udr@cc{\rm\char"15}{#1}} -- bb 12-Jan-1994 19:00:59-GMT,1985;000000000001 Return-Path: Received: from VS3002.AMS.ORG by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AB06083; Wed, 12 Jan 94 12:00:53 MST Received: from taptet.sscl.uwo.ca by MATH.AMS.ORG (PMDF #2306 ) id <01H7LD3ZJ3E8PBHV2H@MATH.AMS.ORG>; Wed, 12 Jan 1994 11:13:32 EST Date: 12 Jan 1994 10:40:58 -0500 (EST) From: Chet Creider Subject: Re: [explanation of "Improper setbox" error message in 3.141] To: A8131DAL@AWIUNI11.EDVZ.UniVie.AC.AT Cc: tex-implementors@MATH.AMS.ORG Message-Id: <9401121540.AA19609@taptet.sscl.uwo.ca> Content-Transfer-Encoding: 7BIT > >Chet Creider asks for an explanation of change 399 (tex82.bug > > > >Now Chet quite reasonably thinks that as \'{\c{o}} was apparently > >working in TeX 3.14, he shouldn't have to rewrite all the occurrences > >as \c{\'{o}} (which works because it is \' that uses \accent, and \c > >that uses \setbox). But it turns out that TeX manged to avoid disaster > > I cannot comment on implementational details but I have a suggestion: > Instead of rewriting it should be possible to solve the problem on the > macro level -- has this already be considered? > > > Peter Schmitt a8131dal@awiuni11.edvz.univie.ac.at Chris Thompson's explanation has satisfied my intellectual curiousity, and sed has taken care of my practical problems. (I am almost certain as well that a rewrite of the macro for \c could solve the problem, but I haven't done this yet.) As someone from the `other side of the fence' in a certain sense (I am very fond of and a heavy user of troff and groff), I would like to thank the readers of tex-implementors@mat.ams.org for their kind interest and concern with my `Improper setbox' problem. Your expertise leaves me breathless as well! I hope there won't be a next time, but it seems to be in the nature of things that there will be, so let me sign off with `until next time': Until next time, Chet 12-Jan-1994 19:06:06-GMT,1984;000000000001 Return-Path: Received: from vax01.ams.org by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA06290; Wed, 12 Jan 94 12:06:00 MST Received: from taptet.sscl.uwo.ca by MATH.AMS.ORG (PMDF #2306 ) id <01H7LF7D9HR4PBI3H1@MATH.AMS.ORG>; Wed, 12 Jan 1994 12:13:32 EST Date: 12 Jan 1994 10:40:58 -0500 (EST) From: Chet Creider Subject: Re: [explanation of "Improper setbox" error message in 3.141] To: A8131DAL@AWIUNI11.EDVZ.UniVie.AC.AT Cc: tex-implementors@MATH.AMS.ORG Message-Id: <9401121540.AA19609@taptet.sscl.uwo.ca> Content-Transfer-Encoding: 7BIT > >Chet Creider asks for an explanation of change 399 (tex82.bug > > > >Now Chet quite reasonably thinks that as \'{\c{o}} was apparently > >working in TeX 3.14, he shouldn't have to rewrite all the occurrences > >as \c{\'{o}} (which works because it is \' that uses \accent, and \c > >that uses \setbox). But it turns out that TeX manged to avoid disaster > > I cannot comment on implementational details but I have a suggestion: > Instead of rewriting it should be possible to solve the problem on the > macro level -- has this already be considered? > > > Peter Schmitt a8131dal@awiuni11.edvz.univie.ac.at Chris Thompson's explanation has satisfied my intellectual curiousity, and sed has taken care of my practical problems. (I am almost certain as well that a rewrite of the macro for \c could solve the problem, but I haven't done this yet.) As someone from the `other side of the fence' in a certain sense (I am very fond of and a heavy user of troff and groff), I would like to thank the readers of tex-implementors@mat.ams.org for their kind interest and concern with my `Improper setbox' problem. Your expertise leaves me breathless as well! I hope there won't be a next time, but it seems to be in the nature of things that there will be, so let me sign off with `until next time': Until next time, Chet 14-Jan-1994 1:39:59-GMT,789;000000000001 Received: from june.cs.washington.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA07008; Thu, 13 Jan 94 18:39:57 MST Return-Path: Received: from localhost (mackay@localhost) by june.cs.washington.edu (8.6.4/7.1ju+) id RAA08724; Thu, 13 Jan 1994 17:40:00 -0800 Date: Thu, 13 Jan 1994 17:40:00 -0800 From: mackay@cs.washington.edu (Pierre MacKay) Message-Id: <199401140140.RAA08724@june.cs.washington.edu> To: unixtex@u.washington.edu Cc: beebe@math.utah.edu In-Reply-To: Unix TeX distribution's message of Tue, 11 Jan 94 08:25:23 -0800 <9401111625.AA24313@stein1.u.washington.edu> Subject: Re: \setbox problem solved [creider@taptet.sscl.uwo.ca: Re: addendum to problem] Doubling the braces works. both \c{{\'o}} and \'{{\c{o}}} give the desired effect. 14-Jan-1994 1:58:13-GMT,1455;000000000001 Received: from vs3002.ams.org by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA07393; Thu, 13 Jan 94 18:58:09 MST Return-Path: mackay@MATH.AMS.ORG Received: from june.cs.washington.edu by MATH.AMS.ORG (PMDF #2306 ) id <01H7NB362C2OPBI843@MATH.AMS.ORG>; Thu, 13 Jan 1994 20:37:17 EST Received: from localhost (mackay@localhost) by june.cs.washington.edu (8.6.4/7.1ju+) id RAA08352; Thu, 13 Jan 1994 17:36:48 -0800 Date: 13 Jan 1994 17:36:48 -0800 From: mackay@cs.washington.edu (Pierre MacKay) Subject: Re: explanation of "Improper setbox" error message in 3.141 In-Reply-To: Chet Creider's message of 11 Jan 1994 09:15:47 -0500 (EST) <9401111415.AA16786@taptet.sscl.uwo.ca> To: creider@taptet.sscl.uwo.ca Cc: tex-implementors@MATH.AMS.ORG Message-Id: <199401140136.RAA08352@june.cs.washington.edu> Content-Transfer-Encoding: 7BIT We do not touch that part of TeX, so I can't understand why the change has occurred. We will look into it. Meanwhile, there is a fix that I have confirmed as working on my TeX3.141 \'{\c{o}} may not work but \'{{\c{o}}} does and so does \c{{\'o}} Email concerned with UnixTeX distribution software should be sent primarily to: UnixTeX@u.washington.edu Elizabeth Tachikawa otherwise to: mackay@cs.washington.edu Pierre A. MacKay Smail: Northwest Computing Support Center Resident Druid for Thomson Hall, Mail Stop DR-10 Unix-flavored TeX University of Washington Seattle, WA 98195 (206) 543-6259 28-Feb-1994 18:26:26-GMT,1394;000000000001 Return-Path: Received: from math.ams.org by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA25090; Mon, 28 Feb 94 11:26:13 MST Received: from sun2.nsfnet-relay.ac.uk by MATH.AMS.ORG (PMDF #2306 ) id <01H9F47HUCGW8Y5IWT@MATH.AMS.ORG>; Mon, 28 Feb 1994 12:50:43 EST Date: 28 Feb 1994 17:20:12 +0000 (GMT) From: CHAA006@VAX.RHBNC.AC.UK Subject: 2 queries: p/d change file for MFT (VAX/VMS), and utility DIFF -> .CH? To: tex-implementors Reply-To: Philip Taylor (RHBNC) Message-Id: <3620070B_00200A20.0097ABE689160E8C$34_1@UK.AC.RHBNC.VAX> Content-Transfer-Encoding: 7BIT Via: uk.ac.rhbnc.vax; Mon, 28 Feb 1994 17:20:24 +0000 Actually-To: Originally-To: $TEX-IMPLEMENTORS Mailer: Janet_Mailshr V3.5 ( 13-OCT-1989 14:07:27 ) Dear Colleagues -- I am currently bootstrapping a complete VAX/VMS TeX kit for the first time in many years, and would appreciate help on two points. (1)~Is anyone aware of a public-domain change file for MFT under VAX/VMS (I have only the K&S change file, and David Kellerman has indicated that he is not willing to allow it to enter the public domain), and (2)~is there available a utility for generating WEB .CH files from a DIFF listing (either VAX/VMS DIFFERENCES or one of the GNU DIFF programs)? Philip Taylor, RHBNC 9-Mar-1994 15:44:54-GMT,3253;000000000001 Return-Path: Received: from math.ams.org by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA18775; Wed, 9 Mar 94 08:44:47 MST Received: from MATH.AMS.ORG by MATH.AMS.ORG (PMDF #2306 ) id <01H9RJ8G39LC9I47EL@MATH.AMS.ORG>; Wed, 9 Mar 1994 10:26:31 EST Date: 09 Mar 1994 10:26:11 -0500 (EST) From: bbeeton Subject: [andrew.trevorrow@anu.edu.au (Andrew K Trevorrow): new TeX bug] To: tex-implementors@MATH.AMS.ORG Message-Id: <763226771.586965.BNB@MATH.AMS.ORG> Content-Transfer-Encoding: 7BIT Mail-System-Version: i've received the attached bug report from andrew trevorrow. please send comments back promptly; as soon as the problem has been verified, i'll forward it to knuth. (it's getting to be time for his annual tex-inspection tour.) thanks. -- bb -------------------- Date: 09 Mar 1994 16:59:50 -0500 (EST) From: andrew.trevorrow@anu.edu.au (Andrew K Trevorrow) To: bnb@MATH.AMS.ORG Subject: new TeX bug Hi Barbara, I think I've found a bug in TeX. Please pass on the following note to the TeX implementors to verify my analysis. ---------------- Over the last couple of years a few OzTeX users have reported a strange bug in which a character at the start of a word changes for no obvious reason. I was never able to reproduce the problem until the other day when Ole Michael Selberg sent me the vital clue: the problem only happens if font_mem_size is increased and the format file is NOT rebuilt. (OzTeX users don't have to recompile TeX to change font_mem_size; they simply edit a number in a configuration file.) Now font_mem_size is supposed to be one of the parameters that can differ in INITEX and VIRTEX. The problem is that non_address is set to font_mem_size, so when bchar_label[f] values are set to non_address and stored in a format file by INITEX they will not be recognized as non-address values by a VIRTEX that uses a different font_mem_size! Note that if font_mem_size in VIRTEX is smaller than the INITEX value then a fatal format error will occur when loading bchar_label[nullfont] (which was set to non_address by INITEX). If font_mem_size in VIRTEX is larger than the INITEX value then far nastier problems can occur, such as a character at the start of a word changing. One solution would be to treat font_mem_size like hash_size and the other parameters that require format files to be rebuilt if their values change. A better solution is to set non_address to -1; this allows font_mem_size to be different in INITEX and VIRTEX. Here are the changes needed to tex.web: @x @!font_index=0..font_mem_size; {index into |font_info|} @y @!font_index=-1..font_mem_size; {index into |font_info|} @z @x @d non_address==font_mem_size {a spurious |font_index|} @y @d non_address==-1 {a spurious |font_index|} @z @x if bchar_label[hf]non_address then {put left boundary at beginning of new line} @z @x undump(0)(font_mem_size)(bchar_label[k]); @y undump(non_address)(font_mem_size-1)(bchar_label[k]); @z I've included these changes in a new version of OzTeX and they fix the bug. Andrew Trevorrow akt150@huxley.anu.edu.au 10-Mar-1994 10:16:56-GMT,2438;000000000001 Return-Path: Received: from math.ams.org by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA07505; Thu, 10 Mar 94 03:16:50 MST Received: from ifi.informatik.uni-stuttgart.de by MATH.AMS.ORG (PMDF #2306 ) id <01H9SLM66B008Y6O77@MATH.AMS.ORG>; Thu, 10 Mar 1994 04:29:49 EST Received: from azu.informatik.uni-stuttgart.de by ifi.informatik.uni-stuttgart.de with SMTP; Thu, 10 Mar 94 10:29:31 +0100 Received: by azu.informatik.uni-stuttgart.de; Thu, 10 Mar 94 10:29:16 +0100 Date: 10 Mar 1994 10:29:16 +0100 From: Bernd Raichle Subject: Re: font_mem_size In-Reply-To: "Wayne G. Sullivan"'s message of 09 Mar 1994 18:10:36 +0000 (GMT) <01H9RPPQULG28Y6LJ0@MATH.AMS.ORG> To: tex-implementors@MATH.AMS.ORG Message-Id: <9403100929.AA11762@azu.informatik.uni-stuttgart.de> Content-Transfer-Encoding: 7BIT on 09 Mar 1994 18:10:36 +0000 (GMT), "Wayne G. Sullivan" said: Wayne> In order to qualify as a BUG of TeX, I believe it is necessary for the Wayne> bug to be in tex.web. If TeX misbehaves because of a change file, it Wayne> does not seem quite fair to blame DEK. I can find no place in tex.web Wayne> where it is suggested that production versions of TeX should have a larger Wayne> font_mem_size than that for INITEX. The definition of the ``constant'' |font_mem_size| is in the section commented with @ The following parameters can be changed at compile time to extend or reduce \TeX's capacity. They may have different values in \.{INITEX} and ^^^^^^^^^^^^^^^^^^^^^^^^^ in production versions of \TeX. The bug in TeX.web is either that a) the (constant) value of |font_mem_size| is used to mark a |non_address| in the tfm info (array |bchar_label|) which is then saved in the format file (= bug in program code) or b) that the value of |font_mem_size| is allowed to have different values in IniTeX and VirTeX (= bug in documentation). Btw, if you want to make an implementation with user configurable sizes of the main mem, font mem, trie mem, etc., it is necessary to make the definition of |non_address| invariant of |font_mem_size| to allow a changeable size of the |font_info| array. (I know that this change is in the change files of emTeX and brTeX/PasTeX, but neither Eberhard nor myself have identified this as a bug in TeX.web :-(.) Bernd Raichle 10-Mar-1994 13:22:04-GMT,4776;000000000001 Return-Path: <71172.524@CompuServe.COM> Received: from math.ams.org by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA11757; Thu, 10 Mar 94 06:21:59 MST Received: from dub-img-1.compuserve.com by MATH.AMS.ORG (PMDF #2306 ) id <01H9ST70HYHC8Y6NG4@MATH.AMS.ORG>; Thu, 10 Mar 1994 08:07:12 EST Received: from localhost by dub-img-1.compuserve.com (8.6.4/5.930129sam) id IAA03987; Thu, 10 Mar 1994 08:05:50 -0500 Date: 10 Mar 1994 08:03:11 -0500 (EST) From: Berthold Horn <71172.524@CompuServe.COM> Subject: andrews bug et alia To: Peter Breitenlohner Cc: Barbara Beeton , TeX Implementirs , Andrew Trevorrow Message-Id: <940310130310_71172.524_DHQ25-1@CompuServe.COM> Content-Transfer-Encoding: 7BIT Dear Barbara (and Peter, Chris, Andrew, ...), > 2. berthold horns msg from Dec 17 > ad 2: non_address=max_halfword is probably OK as well, I have not checked > all implications. I prefer =0 and this has the definite advantage that it > does catch old formats that need to be rebuilt. (Having to rebuild formats > when the program changes - even if the pool checksum doesn't change - > is certainly ok.) Well, there is nothing wrong with using max_halfword for this that I can see (and it is in the spirit of using some `impossibly large' number) and I am *not* convinced that there aren't problems with using 0. But I'll be happy to change it if that in fact can be shown to be safe... > ad 3: that is entirely up to implementors, the 262144 never shows up in > tex.web. But bigTeX has to set some reasonable limit on the size of > the mem array otherwise a stupid paging system uses up enormous amounts of > paging space and non-paging systems are completely sunk. > Cetainly 256K is as good as any other number of the right size. Re: max_halfword. This is used mostly to (i) indicate invalid values (see above for example), and (ii) to limit how big various arrays *can* get. I don't see what this has to do with paging systems. Nothing is ever allocated of size max_halfword. I am *not* talking here about making a `bigg TeX'. However, note that a `dynamic' TeX *cannot* have max_halfword set to 262144, since it must allow things to get bigger than in current `big' TeX's (Many TeX jobs --- such as the `LaTeX Companion --- already now get close to the current limit, or have to split to avoid it --- so we will see more of this). > ad 4: It would be tempting to increase font_max once max_halfword and > max_quarterword have been increased. TeX uses at present only one-byte > font numbers in the DVI file, i.e., range 0..255. Clearly TeX's dvi writing > routines could certainly be adapted to a larger range, no problem here. > But: Extending this range may have implications on existing DVI software. > Some DVI drivers may rely on one-byte font numbers (re: driver standard?). > Therefore I would be very careful at this point!! Right, which is why it is time to upgrade the standards for DVI drivers! Presently the (level 0) standard is inconsistent in that on the one hand, the driver *must* support multi-byte font numbers, yet it need not support font numbers larger than 255. This is an urgent issue, since many jobs now are approaching the 255 limit --- such as the `LaTeX Companion', and some journals that Elsevier does. This is not to say that DVI drivers need to support that many fonts actually being used simultaneously --- just how large internal font numbers are allowed to get. > ad 1: I can't understand this problem. In VIRTEX mem_min must be <=mem_bot, > and mem_min>=min_halfword=null. Now mem_bot is a glue spec, hence can never > occur when traversing a list. If mem_min is mem_bot-1 or mem_bot-2 the one > or two extra words are never used and if mem_min is also never used (done in undump memory). Hence the word mem[mem_min] > is either a glue spec or unused. This can never give a problem > with tests such as p>mem_min when traversing lists. > It might be nicer to test for p<>null but I think this is no bug. > Maybe only don knows why he has formulated this one test in a different way, > but probably he forgotten the reasoning behind that. Believe me, this very definitely *is* a bug! Think about what happens when you extend the variable length node list downward. You can't very well then go back over all list structures and change `null' to the new `mem_min'! > A bug might creep in if someone is dynamically extending the mem array during > the run of VIRTEX and is not doing it properly (mimicking the behaviour of > undump). I would say any problems introduced here are due to improper sys-dep > modifications. Regards, Berthold. 10-Mar-1994 13:58:51-GMT,1521;000000000001 Return-Path: Received: from math.ams.org by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA11875; Thu, 10 Mar 94 06:58:45 MST Received: from ppsw1.cam.ac.uk (gray.csi.cam.ac.uk) by MATH.AMS.ORG (PMDF #2306 ) id <01H9STFM5FBK8Y6RFA@MATH.AMS.ORG>; Thu, 10 Mar 1994 08:13:37 EST Received: from phx.cam.ac.uk by ppsw1.cam.ac.uk with GB-CAM (PP-6.0) as ppsw.cam.ac.uk id <16895-0@ppsw1.cam.ac.uk>; Thu, 10 Mar 1994 13:13:00 +0000 Date: 10 Mar 1994 13:12:54 +0000 (GMT) From: Chris Thompson Subject: Re: font_mem_size To: tex-implementors@MATH.AMS.ORG Message-Id: Content-Transfer-Encoding: 7BIT I agree with Bernd Raichle (and with Peter Breitenlohner, according to e-mail received from him): there is no doubt that |font_mem_size| is meant to be among the parameters that can differ between INITeX and TeX, or between differently parameterised TeX's using the same format file. Bernd says that if this were in fact not the case, then the bug would be > b) that the value of |font_mem_size| is allowed to have different > values in IniTeX and VirTeX (= bug in documentation). To this one can add that if the value is not meant to change, then it should be dumped in the format file, like |eqtb_size|, |hash_prime| and so forth. The absence of this would be a bug (or at least, a serious infelicity) in the code. Chris Thompson Cambridge University Computing Service Internet: cet1@phx.cam.ac.uk JANET: cet1@uk.ac.cam.phx 10-Mar-1994 17:46:02-GMT,2798;000000000001 Return-Path: Received: from math.ams.org by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA14912; Thu, 10 Mar 94 10:45:54 MST Received: from MZDMZA.ZDV.UNI-MAINZ.DE (vzdmzd.zdv.Uni-Mainz.DE) by MATH.AMS.ORG (PMDF #2306 ) id <01H9T12DURSG8Y5O2A@MATH.AMS.ORG>; Thu, 10 Mar 1994 11:52:37 EST Received: from MZDMZA.ZDV.UNI-MAINZ.DE by MZDMZA.ZDV.UNI-MAINZ.DE (PMDF V4.2-11 #4432) id <01H9TDL16NOG8WWCOL@MZDMZA.ZDV.UNI-MAINZ.DE>; Thu, 10 Mar 1994 17:50:28 +0100 Date: 10 Mar 1994 17:50:28 +0100 From: Frank Mittelbach Subject: Re: font_mem_size To: tex-implementors@MATH.AMS.ORG Message-Id: <01H9TDL17Q9E8WWCOL@MZDMZA.ZDV.UNI-MAINZ.DE> X-Vms-To: IN"tex-implementors@MATH.AMS.ORG" X-Vms-Cc: MITTELBACH Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT To: IN%"tex-implementors@MATH.AMS.ORG" > Subj: [andrew.trevorrow@anu.edu.au (Andrew K Trevorrow): new TeX bug] > > > Now font_mem_size is supposed to be one of the parameters that can differ > in INITEX and VIRTEX. The problem is that non_address is set to font_mem_size, > so when bchar_label[f] values are set to non_address and stored in a format > file by INITEX they will not be recognized as non-address values by a VIRTEX > that uses a different font_mem_size! > > Note that if font_mem_size in VIRTEX is smaller than the INITEX value > then a fatal format error will occur when loading bchar_label[nullfont] > (which was set to non_address by INITEX). If font_mem_size in VIRTEX is > larger than the INITEX value then far nastier problems can occur, such as > a character at the start of a word changing. I can't agree with Wayne on the point of this not being mentioned in tex.web. the font_mem_size is listed under: @ The following parameters can be changed at compile time to extend or reduce \TeX's capacity. They may have different values in \.{INITEX} and in production versions of \TeX. half a year ago i was hit by the same problem (call it an error or not :-) when i was preparing the LaTeX Companion. I had to enlarge the font_mem_size several times (web2c implementation) to allow for more fonts being loaded during runtime. Since the parameter was listed under the above heading i only regenerated virtex (and initex) but didn't produce new formats. The result were very weird errors like ligatures appearing at the begin of a word etc etc. I finally found that this was due to my change of the parameter without rerunning initex. I filed the problem away due to time shortage but i thought and still think it classifies under a bug, at least the parameter need to be moved to the next section in tex.web. However if there is a fix for the problem it would even be better to fix it. cheers frank 10-Mar-1994 18:02:02-GMT,3408;000000000001 Return-Path: Received: from math.ams.org by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA15067; Thu, 10 Mar 94 11:01:47 MST Received: from MZDMZA.ZDV.UNI-MAINZ.DE (vzdmzd.zdv.Uni-Mainz.DE) by MATH.AMS.ORG (PMDF #2306 ) id <01H9T12DURSG8Y5O2A@MATH.AMS.ORG>; Thu, 10 Mar 1994 11:56:37 EST Received: from MZDMZA.ZDV.UNI-MAINZ.DE by MZDMZA.ZDV.UNI-MAINZ.DE (PMDF V4.2-11 #4432) id <01H9TDL3ZNV48WWCOL@MZDMZA.ZDV.UNI-MAINZ.DE>; Thu, 10 Mar 1994 17:50:32 +0100 Date: 10 Mar 1994 17:50:32 +0100 From: Frank Mittelbach Subject: problems with the value of prevdepth To: tex-implementors@MATH.AMS.ORG Message-Id: <01H9TDL40GSY8WWCOL@MZDMZA.ZDV.UNI-MAINZ.DE> X-Vms-To: IN"tex-implementors@MATH.AMS.ORG" X-Vms-Cc: MITTELBACH Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT To: IN%"tex-implementors@MATH.AMS.ORG" since Andrew was faster on font_mem_size i would like to report another problem we enountered recently and hear your opinion about it. LaTeX has a command \vspace*{} that is supposed to produce extra vertical space which doesn't even vanishes between page breaks. The amount of extra space should be exactly . For this reason the command looks (if in vmode) at \prevdepth produces an invisible rule (to avoid getting discarded just after a page break) then a \penalty10000 followed by \vskip (another \vskip\z@ to guard against a following \unskip) followed by setting \prevdepth to the value encountered before the rule. This should give exactly the right space, for example, if placed at the beginning of a page it should lower the first line by exactly but unfortunately it doesn't. According to the TeX book \prevdepth is set to -1000pt at the beginning of a vertical list. This is done for the main vertical list as well, however it is not done for the individual main vertical list that forms a page. As a result, the depth of the last line on a preceding page influences the value of \prevdepth at the beginning of the next. this doesn't really matter since TeX doesn't look at prevdepth when it places the first line on the page (using \topskip instead) but it does very much matter when a macro looks at the internal quantity. The reason for current implementation is clear: if something is left on recent contributions, the value of \prevdepth is important since it reflects the depth of the last line in recent contributions and the implementation needs to preserve this value so the the next line contributed gets an appropriate interline spacing. However, since there is no way of determining on the macro level whether recent contributions are empty or not, there is no way to find out if the value of \prevdepth actually reflects the truth resulty in very ugly results on twolcoumn layout and other situations if you are unlucky. One can certainly argue that this is correct by definition: the main vertical list is a single list and therefore prevdepth is never supposed to be reset. However, I think that this interpretation is not natural; my suggestion would be to apply the following algorithm: In the output routine set \prevdepth to -1000pt iff the recent contributions are completely emptied otherwise leave it untouched since it reflects the depth of the last box as it will be seen on the macro level. cheers frank 9-Mar-1994 19:03:10-GMT,1331;000000000001 Return-Path: <@HEARN.nic.SURFnet.nl:WSULIVAN@IRLEARN.UCD.IE> Received: from math.ams.org by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA22405; Wed, 9 Mar 94 12:03:05 MST Received: from HEARN.nic.SURFnet.nl by MATH.AMS.ORG (PMDF #2306 ) id <01H9RPPPUEE88Y6LJ0@MATH.AMS.ORG>; Wed, 9 Mar 1994 13:16:29 EST Received: from IRLEARN.UCD.IE by HEARN.nic.SURFnet.nl (IBM VM SMTP V2R2) with BSMTP id 1971; Wed, 09 Mar 94 19:15:22 CET Received: from IRLEARN.UCD.IE (NJE origin WSULIVAN@IRLEARN) by IRLEARN.UCD.IE (LMail V1.2a/1.8a) with BSMTP id 9164; Wed, 9 Mar 1994 18:20:10 +0000 Date: 09 Mar 1994 18:10:36 +0000 (GMT) From: "Wayne G. Sullivan" Subject: font_mem_size To: tex-implementors@MATH.AMS.ORG Message-Id: <01H9RPPQULG28Y6LJ0@MATH.AMS.ORG> Content-Transfer-Encoding: 7BIT In order to qualify as a BUG of TeX, I believe it is necessary for the bug to be in tex.web. If TeX misbehaves because of a change file, it does not seem quite fair to blame DEK. I can find no place in tex.web where it is suggested that production versions of TeX should have a larger font_mem_size than that for INITEX. Actually it is a good idea, but anyone who implements such a change is responsible for checking that the changes introduced do not produce bugs. Wayne Sullivan 11-Mar-1994 13:11:03-GMT,1321;000000000001 Return-Path: <71172.524@CompuServe.COM> Received: from math.ams.org by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA04363; Fri, 11 Mar 94 06:10:53 MST Received: from arl-img-1.compuserve.com by MATH.AMS.ORG (PMDF #2306 ) id <01H9U69FB8ZK8Y6NG1@MATH.AMS.ORG>; Fri, 11 Mar 1994 07:31:12 EST Received: from localhost by arl-img-1.compuserve.com (8.6.4/5.930129sam) id HAA05081; Fri, 11 Mar 1994 07:31:02 -0500 Date: 11 Mar 1994 07:27:39 -0500 (EST) From: Louis Vosloo <71172.524@CompuServe.COM> Subject: clarification To: TeX Implementors Message-Id: <940311122738_71172.524_DHQ57-1@CompuServe.COM> Content-Transfer-Encoding: 7BIT Hi: What I meant in my rumblings about max_half_word is the following: max_half_word should be what the name says it is, namely the *actual* max_half_word for the particular `word' size used in the TeX implementation, --- *not* the max_half_word for some ficticuous 36 bit CPU. And max_half_word should *not* be tied to the initial main memory allocation of iniTeX. --- max_half_word has nothing to do with how large you decide to make TeX's main memory (except that it has to be at least as large). In a dynamic TeX you cannot work with max_half_word set to 262144. Otherwise you can't grow various memory space beyond that. Regards, Berthold. 28-Mar-1994 19:38:27-GMT,1293;000000000001 Return-Path: Received: from math.ams.org by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA18446; Mon, 28 Mar 94 12:38:12 MST Received: from netcom10.netcom.com (netcom11.netcom.com) by MATH.AMS.ORG (PMDF #2306 ) id <01HAIBQQ5XB49TDPBN@MATH.AMS.ORG>; Mon, 28 Mar 1994 14:27:49 EST Received: from localhost by netcom10.netcom.com (8.6.4/SMI-4.1/Netcom) id LAA17402; Mon, 28 Mar 1994 11:28:30 -0800 Date: 28 Mar 1994 11:28:27 -0800 (PST) From: quixote@netcom.com (Don Hosek) Subject: Extending quarterword to 16 bits To: tex-implementors@MATH.AMS.ORG Reply-To: dhosek@quixote.com, tex-implementors@MATH.AMS.ORG Message-Id: <199403281928.LAA17402@netcom10.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: ELM [version 2.4 PL23] Content-Length: 454 Has anyone had experience with doing this? I'm beginning to experiment (with the goal of eliminating the restrictiong of 256 fonts loaded in TeX), but haven't explored all the ramifications (and yes, I know I need to modify \S610). One early unexpected result has been a TeX capacity exceeded error on reading the German hyphenation patterns (the only mods at this point are boosting font_max, max_quarterword and adapting the consistency checks). -dh 28-Mar-1994 19:59:58-GMT,4008;000000000001 Return-Path: Received: from math.ams.org by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA18817; Mon, 28 Mar 94 12:59:53 MST Received: from leeman.york.ac.uk by MATH.AMS.ORG (PMDF #2306 ) id <01HAICK9JHSG9TDMOP@MATH.AMS.ORG>; Mon, 28 Mar 1994 14:50:59 EST Received: from vax.york.ac.uk by leeman.york.ac.uk id <28828-0@leeman.york.ac.uk>; Mon, 28 Mar 1994 20:44:28 +0100 Date: 28 Mar 1994 20:44:28 +0100 From: postmaster@leeman.york.ac.uk Subject: Delivery Report (failure) for spqr@ftp.tex.ac.uk To: tex-implementors@MATH.AMS.ORG Message-Id: <"leeman.yor.823:28.02.94.19.44.22"@york.ac.uk> Content-Identifier: Extending qua... Content-Transfer-Encoding: 7BIT Message-Type: Delivery Report ------------------------------ Start of body part 1 This report relates to your message: Subject: Extending quarterword to 16 bits, Message-ID: <199403281928.LAA17402@netcom10.netcom.com>, To: tex-implementors@MATH.AMS.ORG of Mon, 28 Mar 1994 20:34:43 +0100 Your message was not delivered to spqr@ftp.tex.ac.uk for the following reason: Unknown Address No nameserver addresses for ftp.tex.ac.uk ***** The following information is directed towards the local administrator ***** and is not intended for the end user * * DR generated by: mta leeman.york.ac.uk * in /PRMD=UK.AC/ADMD= /C=GB/ * at Mon, 28 Mar 1994 20:44:22 +0100 * * Converted to RFC 822 at leeman.york.ac.uk * at Mon, 28 Mar 1994 20:44:28 +0100 * * Delivery Report Contents: * * Subject-Submission-Identifier: [/PRMD=UK.AC/ADMD= /C=GB/;<199403281928.LAA17402@netcom10.] * Content-Identifier: Extending qua... * Subject-Intermediate-Trace-Information: /PRMD=UK.AC/ADMD= /C=GB/arrival Mon, 28 Mar 1994 20:34:43 +0100 action Relayed * Subject-Intermediate-Trace-Information: /PRMD=UK.AC/ADMD= /C=GB/arrival Mon, 28 Mar 1994 20:28:27 +0100 action Relayed * Content-Correlator: Subject: Extending quarterword to 16 bits, * Message-ID: <199403281928.LAA17402@netcom10.netcom.com>, * To: tex-implementors@MATH.AMS.ORG* Recipient-Info: spqr@ftp.tex.ac.uk, * /S=spqr/OU=ftp/O=tex/PRMD=UK.AC/ADMD= /C=GB/; * FAILURE reason Unable-To-Transfer (1); * diagnostic Unrecognised-ORName (0); * last trace (ia5 text (2)) Mon, 28 Mar 1994 20:28:27 +0100; * converted eits ia5 text (2); * supplementary info "No nameserver addresses for * ftp.tex.ac.uk"; ****** End of administration information ------------------------------ Start of forwarded message 1 Received: from minster.york.ac.uk by leeman.york.ac.uk with SMTP (PP) id <28692-0@leeman.york.ac.uk>; Mon, 28 Mar 1994 20:34:44 +0100 From: tex-implementors@MATH.AMS.ORG Received: from netcom10.netcom.com (netcom11.netcom.com) by MATH.AMS.ORG (PMDF #2306 ) id <01HAIBQQ5XB49TDPBN@MATH.AMS.ORG>; Mon, 28 Mar 1994 14:27:49 EST Received: from localhost by netcom10.netcom.com (8.6.4/SMI-4.1/Netcom) id LAA17402; Mon, 28 Mar 1994 11:28:30 -0800 Date: 28 Mar 1994 11:28:27 -0800 (PST) >From: quixote@netcom.com (Don Hosek) Subject: Extending quarterword to 16 bits To: tex-implementors@MATH.AMS.ORG Reply-to: dhosek@quixote.com, tex-implementors@MATH.AMS.ORG Message-id: <199403281928.LAA17402@netcom10.netcom.com> MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: ELM [version 2.4 PL23] Content-Length: 454 Has anyone had experience with doing this? I'm beginning to experiment (with the goal of eliminating the restrictiong of 256 fonts loaded in TeX), but haven't explored all the ramifications (and yes, I know I need to modify \S610). One early unexpected result has been a TeX capacity exceeded error on reading the German hyphenation patterns (the only mods at this point are boosting font_max, max_quarterword and adapting the consistency checks). - -dh ------------------------------ End of forwarded message 1 28-Mar-1994 22:27:26-GMT,1697;000000000001 Return-Path: <71172.524@CompuServe.COM> Received: from math.ams.org by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA21617; Mon, 28 Mar 94 15:27:16 MST Received: from dub-img-2.compuserve.com by MATH.AMS.ORG (PMDF #2306 ) id <01HAIGLZX61S9TDRBD@MATH.AMS.ORG>; Mon, 28 Mar 1994 16:46:42 EST Received: from localhost by dub-img-2.compuserve.com (8.6.4/5.930129sam) id QAA13245; Mon, 28 Mar 1994 16:45:33 -0500 Date: 28 Mar 1994 16:41:47 -0500 (EST) From: Berthold Horn <71172.524@CompuServe.COM> Subject: Extending quarterword to 16 bits To: "INTERNET:quixote@netcom.com" Cc: TeX Implementors Message-Id: <940328214146_71172.524_DHQ129-1@CompuServe.COM> Content-Transfer-Encoding: 7BIT Dear Don: > Has anyone had experience with doing this? I'm beginning to experiment > (with the goal of eliminating the restrictiong of 256 fonts loaded > in TeX), but haven't explored all the ramifications (and yes, I know I > need to modify \S610). One early unexpected result has been a TeX > capacity exceeded error on reading the German hyphenation patterns > (the only mods at this point are boosting font_max, max_quarterword > and adapting the consistency checks). Yes, Y&YTeX does this. Its sort of a natural thing to do on machines were the TeX word is 64 bit. No big problems other than you need to modify the code were the font number is written to the DVI file -- to provide for multi-byte font numbers - which I guess is what you are referring to above... And, as you know :=), all decent DVI processors should be able to read multi- byte font numbers -- although most of them don't know what to do with them. Regards, Berthold. 29-Mar-1994 11:42:06-GMT,928;000000000001 Return-Path: Received: from math.ams.org by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA00478; Tue, 29 Mar 94 04:41:54 MST Received: from terminus.cs.umb.edu by MATH.AMS.ORG (PMDF #2306 ) id <01HAJ7NPQN009TDRD3@MATH.AMS.ORG>; Tue, 29 Mar 1994 05:41:33 EST Received: by terminus.cs.umb.edu id AA25088 (5.65c/IDA-1.4.4 for tex-implementors@MATH.AMS.ORG); Tue, 29 Mar 1994 05:41:15 -0500 Date: 29 Mar 1994 05:41:15 -0500 From: "K. Berry" Subject: Re: Extending quarterword to 16 bits To: dhosek@quixote.com, tex-implementors@MATH.AMS.ORG Message-Id: <199403291041.AA25088@terminus.cs.umb.edu> Content-Transfer-Encoding: 7BIT Bernd Raichle sent me some changes to extend web2c TeX to more than 256 fonts. It's in the README file in the web2c distribution. Perhaps I should install the changes into web2c's main change file; have to revisit that. 29-Mar-1994 13:26:28-GMT,2565;000000000001 Return-Path: Received: from math.ams.org by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA04290; Tue, 29 Mar 94 06:26:23 MST Received: from ifi.informatik.uni-stuttgart.de by MATH.AMS.ORG (PMDF #2306 ) id <01HAJC8TE7689TD8QD@MATH.AMS.ORG>; Tue, 29 Mar 1994 07:58:04 EST Received: from azu.informatik.uni-stuttgart.de by ifi.informatik.uni-stuttgart.de with SMTP; Tue, 29 Mar 94 14:50:15 +0200 Received: by azu.informatik.uni-stuttgart.de; Tue, 29 Mar 94 14:49:12 +0200 Date: 29 Mar 1994 14:49:12 +0200 From: Bernd Raichle Subject: Re: Extending quarterword to 16 bits In-Reply-To: Don Hosek's message of 28 Mar 1994 11:28:27 -0800 (PST) <199403281928.LAA17402@netcom10.netcom.com> To: tex-implementors@MATH.AMS.ORG Message-Id: <9403291249.AA09484@azu.informatik.uni-stuttgart.de> Content-Transfer-Encoding: 7BIT on 28 Mar 1994 11:28:27 -0800 (PST), quixote@netcom.com (Don Hosek) said: Don> Has anyone had experience with doing this? I'm beginning to experiment Don> (with the goal of eliminating the restrictiong of 256 fonts loaded Don> in TeX), but haven't explored all the ramifications (and yes, I know I Don> need to modify \S610). Don't forget to change the definiton of |undefined_control_sequence| to leave place in |eqtb| for the additional font identifiers (I have introduced a constant |max_font_max|, which must have the same value for IniTeX and VirTeX and replaces the constant 256 in the original places and definitions). Don> One early unexpected result has been a TeX Don> capacity exceeded error on reading the German hyphenation patterns Don> (the only mods at this point are boosting font_max, max_quarterword Don> and adapting the consistency checks). To read ghyphen.tex it's necessary to blow up the Trie constants (trie_size, trie_op_size). The ``big trie change'' of the original trie structures to allow more than 256 trie opcodes per language (for "ghyphen.max") shouldn't be necessary because you are using larger |quarter_word|s. Berthold Horn <71172.524@CompuServe.COM> said: > And, as you know :=), all decent DVI processors should be able to read multi- > byte font numbers -- although most of them don't know what to do with them. yes, all decent DVI processors should be able to read multi-byte font numbers and if they are good, they can process fonts with a font number > 255.... but there are good DVI processors which are not able to process more than 256 fonts per document (see: DVI driver standard, Level 0). Bernd Raichle 7-Apr-1994 14:25:00-GMT,6490;000000000001 Return-Path: Received: from silverfork.math.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA01923; Thu, 7 Apr 94 08:22:31 MDT Date: Thu, 7 Apr 94 08:22:31 MDT From: "Nelson H. F. Beebe" To: tex-implementors@math.ams.com, tex-archive@math.utah.edu, TWG-TAG@SHSU.edu Cc: beebe X-Us-Mail: "Center for Scientific Computing, University of Utah, Salt Lake City, UT 84112" X-Telephone: +1 801 581 5254 X-Fax: +1 801 581 4148 Subject: URGENT: ftp security alert Message-Id: In case some of you are not on the Computer Emergency Response Team (CERT) mailing list, I'm reposting this urgent message which arrived in my mailbox yesterday afternoon. I worked until late last night to get the ftp server on ftp.math.utah.edu upgraded to this latest version; comparison of sources with the previous version did not find any Trojan Horse code, so I don't believe that our ftp host has been compromised. Ftp access to our site was shut down for a few hours yesterday while I investigated this. The CERT message does not describe how the ftpd code was modified, but examination of the code shows that it would be quite easy to change one of the set*uid() function calls to leave a remote user with root privileges on the ftp server, perhaps only when certain ftp commands were issued, or when a particular username@hostname password was provided. I will shortly be making available the extended ftpd code, but instead of placing it in an anonymous ftp directory where it could be corrupted by a successful breakin, I will make separate arrangements for the transfer of the code with anyone who requests it. During installation and testing on several architectures, I found that the code has undocumented features that are useful, and which I will document before releasing the modified version. The older extended version of the ftpd program that has been available until now in ftp.math.utah.edu:/pub/misc/ftpd.trz has been deleted; if you have copies of ANY ftpd code in your archives, I suggest you seriously consider removing them. From: CERT Advisory Date: Wed, 6 Apr 94 12:51:16 EDT To: cert-advisory@cert.org Subject: CERT Advisory - wuarchive ftpd Trojan Horse Organization: Computer Emergency Response Team : 412-268-7090 Resent-To: cnet@lists.utah.edu Resent-Date: Wed, 6 Apr 94 13:13:16 MDT ============================================================================= CA-94:07 CERT Advisory April 6, 1994 wuarchive ftpd Trojan Horse ----------------------------------------------------------------------------- The CERT Coordination Center has received confirmation that some copies of the source code for the wuarchive FTP daemon (ftpd) were modified by an intruder, and contain a Trojan horse. We strongly recommend that any site running the wuarchive ftpd take steps to immediately install version 2.3, or disable their FTP daemon. ----------------------------------------------------------------------------- I. Description Some copies of the source code for versions 2.2 and 2.1f of the wuarchive ftpd were modified by an intruder, and contain a Trojan horse. If your FTP daemon was compiled from the intruder-modified source code, you are vulnerable. It is possible that previous versions of the source code for the server were modified in a similar manner. If you are running the wuarchive ftpd, but not providing anonymous FTP access, you are still vulnerable to this Trojan horse. II. Impact An intruder can gain root access on a host running an FTP daemon that contains this Trojan horse. III. Solution We strongly recommend that any site running the wuarchive ftpd (version 2.2 or earlier) take steps to immediately install version 2.3. If you cannot install the new version in a timely manner, you should disable FTP service. It is not sufficient to disable anonymous FTP. You must disable the FTP daemon. Sites can obtain version 2.3 via anonymous FTP from ftp.uu.net, in the "/networking/ftp/wuarchive-ftpd" directory. We recommend that you turn off your FTP server until you have installed the new version. Be certain to verify the checksum information to confirm that you have retrieved a valid copy. BSD SVR4 File Checksum Checksum MD5 Digital Signature ----------------- -------- --------- -------------------------------- wu-ftpd-2.3.tar.Z 24416 181 30488 361 e58adc5ce0b6eae34f3f2389e9dc9197 --------------------------------------------------------------------------- The CERT Coordination Center wishes to thank Bryan O'Connor and Chris Myers of Washington University in St. Louis for their invaluable assistance in resolving this problem. CERT also gratefully acknowledges the help of Neil Woods and Karl Strickland. --------------------------------------------------------------------------- If you believe that your system has been compromised, contact the CERT Coordination Center or your representative in the Forum of Incident Response and Security Teams (FIRST). If you wish to send sensitive incident or vulnerability information to CERT via electronic mail, CERT strongly advises that the e-mail be encrypted. CERT can support a shared DES key, PGP (public key available via anonymous FTP on info.cert.org), or PEM (contact CERT for details). Internet E-mail: cert@cert.org Telephone: 412-268-7090 (24-hour hotline) CERT personnel answer 8:30 a.m.-5:00 p.m. EST(GMT-5)/EDT(GMT-4), and are on call for emergencies during other hours. CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890 Past advisories, information about FIRST representatives, and other information related to computer security are available via anonymous FTP from info.cert.org. ======================================================================== Nelson H. F. Beebe Tel: +1 801 581 5254 Center for Scientific Computing FAX: +1 801 581 4148 Department of Mathematics, 105 JWB Internet: beebe@math.utah.edu University of Utah Salt Lake City, UT 84112, USA ======================================================================== 30-Apr-1994 11:23:09-GMT,33318;000000000001 Return-Path: Received: from math.ams.org by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA13297; Sat, 30 Apr 94 05:22:59 MDT Received: from csrj.crn.cogs.susx.ac.uk by MATH.AMS.ORG (PMDF #2306 ) id <01HBRZQ4O0YO8Y51DV@MATH.AMS.ORG>; Sat, 30 Apr 1994 07:00:20 EST Received: by csrj.crn.cogs.susx.ac.uk (Smail3.1.28.1 #44) id m0pxChR-00003QC; Sat, 30 Apr 94 11:55 BST Date: 30 Apr 1994 11:55 -0300 (BST) From: alanje@cogs.susx.ac.uk (Alan Jeffrey) Subject: LaTeX installation files To: tex-implementors@MATH.AMS.ORG Message-Id: Content-Transfer-Encoding: 7BIT Dear TeX implementors, As part of the full release of LaTeX2e, we would like to include documentation describing how LaTeX can be installed on as wide a variety of TeX platforms as possible. The details of these installation instructions may be very dependent on particular TeX implementations, so we would like to have as many of these files as possible maintained by experts in the TeX platform in question. We would be grateful for anyone who could take the time to prepare a SYSTEM.l2e file for inclusion in the full release of LaTeX2e, or who could provide any comments on the LaTeX installation procedure. Please find attatched the general LaTeX installation guide, plus a template for writing SYSTEM.l2e files, and a sample web2ctex.l2e installation guide for LaTeX under UNIX web2c TeX. NOTE: Some of the details of this installation are different from the current distribution. For example, the final release will produce a format file called latex.fmt, rather than latex2e.fmt, which is produced by the beta release. We hope to hear back from you, Alan Jeffrey (for the LaTeX3 project team) Alan Jeffrey Tel: +44 273 606755 x 3238 alanje@cogs.susx.ac.uk School of Cognitive and Computing Sciences, Sussex Univ., Brighton BN1 9QH, UK --- cut here for documentation --- % @TeX-file{ % date = "29 April 1994", % filename = "archive.tex", % docstring = "This is a self-extracting archive, containing: % install.l2e % texpert.l2e % othertex.l2e % template.l2e % web2ctex.l2e % They can be extracted by running TeX on this file." % } \def \gobble#1{} \def\checkchar#1#2{\ifnum`#1=#2\else\checkcharwarning{#1}{#2}\fi} \def\checkcharwarning#1#2{\immediate\write16 {Warning: ASCII #2 has been scrambled to character `\expandafter\gobble\string#1'. }} \checkchar{\@}{64} \checkchar{\#}{35} \checkchar{\$}{36} \checkchar{\%}{37} \checkchar{\^}{94} \checkchar{\&}{38} \checkchar{\*}{42} \checkchar{\_}{95} \checkchar{\{}{123} \checkchar{\}}{125} \checkchar{\[}{91} \checkchar{\]}{93} \checkchar{\<}{60} \checkchar{\>}{62} \checkchar{\\}{92} \checkchar{\/}{47} \immediate \write 16{} \immediate \write 16{This is a self-extracting archive, containing:} \message {install.l2e} \message {texpert.l2e} \message {othertex.l2e} \message {template.l2e} \message {web2ctex.l2e} \immediate \write 16{} \errhelp {Press RETURN to extract the files, or X to exit.} \errmessage {To extract these files, press RETURN.} \def \<#1\>{\immediate \write 1{#1}} \def \start(#1){\immediate \openout 1=#1 } \def \stop(#1){\immediate \closeout 1\immediate \write 16{File written on #1.}} \edef \\{\expandafter \gobble \string \\} \catcode `\{=12 \catcode `\}=12 \catcode `\~=12 \catcode `\@=12 \catcode `\#=12 \catcode `\$=12 \catcode `\%=12 \catcode `\^=12 \catcode `\&=12 \catcode `\_=12 \catcode `\|=12 \catcode `\{=12 \catcode `\}=12 \catcode `\[=12 \catcode `\]=12 \catcode `\<=12 \catcode `\`=12 \catcode `\'=12 \catcode `\ =12 \start(install.l2e) \< LaTeX Installation Guide \> \<\> \< 21 April 1994 \> \<\> \ \<======= \> \<\> \ \ \<\> \ \<\> \< * The available documentation. \> \<\> \< * How to find out about LaTeX with your version of TeX. \> \<\> \< * How the installation works. \> \<\> \< * What to do if anything goes wrong. \> \<\> \ \ \<\> \<\> \ \<============= \> \<\> \ \ \ \<\> \ \ \<\> \< * The LaTeX Companion, Goossens, Mittelbach and Samarin, Addison-Wesley \> \< ISBN 0-201-54199-8. \> \<\> \ \<\> \< * LaTeX: A Document Preparation System, Leslie Lamport, Addison-Wesley \> \<\> \<\> \ \<=================== \> \<\> \ \ \ \<\> \ \ \ \<\> \< * emtex.l2e for emTeX on the PC. \> \<\> \< * oztex.l2e for OzTeX on the Macintosh. \> \<\> \< * textures.l2e for Textures on the Macintosh. \> \<\> \< * web2ctex.l2e for web2c TeX on Unix platforms. \> \<\> \< * vmstex.l2e for VMS TeX on VAX platforms. \> \<\> \ \<\> \< * othertex.l2e for any other brand of TeX. \> \<\> \ \<\> \<\> \ \<========================== \> \<\> \ \<\> \< * Saving any old version of LaTeX. \> \<\> \< * Unpacking the distribution. \> \<\> \< * Creating the LaTeX format. \> \<\> \< * Putting the files where LaTeX can read them. \> \<\> \ \<\> \<\> \ \<------------------------------- \> \ \ \ \<\> \<\> \ \<-------------------------- \> \ \ \ \ \ \ \<\> \ \ \ \<\> \ \ \<\> \ \ \ \ \<\> \ \ \ \ \ \<\> \<\> \ \<------------------------- \> \ \ \ \<\> \ \ \ \<\> \<\> \ \<------------------------------------------- \> \ \ \ \<\> \< * the LaTeX inputs directory, which contains LaTeX files. \> \<\> \< * the MakeIndex inputs directory, which contains MakeIndex files. \> \<\> \ \<\> \< * latexbug.tex, testpage.tex and docstrip.tex. \> \<\> \ \<\> \< * .cls, document class files. \> \<\> \< * .clo, document class options files. \> \<\> \< * .sty, package files. \> \<\> \< * .fd, font definition files. \> \<\> \< * .def, files of definitions which may be read by LaTeX while \> \< processing documents. \> \<\> \< * .cfg, TeX expert configuration files. \> \<\> \ \ \<\> \< * .ist, MakeIndex style files. \> \<\> \ \<\> \<\> \ \<===================================== \> \<\> \ \ \ \<\> \ \ \<\> \ \<\> \<\> \ \<======== \> \<\> \ \ \<\> \<\> \<`texsys.cfg': While running iniTeX on latex2e.ltx you may get an error \> \< reporting a problem with texsys.cfg. \> \<\> \< If this happens then you have obtained (or produced) a texsys.cfg that \> \< is not suitable for your system. \> \<\> \< First, read the system.l2e file. This may tell you how to customize \> \< texsys.cfg \> \<\> \< If the system.l2e file does not mention texsys.cfg, then you should \> \< not need a texsys.cfg file. Try deleting texsys.cfg and building the \> \< LaTeX format again. \> \<\> \< If you still get errors, try running LaTeX on dircheck.dtx, and \> \< reading the resulting document. \> \<\> \<\> \<`File missing': Some of the files from the LaTeX distribution are \> \< missing. There are a number of possible reasons for this: \> \<\> \< * the files are missing. You should get the files from the same \> \< place you got the rest of the distribution. If you can't, you \> \< should complain to whoever gave you this distribution. \> \<\> \< * the files are present, but in the wrong directory. You should \> \< move the files to a directory iniTeX can read. \> \<\> \< * the files are present, and in the right directory. IniTeX may \> \< have been set up incorrectly. You may be able to correct this, \> \< depending on your TeX implementation. See the documentation of your \> \< TeX implementation for more details. \> \<\> \<\> \<`Font missing': Some of the fonts (.tfm files) required by LaTeX are \> \< missing. As above, either you have not got the required files, or \> \< iniTeX is not able to find them. So you may need to move them or to \> \< configure iniTeX to look in the correct places. See the documentation \> \< of your TeX implementation for more details. \> \<\> \<\> \<`Out of memory': On TeX implementations with small memory, you may \> \< exhaust iniTeX's memory whilst installing LaTeX. \> \<\> \< You may be able to correct this: \> \<\> \< * Some TeX implementations allow the amount of memory allocated \> \< to TeX to be increased. See the documentation of your TeX \> \< implementation for more details. \> \<\> \< * Some iniTeX implementations allow more memory than others; so \> \< you may be able to run iniTeX on a larger machine and then move \> \< the files across to the smaller machine. \> \<\> \< * If the error happened during the unpacking of the distribution \> \< (i.e. when you run iniTeX on unpack.ins) then try running this \> \< file with normal TeX, for example plain TeX or an old version \> \< of LaTeX. \> \<\> \<\> \ \<\> \< * read the system.l2e file; \> \<\> \< * if this fails, ask your local TeX guru; \> \<\> \< * if this fails, try asking a local TeX mailing list; \> \<\> \< * if this fails, run iniTeX on the file latexbug.tex, fill in the \> \< resulting bug report form, and send it to: \> \<\> \< latex-bugs@rus.uni-stuttgart.de \> \<\> \<\> \<--- Copyright 1994 the LaTeX3 project. --- \> \<--- All rights reserved. --- \> \<\> \stop(install.l2e) \start(texpert.l2e) \< LaTeX installation TeX expert information \> \<\> \< 21 April 1994 \> \<\> \<\> \ \<======= \> \<\> \ \ \<\> \< * The checks performed by ltxcheck.tex \> \<\> \< * How to print the LaTeX source. \> \<\> \< * How to configure the hyphenation patterns for LaTeX. \> \<\> \< * How to configure LaTeX's compatibility mode. \> \<\> \ \<\> \<\> \ \<======================= \> \<\> \ \<\> \<1) The \\@currdir check. \> \< It is useful for LaTeX to know the syntax for the `current directory \> \< (or folder)', or `default directory', if the operating system has \> \< such a concept. \> \<\> \< For example, file abc.tex in this directory, or folder, is specified \> \< by: \> \< ./abc.tex on unix and most DOS/OS2 TeX's, \> \< []abc.tex on VMS \> \< :abc.tex on a Macintosh. \> \< The above possibilities will be found automatically during the \> \< installation. However, if none of these syntaxes works on your \> \< system then the internal macro \\@currdir will be set to be empty \> \< and ltxcheck will report this. \> \<\> \< If your system does have a notion of a current directory, you can \> \< define \\@currdir in texsys.cfg. \> \<\> \< You could also report this to the latex-bug address, so that \> \< later releases can automatically cope with your system. \> \<\> \<2) The \\input@path check. \> \< On some systems TeX cannot check whether a file exists before \> \< trying to input it, unless the filename is expressed as a full path \> \< name, including the directory. On these systems LaTeX needs to be \> \< given a list of directories in which to look for files; the \> \< internal macro \\input@path holds this information. \> \<\> \< When run, ltxcheck will try to locate the file article.cls. \> \< If it fails to find this file (and you have placed it in the \> \< `standard input directory') then you must define \\input@path in \> \< texsys.cfg. \> \<\> \< The files texsys.cfg and dircheck.dtx contain examples of how to do \> \< this but only you know the directories and syntax that should be used \> \< for your installation. \> \<\> \< We hope to build up a better collection of examples in future \> \< releases of LaTeX2e, as it is tested on more TeX systems. \> \<\> \<3) TeX version check. \> \< The final checks test that you are running a recent version of TeX. \> \< If ltxcheck reports that you have TeX2, then you should try to \> \< upgrade TeX (and rebuild LaTeX) as soon as possible. LaTeX2e may be \> \< used with TeX2, but certain features will be missing and you will \> \< not be able to use the new (8-bit) font families that are now \> \< available. \> \<\> \< If ltxcheck reports that your TeX version is older than 3.141, you \> \< will see some strange messages during the installation. This is \> \< because earlier TeXs printed certain line-breaks in messages on the \> \< terminal as ^^J rather than starting a new line. \> \<\> \<\> \ \<========================= \> \<\> \ \ \ \ \<\> \ \ \ \<\> \< \\PassOptionsToClass{a4paper}{article} \> \<\> \ \ \ \ \ \<\> \ \<\> \< makeindex -s gind.ist FILENAME \> \< makeindex -s gglo.ist -o FILENAME.gls FILENAME.glo \> \<\> \<\> \ \<======================= \> \<\> \<*** THIS NEEDS WRITTEN! *** \> \<\> \<\> \ \<============================== \> \<\> \ \<\\documentclass, LaTeX assumes it is a LaTeX 2.09 document, and \> \ \<\> \< * sets a flag \\@compatibilitytrue \> \<\> \< * inputs the file latex209.def \> \<\> \< * inputs a file latex209.cfg if it exists. \> \<\> \ \ \ \ \ \ \ \<\> \<\> \<--- Copyright 1994 the LaTeX3 project. --- \> \<--- All rights reserved. --- \> \<\> \stop(texpert.l2e) \start(othertex.l2e) \< LaTeX installation instructions for unknown implementation \> \<\> \< 10 April 1994 \> \<\> \<\> \ \<======= \> \<\> \ \ \ \ \<\> \ \<\> \< * How to save any old version of LaTeX. \> \<\> \< * How to unpack the LaTeX distribution. \> \<\> \< * How to create the LaTeX format. \> \<\> \< * How to install the LaTeX files. \> \<\> \< * How to check the LaTeX installation. \> \<\> \< * What to do if the installation didn't work. \> \<\> \ \ \ \ \ \<\> \<\> \ \<=============================== \> \<\> \ \ \<\> \ \ \<\> \ \ \ \ \ \<\> \< * If the LaTeX inputs are separate from the other TeX inputs, then you \> \< should make a copy of the LaTeX inputs directory, and call it \> \< `latex209'. \> \<\> \< * If the LaTeX inputs are kept with the other TeX inputs, then you \> \< should create a new directory called `latex209', and copy any file \> \< ending with .sty from the LaTeX inputs directory into the latex209 \> \< directory. \> \<\> \ \ \ \<\> \< * The `latex209' format is used rather than `latex'. \> \<\> \< * The `latex209' directory is searched before the LaTeX inputs directory. \> \<\> \ \<\> \<\> \ \<========================== \> \<\> \ \<`unpack.ins'. The details of how to do this will depend on your TeX \> \ \<\> \<\> \ \<========================= \> \<\> \ \<`latex.ltx' and save the resulting format file as `latex.fmt' in the TeX \> \ \<`latex', or a `LaTeX' option to your TeX implementation. The details of \> \ \<\> \<\> \ \<=========================================== \> \<\> \ \ \<\> \< latexbug.tex testpage.tex docstrip.tex. \> \<\> \ \<\> \< .cls .clo .sty .fd .def .cfg \> \<\> \ \ \<\> \< gind.ist gglo.ist \> \<\> \ \<\> \<\> \ \<===================================== \> \<\> \ \ \ \ \<\> \<\> \ \<======== \> \<\> \ \ \ \<\> \ \<`PROBLEMS' section in install.l2e. \> \<\> \<\> \<--- Copyright 1994 the LaTeX3 project --- \> \<--- All rights reserved. --- \> \<\> \stop(othertex.l2e) \start(template.l2e) \< \> \<\> \< This file contains a template for system.l2e files. If you want to \> \< write a system.l2e file for your TeX implementation, then this is a \> \< good place to start! \> \<\> \< All of the places where you can add customization are indicated by a \> \< tag like . The tags are: \> \<\> \< ... This material is intended for the author of a \> \< system.l2e file. Please delete it before showing it to users! \> \<\> \< ... You may delete this material if you wish. \> \<\> \< ... Please write a description here. \> \<\> \< Replace this with the name of your TeX \> \< implementation, e.g. `FooTeX v1.4'. \> \<\> \< Replace this with today's date, e.g. `1 April 1994'. \> \<\> \< Replace this with the current year, e.g. `1994'. \> \<\> \< Replace this with your name, e.g. `Jane Doe'. \> \<\> \< Remember, a lot of users won't bother reading install.l2e, they'll \> \< just be reading this file! \> \<\> \< If you'd like to distribute this file to other users of your TeX \> \< implementation, please EMail it to latex-bugs@rus.uni-stuttgart.de. \> \<\> \< \> \<\> \< LaTeX installation instructions for \> \<\> \< \> \<\> \<\> \ \<======= \> \<\> \ \<. Before reading this file, you should read \> \ \<\> \ \<\> \< * How to save any old version of LaTeX. \> \<\> \< \> \< * How to configure LaTeX. \> \< \> \<\> \< * How to unpack the LaTeX distribution. \> \<\> \< * How to create the LaTeX format. \> \<\> \< * How to install the LaTeX files. \> \<\> \< \> \< * What to do if you have any problems. \> \< \> \<\> \< \> \< * Name any system-specific sections, e.g. `Running LaTeX with FooTeX v \> \< 1.2 or older'. These should appear as sections below! \> \< \> \<\> \<\> \ \<=============================== \> \<\> \ \ \<\> \< \> \< Describe how to save the old format as `latex209.fmt' and the old \> \< inputs in a directory called `latex209'. You might also describe how \> \< to run LaTeX2e and LaTeX 2.09 in parallel. \> \< \> \<\> \< \> \<\> \ \<================= \> \<\> \< \> \< Describe any configuration which has do be done. For example, LaTeX2e \> \< uses more memory than LaTeX 2.09, so you may need to tell users to \> \< increase one of TeX's memory parameters. \> \<\> \< If your TeX implementation requires a texsys.cfg file, you shold \> \< describe a sample one, and tell users to cut it out, edit it as \> \< appropriate, and save it as texsys.cfg. For example, under OzTeX 1.5, \> \< an appropriate example texsys.cfg file would be: \> \<\> \< \\def\\@currdir{:} \> \< \\def\\input@path{% \> \< {Hard-Disk:TeX:My-inputs}% \> \< {Hard-Disk:TeX:TeX-inputs}% \> \< } \> \<\> \< See dircheck.dtx and texpert.l2e for more details about texsys.cfg. \> \< \> \<\> \< \> \<\> \ \<========================== \> \<\> \< \> \< Describe how to run iniTeX on unpack.ins. This won't generate a .fmt \> \< file. \> \< \> \<\> \<\> \ \<========================= \> \<\> \< \> \< Describe how to run iniTeX on latex.ltx. This will generate a .fmt \> \< file, and you should tell users to put it in an appropriate \> \< directory. You may need to include some other system-specific \> \< instructions, e.g. editing CONFIG files or writing shell scripts. \> \< You may also want to show a sample texsys.cfg file. \> \< \> \<\> \<\> \ \<=========================================== \> \<\> \< \> \< Describe how to move the following files into a LaTeX inputs directory: \> \<\> \< latexbug.tex testpage.tex docstrip.tex. \> \< *.cls *.clo *.sty *.fd *.def *.cfg \> \<\> \< and put *.ist in a MakeIndex inputs directory. \> \< \> \<\> \<\> \ \<===================================== \> \<\> \< \> \< Describe how to run LaTeX (yes, some users may not have run LaTeX \> \< before!) on ltxcheck.tex. Say that it's going to produce some `OK' \> \< messages, and perhaps some `BAD' warnings. \> \< \> \<\> \< \> \<\> \ \<======== \> \<\> \< \> \< Describe any problems users may come across in this TeX \> \< implementation, and clues on how to cure them! Try copying the style \> \< of the `PROBLEMS' section in install.l2e. \> \< \> \<\> \ \<`PROBLEMS' section in install.l2e. \> \<\> \< \> \<\> \<\> \< \> \<\> \< SYSTEM-SPECIFIC SECTIONS \> \< ======================== \> \<\> \< Put any other system-specific material here, e.g. `How to install \> \< LaTeX with versions of FooTeX older than 1.2'. \> \<\> \< \> \<\> \<\> \<--- Copyright and the LaTeX3 project --- \> \<--- All rights reserved. --- \> \<\> \stop(template.l2e) \start(web2ctex.l2e) \< LaTeX installation instructions for web2c Unix TeX \> \<\> \< 18 April 1994 \> \<\> \<\> \ \<======= \> \<\> \ \ \ \<\> \ \<\> \< * How to save any old version of LaTeX. \> \<\> \< * How to unpack the LaTeX distribution. \> \<\> \< * How to create the LaTeX format. \> \<\> \< * How to install the LaTeX files. \> \<\> \ \ \<\> \ \ \<\> \< setenv LATEXINPUTS /usr/local/lib/tex/inputs/latex \> \<\> \ \ \<\> \< setenv LATEXFORMATS /usr/local/lib/tex/formats \> \<\> \ \ \<\> \< setenv LATEXBIN /usr/local/bin \> \<\> \ \ \<\> \< setenv LATEXDIST /usr/local/lib/tex/latex/src \> \<\> \<\> \ \<=============================== \> \<\> \ \ \<\> \ \<\> \< cd $LATEXFORMATS \> \< mv latex.fmt latex209.fmt \> \<\> \ \ \ \<\> \< cd $LATEXINPUTS \> \< mkdir ../latex209 \> \< cp *.sty ../latex209 \> \<\> \ \<\> \< cd $LATEXINPUTS \> \< mkdir ../latex209 \> \< cp * ../latex209 \> \<\> \ \ \<\> \< #!/bin/sh \> \< TEXINPUTS=${LATEX209INPUTS:- \\ \> \< .:/usr/local/lib/tex/inputs/latex209:$TEXINPUTS} \> \< export TEXINPUTS \> \< virtex \\&latex209 $* \> \<\> \<\> \ \<========================== \> \<\> \ \<\> \< cd $LATEXDIST \> \< initex unpack.ins \> \<\> \ \<\> \<\> \ \<========================= \> \<\> \ \<\> \< initex latex.ltx \> \<\> \ \<\> \< mv latex.fmt $LATEXFORMATS \> \<\> \ \ \<\> \< cd $LATEXBIN \> \< ln virtex latex \> \<\> \<\> \ \<=========================================== \> \<\> \ \<\> \< cd $LATEXDIST \> \< mv latexbug.tex testpage.tex docstrip.tex \\ \> \< *.cls *.clo *.sty *.fd *.def *.cfg \\ \> \< $LATEXINPUTS \> \<\> \ \<\> \<\> \ \<===================================== \> \<\> \ \<\> \< cd $LATEXDIST \> \< latex ltxcheck \> \<\> \ \<\> \<\> \<--- Copyright 1994 the LaTeX3 project. --- \> \<--- All rights reserved. --- \> \<\> \<\> \stop(web2ctex.l2e) \catcode`\ =12 \ifx\LaTeX\isanundefinedcontrolsequence \expandafter\end \else \makeatletter\expandafter\@@end \fi 15-Jun-1994 11:02:09-GMT,2105;000000000001 Return-Path: Received: from math.ams.org by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA19720; Wed, 15 Jun 94 05:01:59 MDT Received: from ra.cs.umb.edu by MATH.AMS.ORG (PMDF #2306 ) id <01HDK7WZAA4GA3CP1J@MATH.AMS.ORG>; Wed, 15 Jun 1994 06:25:22 EST Received: by ra.cs.umb.edu id AA13557 (5.65c/IDA-1.4.4 for tex-implementors@math.ams.org); Wed, 15 Jun 1994 06:25:07 -0400 Date: 15 Jun 1994 06:25:07 -0400 From: "K. Berry" Subject: ^^M implementation To: tex-implementors@MATH.AMS.ORG Message-Id: <199406151025.AA13557@ra.cs.umb.edu> Content-Transfer-Encoding: 7BIT Oren, Barbara, and I have been discussing a possible change to BibTeX's style files so that the generated bbl files will have a header at the beginning saying that they were generated, etc. I suggested the best format-independent ``comment'' character to use is ^^M (that's three printable ASCII characters). plain (and initex itself) gives this character catcode 5 (end of line), and no format I know of redefines it. That is, redefines it in general; of course, just about everything redefines ^^M for the purposes of ``example'' environment, but that doesn't matter here. Also of course ^^M can't be used as a comment character in general, but we're just talking about header comments at the beginning of the file, when TeX is definitely in vertical mode. The point to using ^^M instead of % is that Texinfo (and other undistributed formats) make % into a normal character, which seems a reasonable thing to do. Although Texinfo doesn't have bibtex support now, I will probably add it eventually. In any case, we don't see any downside to using ^^M for this purpose. The TeXbook says implementations of TeX must ignore anything after ^^M (page 47), but the trip test doesn't check this. Barbara mentioned that a number of early implementations (e.g., the original TOPS-20 one) were buggy in this regard, and hence we should confirm with this list that all present implementations think ^^M this stuff is ignored really does ignore this stuff, and this just masticates into a single . 15-Jun-1994 12:36:29-GMT,1082;000000000001 Return-Path: <@aston.ac.uk:spqr@ftp.tex.ac.uk> Received: from math.ams.org by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA21285; Wed, 15 Jun 94 06:36:25 MDT Received: from sun2.nsfnet-relay.ac.uk by MATH.AMS.ORG (PMDF #2306 ) id <01HDKBPC3VGGA3CP30@MATH.AMS.ORG>; Wed, 15 Jun 1994 08:14:12 EST Received: from ftp.tex.ac.uk by email.aston.ac.uk with SMTP (PP) id <25772-0@email.aston.ac.uk>; Wed, 15 Jun 1994 13:10:04 +0100 Received: by ftp.tex.ac.uk (4.1/SMI-4.1) id AA12492; Wed, 15 Jun 94 12:06:18 GMT Date: 15 Jun 1994 12:06:18 +0000 (GMT) From: spqr@ftp.tex.ac.uk (Sebastian Rahtz) Subject: Re: ^^M implementation In-Reply-To: <199406151025.AA13557@ra.cs.umb.edu> Sender: spqr@ftp.tex.ac.uk To: kb@cs.umb.edu Cc: tex-implementors@MATH.AMS.ORG Message-Id: <9406151206.AA12492@ftp.tex.ac.uk> Content-Transfer-Encoding: 7BIT Via: uk.ac.aston; Wed, 15 Jun 1994 13:12:52 +0100 References: <199406151025.AA13557@ra.cs.umb.edu> but surely the ^^M is very open to being stripped out by over-clever dos/unix filters? why not use a TeX command like \bibcomment{...}? sebastian 15-Jun-1994 16:33:25-GMT,2585;000000000001 Return-Path: Received: from math.ams.org by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA23127; Wed, 15 Jun 94 10:33:06 MDT Received: from ifi.informatik.uni-stuttgart.de by MATH.AMS.ORG (PMDF #2306 ) id <01HDKF5LRJ0WA3CUI5@MATH.AMS.ORG>; Wed, 15 Jun 1994 09:54:12 EST Received: from azu.informatik.uni-stuttgart.de by ifi.informatik.uni-stuttgart.de with SMTP; Wed, 15 Jun 94 15:51:40 +0200 Received: by azu.informatik.uni-stuttgart.de; Wed, 15 Jun 94 15:51:40 +0200 Date: 15 Jun 1994 15:51:40 +0200 From: Bernd Raichle Subject: Re: ^^M implementation In-Reply-To: Sebastian Rahtz's message of 15 Jun 1994 12:06:18 +0000 (GMT) <9406151206.AA12492@ftp.tex.ac.uk> To: tex-implementors@MATH.AMS.ORG Message-Id: <9406151351.AA10823@azu.informatik.uni-stuttgart.de> Content-Transfer-Encoding: 7BIT on 15 Jun 1994 12:06:18 +0000 (GMT), spqr@ftp.tex.ac.uk (Sebastian Rahtz) said: spqr> but surely the ^^M is very open to being stripped out by over-clever spqr> dos/unix filters? why not use a TeX command like \bibcomment{...}? No, it doesn't get stripped out, because there's no Ctrl-M "in" the file, but a sequence of three characters `^', `^', `M'. Nonetheless as I understand the proposal, Karl says that the standard bbl-files will have a comment before the contents which looks like ^^M bibstyle = plain ^^M (C) ^^M \begin{thebibliography}{123} \bibitem .... \bibitem .... \bibitem .... \end{thebibliography} Karl wrote: > The point to using ^^M instead of % is that Texinfo (and other > undistributed formats) make % into a normal character, which seems a > reasonable thing to do. Although Texinfo doesn't have bibtex support > now, I will probably add it eventually. In any case, we don't see any > downside to using ^^M for this purpose. If Texinfo and any other format will have bibtex support using the standard bibtex styles they have to change the catcode of \ (e.g. Texinfo) and define macros for \begin, \bibitem, \end, .... if they aren't defined already before reading the bbl-file. ... and if they have to do this, it will be simple to change the catcode of `%' to allow comments before the bbl contents. Or the authors of these formats have to write their own bst-files creating bbl-files for their input conventions. Why do you want to use another comment character? Bernd Raichle PS: Btw, Texinfo changes the catcode of `^' to \active in its normal non-TeX environment (don't know if this is true for all Texinfo versions). 15-Jun-1994 17:44:43-GMT,4099;000000000000 Return-Path: Received: from math.ams.org by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA23854; Wed, 15 Jun 94 11:44:32 MDT Received: from math.utah.edu (csc-sun.math.utah.edu) by MATH.AMS.ORG (PMDF #2306 ) id <01HDKLEQHEZKA3CY3W@MATH.AMS.ORG>; Wed, 15 Jun 1994 12:51:37 EST Received: from silverfork.math.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA23277; Wed, 15 Jun 94 10:51:19 MDT Date: 15 Jun 1994 10:51:19 -0600 (MDT) From: "Nelson H. F. Beebe" Subject: Comment on proposed ^^M comment syntax for .bbl files To: tex-implementors@MATH.AMS.ORG Cc: beebe@math.utah.edu Message-Id: Content-Transfer-Encoding: 7BIT X-Us-Mail: "Center for Scientific Computing, University of Utah, Salt Lake City, UT 84112" X-Telephone: +1 801 581 5254 X-Fax: +1 801 581 4148 I must register opposition to the proposed ^^M comment syntax for .bbl files, which was suggested because TeXinfo, which normally uses @ instead of \ as the escape character, and @c instead of % as the comment starter symbol, may soon have BibTeX bibliography file support. The reason is simple: @Preamble{...}, and frequently, string values in author, title, note, and abstract fields, already contain TeX material, such as these examples from ftp://ftp.math.utah.edu/pub/tex/bib/epodd.bib: @Preamble{ "\input bibnames.sty " # "\input texnames.sty " # "\def \INSCRIPT {{\sc in\-script}}" # "\def \PIC {{\sc pic}}" # "\def \registered {$^{{\ooalign{\hfil\raise.07ex \hbox{\footnotesize R}\hfil\crcr \mathhexbox20D}}}$}" # "\def \trademark {$^{\hbox{\sc tm}}$}" # "\def \SceX {Sc\kern-.035em \lower.5ex\hbox{E}\kern-.125em X}" } author = "R. Arrabito and H. J{\"{u}}rgensen", abstract = "The Find command is a familiar mechanism for travelling round linear documents. In hypertext documents, on the other hand, the primary method of travel is by means of built-in links. The paper considers how a Find command can be integrated into a hypertext system. There are two main issues: \begin{itemize} \item What does it mean to search a hypertext document? \item Can the two methods of travel be integrated in such a way that the user does not become disoriented? \end{itemize} ", This material is generally usable with both TeX and LaTeX (the itemize environment in the abstract is an exception); its conversion to a format that TeXinfo can understand is non-trivial. I propose that % be retained as a comment character, and that TeXinfo's command to read a .bbl file be redefined to revert to % and \ for comments and escapes. That seems to be a much cleaner solution that maintains compatibility with TeX, LaTeX, and other software tools that process TeX files. I realize that the presence of more advanced TeX and LaTeX control sequences poses a problem for TeXinfo, which contains a tiny subset of their capability, on the grounds that it must be able to produce both typeset output, and on-line ASCII output. However, that in itself is a serious limitation of TeXinfo which prevents its use for most of the technical writing that I do. Obviously, if one is writing in TeXinfo format, bibliography entries will have to be edited to conform to the simpler capabilities of TeXinfo; even with excision of LaTeX environments, accents in personal names remain, and are unsupported in TeXinfo. ======================================================================== Nelson H. F. Beebe Tel: +1 801 581 5254 Center for Scientific Computing FAX: +1 801 581 4148 Department of Mathematics, 105 JWB Internet: beebe@math.utah.edu University of Utah Salt Lake City, UT 84112, USA ======================================================================== 23-Jun-1994 12:38:37-GMT,1925;000000000001 Return-Path: Received: from math.ams.org by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA25592; Thu, 23 Jun 94 06:38:28 MDT Received: from mail-relay.ja.net by MATH.AMS.ORG (PMDF #2306 ) id <01HDVIMQUZA8A3DN2R@MATH.AMS.ORG>; Thu, 23 Jun 1994 08:30:36 EST Date: 23 Jun 1994 13:30:00 -0300 (BST) From: CHAA006@VAX.RHBNC.AC.UK Subject: `undefined' function used in section 186 of TeX To: tex-implementors Reply-To: Philip Taylor Message-Id: <2300989E_000DF7E0.009806246CDBA3C4$29_1@UK.AC.RHBNC.VAX> Content-Transfer-Encoding: 7BIT Via: uk.ac.rhbnc.vax; Thu, 23 Jun 1994 13:30:07 +0100 Actually-To: Originally-To: $TEX-IMPLEMENTORS Originally-From: CHAA006 "Philip Taylor " Mailer: Janet_Mailshr V3.6b ( 8-APR-1994 18:36:11 ) Dear Colleagues -- In section 186 of TeX, DEK checks for a well-formed real by comparing an integer cast with 2^{20}. Under VAX/VMS, the pre-declared routine -undefined- may be used for this test. Under Alpha/VMS, however, -undefined- is `not yet implemented': what test do other Alpha/VMS implementors use at this point? Philip Taylor, RHBNC. -------- {Section 186} @x [12] check glue ratio for REALness arbitrary random value. The following code assumes that a properly formed nonzero |real| number has absolute value $2^{20}$ or more when it is regarded as an integer; this precaution was adequate to prevent floating point underflow on the author's computer. @y arbitrary random value. The following code uses the VAX/VMS predeclared routine |undefined|, which returns |true| if its argument is not a properly constituted |real| number. @d VAX_undefined==@= undefined@> @z {Section 186} @x if abs(mem[p+glue_offset].int)<@'4000000 then print("?.?") @y if VAX_undefined(mem[p+glue_offset].gr) then print("?.?") @z 18-Jul-1994 11:53:30-GMT,4664;000000000001 Return-Path: Received: from math.ams.org by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA12062; Mon, 18 Jul 94 05:53:25 MDT Received: from uu3.psi.com by MATH.AMS.ORG (PMDF #7286 ) id <01HEUD1GB468ATKH69@MATH.AMS.ORG>; Mon, 18 Jul 1994 07:08:14 EST Received: by uu3.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA10973 for ; Mon, 18 Jul 94 07:01:39 -0400 Received: from localhost by microprograms.com (5.65/3.2.083191-Micro Programs Inc.) id AA00607; Fri, 15 Jul 1994 08:50:36 -0400 Date: 15 Jul 1994 08:50:35 -0400 From: bob@microprograms.com Subject: Re: LaTeX installation files In-Reply-To: Your message of "30 Apr 94 11:55:00 -0300." To: alanje@cogs.susx.ac.uk (Alan Jeffrey) Cc: tex-implementors@MATH.AMS.ORG, bob@microprograms.com Message-Id: <9407181101.AA10973@uu3.psi.com> Content-Transfer-Encoding: 7BIT X-Mts: smtp Sorry to be so long in sending this to you. Since I cannot afford ftp, it took me a while to obtain a copy of latex2e. Here is the installation instructions for MicroTeX aka uTeX. This is the version of TeX developed by David Fuchs and marketed (chronologically) by Addison Wesley, ArborText, and --- now --- Micro Programs Inc. Bob Harris ================================== cut here ================================== LaTeX installation instructions for MicroTeX 15 July 1994 SUMMARY ======= This file contains instructions on how to install LaTeX for MicroTeX (uTeX). Before reading this file, you should read install.txt, which will explain how the LaTeX installation works. This file describes: * How to save any old version of LaTeX. * How to unpack the LaTeX distribution. * How to create the LaTeX format. * How to create latex.exe * How to install the LaTeX files. These instructions assume that you are using the standard directory set up supplied by the MicroTeX distribution. We hope that, if your system's set up differs from this then you will be sufficiently familiar with your system to make the necessary amendments to these instructions. SAVING ANY OLD VERSION OF LATEX =============================== If you have a copy of LaTeX 2.09, you may wish to save it before installing the new LaTeX. You should make a subdirectory called latex209 in the MicroTeX directory. Then copy any files called *.sty from the TeX inputs directory (normally arbortxt\inputs) into this latex209 subdirectory. You should also rename the LaTeX format file which you use for LaTeX 2.09, usually lplain.fmt, to latex209.fmt. Finally, rename the current executable version of latex in \arborxt\bin to latex209.exe You should then create a batch file latex209.bat, which temporarily resets the TEXINPUT environment variable to a path which includes the latex209 subdirectory before the TeX inputs directory, and then calls latex209.exe. Check that this batch file works before proceeding. UNPACKING THE DISTRIBUTION ========================== To unpack the LaTeX distribution, you should change to the directory reserved for the installation and run iniTeX on the file unpack.ins by typing: initex unpack.ins CREATING THE LATEX FORMAT ========================= To create the LaTeX format, you should run iniTeX on the file latex.ltx by typing: initex latex.ltx \dump This will create a file latex.fmt. You should copy this to the directory where TeX looks for its format files, normally the formats subdirectory of arbortxt. CREATING THE LATEX PROGRAM Finally, create latex.exe by typing: preload < mklatex.dat PUTTING THE FILES WHERE LATEX CAN READ THEM =========================================== You should move the following files to the TeX inputs directory (usually arbortxt\inputs): latexbug.tex testpage.tex docstrip.tex *.cls *.clo *.sty *.fd *.def *.cfg If you use the MakeIndex program (called makeindx.exe) then you should also move the *.ist files into the inputs directory. CHECKING THAT THE INSTALLATION WORKED ===================================== You should now run LaTeX on ltxcheck.tex. This should produce a number of `OK' messages. If it produces any warnings, please consult the `Problems' section of the file install.txt. PROBLEMS ======== initex requires more conventional memory than does plain tex or latex. If either of the two steps above that use initex fail, try temporarily unloading any TSR programs or unnecessary device drivers until you have created the .fmt file. --- Copyright 1994 Micro Programs Inc and the LaTeX3 project --- --- All rights reserved. --- 18-Jul-1994 15:47:46-GMT,2711;000000000001 Received: from math.ams.org by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA13601; Mon, 18 Jul 94 09:47:41 MDT Return-Path: mackay@MATH.AMS.ORG Received: from june.cs.washington.edu by MATH.AMS.ORG (PMDF #7286 ) id <01HEULT4YD9CATKGPQ@MATH.AMS.ORG>; Mon, 18 Jul 1994 11:19:37 EST Received: (mackay@localhost) by june.cs.washington.edu (8.6.9/7.2ju) id IAA02739; Mon, 18 Jul 1994 08:18:45 -0700 Date: 18 Jul 1994 08:18:45 -0700 From: mackay@cs.washington.edu (Pierre MacKay) Subject: Re: LaTeX installation files To: alanje@cogs.susx.ac.uk, bob@microprograms.com Cc: tex-implementors@MATH.AMS.ORG Message-Id: <199407181518.IAA02739@june.cs.washington.edu> Content-Transfer-Encoding: 7BIT In my experience, on Unix, latex.ltx supplies the \dump command internally (which means that LaTeX3 is intended to allow NO add-on options in the dumped format. (Not too bad. since you can still dump over the top of a predumped format.) I don't suppose the presence of a redundant \dump command does any harm, but it may be confusing in some environments. %=======================================================================% | N O T I C E | | The University of Washington has ordered us to close the Northwest | | Computing Support Center, and to terminate the official support | | of UnixTeX. Although the termination was final as of June 14, 1994 | | we will try unofficially to provide some services for the next few | | months. Unfortunately Elizabeth will not be available by phone, | | and I cannot be near my phone in any regular sense. Please note | | the changes in address and telephone number. There is no Northwest | | Computing Support Center any longer. | | | %=======================================================================% Email concerned with UnixTeX distribution software may be sent to: UnixTeX@u.washington.edu Elizabeth Tachikawa or to: mackay@cs.washington.edu Pierre A. MacKay Smail: Department of Classics Emeritus Druid for Denny Hall, Mail Stop DH-10 Unix-flavored TeX University of Washington Seattle, WA 98195 (206) 543-2268 (No call forwarding, no message recorder) North American academic institutions have been taken over by MBA bean-counters and genuine or wannabe industry CEOs. Just when American industry is beginning to doubt the wisdom of autocratic pyramidal dictatorship, most American Universities have adopted that style of management, which is nice for refugees from defense industry boardrooms, but rather sickening for the rest of us. 11-Aug-1994 14:31:46-GMT,1602;000000000001 Return-Path: Received: from math.ams.org by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA19276; Thu, 11 Aug 94 08:31:42 MDT Received: from mail-relay.ja.net by MATH.AMS.ORG (PMDF #7286 ) id <01HFS2QFFIWGB141BL@MATH.AMS.ORG>; Thu, 11 Aug 1994 10:19:58 EST Date: 11 Aug 1994 15:18:31 -0300 (BST) From: CHAA006@VAX.RHBNC.AC.UK Subject: Patgen To: tex-implementors Reply-To: Philip Taylor Message-Id: <210022C6_001D2068.00982CB4B3AA8872$19_1@UK.AC.RHBNC.VAX> Content-Transfer-Encoding: 7BIT Via: uk.ac.rhbnc.vax; Thu, 11 Aug 1994 15:19:34 +0100 Actually-To: Originally-To: $TEX-IMPLEMENTORS Originally-From: CHAA006 "Philip Taylor " Mailer: Janet_Mailshr V3.6b ( 8-APR-1994 18:36:11 ) Bu courtesy of Christian Spieler, I now have an Alpha/VMS version of Patgen which is capable of processing the British hyphenation patters. But unlike the version referred to in Frank Liang's thesis, this one requires to be told (for each pass) hyph_start, hyph_finish, pat_start and pat_finish. Suggested values from Dominik Wujastyk (plus good, bad and threshold) are 1 1 2 4 1 2 20 2 2 2 4 2 1 8 3 3 2 5 1 4 7 4 4 2 6 3 2 1 5 5 2 8 1 * 4 (where * = infinity) I would _very_ much appreciate an explanation of the significance of the hyph_ and pat_ parameters. (And of course, if anyone has a real rationale for the derivation of the good, bad and threshold values, that would be most interesting as well!). Philip Taylor, RHBNC. 10-Oct-1994 19:42:29-GMT,967;000000000001 Return-Path: Received: from vax02.ams.org by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA26227; Mon, 10 Oct 94 13:42:26 MDT Received: from inet-gw-1.pa.dec.com by MATH.AMS.ORG (PMDF #7286 ) id <01HI46KUTC7KD08RU6@MATH.AMS.ORG>; Mon, 10 Oct 1994 15:16:29 EST Received: from lilac.pa.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94) id AA07693; Mon, 10 Oct 94 12:11:28 -0700 Received: by lilac.pa.dec.com; id AA02373; Mon, 10 Oct 94 12:11:27 -0700 Date: 10 Oct 1994 12:11:27 -0700 From: lamport@src.dec.com Subject: semantic nest size To: TEX-IMPLEMENTORS@MATH.AMS.ORG Message-Id: <9410101911.AA02373@lilac.pa.dec.com> Content-Transfer-Encoding: 7BIT X-Mts: smtp I've been running TeX out of semantic nest size lately with a set of macros for writing structured proofs. All the Unix TeX's I've seen have had semantic nest size set to 40. I suggest that the default be changed to 80 or 100 in the standard distributions. Leslie Lamport 23-Nov-1994 17:13:05-GMT,1720;000000000001 Return-Path: Received: from vax02.ams.org by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA22233; Wed, 23 Nov 94 10:12:57 MST Received: from mail-relay.ja.net by MATH.AMS.ORG (PMDF #7286 ) id <01HJTDXYG37KEBQ5P1@MATH.AMS.ORG>; Wed, 23 Nov 1994 10:46:18 EST Date: 23 Nov 1994 15:45:39 -0300 (BST) From: CHAA006@VAX.RHBNC.AC.UK Subject: \openin has global semantics To: tex-implementors Reply-To: Philip Taylor Message-Id: <2023ACD5_000DF7E0.00987E71B9FB99FA$23_1@UK.AC.RHBNC.VAX> Content-Transfer-Encoding: 7BIT Via: uk.ac.rhbnc.vax; Wed, 23 Nov 1994 15:45:39 +0000 Actually-To: Originally-To: $TEX-IMPLEMENTORS Originally-From: CHAA006 "Philip Taylor " Mailer: Janet_Mailshr V3.6b ( 8-APR-1994 18:36:11 ) I can nowhere find in the TeXbook a statement that \openin is implicitly global, yet every TeX that I have seems to treat it as such. Is this a failure on my part to interpret the TeXbook correctly, or a genuine b@g? Philip Taylor, RHBNC -------- \newread \zero \newwrite \one \newwrite \two \immediate \openout \one = one.tex \immediate \write \one {one} \immediate \closeout \one \immediate \openout \two = two.tex \immediate \write \two {two} \immediate \closeout \two \openin \zero = one.tex \begingroup \openin \zero = two.tex \endgroup \read \zero to \buffer \message {\noexpand \buffer: \meaning \buffer} \end This is TeX, Version 3.1415a [PD VMS 3.4] (preloaded format=plain 94.3.4) 23 NOV 1994 15:41 **TEST (DISK14:[CHAA.006]TEST.TEX;33 \zero=\read0 \one=\write0 \two=\write1 \buffer : macro:->two ) No pages of output. 23-Nov-1994 19:13:02-GMT,2742;000000000001 Received: from vax02.ams.org by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA23768; Wed, 23 Nov 94 12:12:59 MST Return-Path: mackay@MATH.AMS.ORG Received: from june.cs.washington.edu by MATH.AMS.ORG (PMDF #7286 ) id <01HJTK2UDA7KEBQ07T@MATH.AMS.ORG>; Wed, 23 Nov 1994 13:41:15 EST Received: (mackay@localhost) by june.cs.washington.edu (8.6.9/7.2ju) id KAA07351; Wed, 23 Nov 1994 10:39:31 -0800 Date: 23 Nov 1994 10:39:31 -0800 From: mackay@cs.washington.edu (Pierre MacKay) Subject: Re: \openin has global semantics In-Reply-To: CHAA006@VAX.RHBNC.AC.UK's message of 23 Nov 1994 15:45:39 -0300 (BST) <2023ACD5_000DF7E0.00987E71B9FB99FA$23_1@UK.AC.RHBNC.VAX> To: P.Taylor@Vax.Rhbnc.Ac.Uk Cc: tex-implementors@MATH.AMS.ORG Message-Id: <199411231839.KAA07351@june.cs.washington.edu> Content-Transfer-Encoding: 7BIT \openin is not specifically declared to be a "primitive" because in is really not a typesetting primitive, but rather an auxiliary command. I suppose it could have been emphasized that it is intrinsically global, but I think it is pretty obvious that it has to be. The IO channels 1-15 have to be hardwired into the compilation in virtually all OSs, and the notion of channel 2 being different from \begingroup channel 2 \endgroup makes my head swim. How would the file control structures know which stream to monitor. IO is a scruffy business at best. I guess DEK just assumed that the limitations (which were certainly pretty absolute at the time) on managing multiple IO channels were to obvious to need emphasis. %=======================================================================% | N O T I C E | | The University of Washington has ordered us to close the Northwest | | Computing Support Center, and to terminate the official support | | of UnixTeX. Although the termination was final as of June 14, 1994 | | I will continue unofficially to provide tape distributions and | | any other services I can. Although I cannot be near my phone on any | | regular schedule, I now have an answering machine. Please note | | the changes in address and telephone number. There is no Northwest | | Computing Support Center any longer. | | | %=======================================================================% Email concerned with UnixTeX distribution software may be sent To: mackay@cs.washington.edu Pierre A. MacKay Smail: Department of Classics Emeritus Druid for Denny Hall, Mail Stop DH-10 Unix-flavored TeX University of Washington Seattle, WA 98195 (206) 543-2268 (Message recorder now available) 15-Dec-1994 20:14:25-GMT,1751;000000000001 Return-Path: Received: from vax02.ams.org by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA20020; Thu, 15 Dec 94 13:14:18 MST Received: from netcom12.netcom.com by MATH.AMS.ORG (PMDF #7286 ) id <01HKODASEGNKEWWYVS@MATH.AMS.ORG>; Thu, 15 Dec 1994 15:02:08 EST Received: by netcom12.netcom.com (8.6.9/Netcom) id MAA11762; Thu, 15 Dec 1994 12:01:52 -0800 Date: 15 Dec 1994 12:01:51 -0800 (PST) From: kinch@netcom.com (Richard J. Kinch) Subject: Bug in cmbx5 and cmbx6 To: tex-implementors@MATH.AMS.ORG Message-Id: <199412152001.MAA11762@netcom12.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: ELM [version 2.4 PL23] Content-Length: 1022 I believe there is a latent bug in Computer Modern cmbx5 and cmbx6. The meta-ness seems to degenerate at the 5-point optical size used in cmbx5. For example, digit "7" grows a wart on top, and serifs on glyphs like A, K, M, N, U, V, W, X, Y, and others are notched in the inside corners. The "7" problem is clearly visible at 300 dpi when magnified to cmbx5 at 37.15pt. The serif notching is not evident except at even larger magnifications. At normal size at 300 or 600 this is not necessarily visible. In C&T Volume E (Computer Modern Typefaces) on page 560 there is a sample of cmbx5. Under a 10x lens or so you can see extra ink on the top of the digit "7". I believe there is a one- or two-pixel wart on top of "7" in the cmbx6 sample, too. The problems are evident in proof-size printouts. I discovered this in converting the METAFONT shapes to Bezier outlines with my automatic converter, METAFOG. I saw the misshapen glyphs and puzzled for days thinking I had a bug in my converter. Richard Kinch 11-Jan-1994 14:21:21-GMT,1475;000000000001 Return-Path: Received: from vs3002.ams.org by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA07116; Tue, 11 Jan 94 07:21:15 MST Received: from taptet.sscl.uwo.ca by MATH.AMS.ORG (PMDF #2306 ) id <01H7JULHBOG0PBI0KR@MATH.AMS.ORG>; Tue, 11 Jan 1994 09:12:27 EST Date: 11 Jan 1994 09:15:47 -0500 (EST) From: Chet Creider Subject: explanation of "Improper setbox" error message in 3.141 To: tex-implementors@MATH.AMS.ORG Message-Id: <9401111415.AA16786@taptet.sscl.uwo.ca> Content-Transfer-Encoding: 7BIT I would be very grateful for an explanation of why tex was changed between 3.14 and 3.141 such that common (at least to linguists, but I would think also for mathematicians) diacritic combinations such as \'{\c{o}} are disallowed (eliciting an Improper \setbox error and the followiing explanation (from tex.web): " Sorry, \setbox is not allowed ... between \accent and an accented character." This is extremely inconvenient and although fixes with sed scripts are possible (for some reason the reversed order \c{\'{o}} is all right), the only real solution is to back up to 3.14. Not very good to do in the long run. I would be very grateful if a design reconsideration could be made, but I suppose that is not likely for such a little thing (for me, however, it is not little as I'm editing a manuscript with something like 10,000 of these constructions). With thanks, Chet Creider 12-Jan-1994 2:05:25-GMT,4322;000000000001 Return-Path: Received: from vs3002.ams.org by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA21584; Tue, 11 Jan 94 19:03:18 MST Received: from ppsw1.cam.ac.uk (gray.csi.cam.ac.uk) by MATH.AMS.ORG (PMDF #2306 ) id <01H7KHGY50Y8PBHYQZ@MATH.AMS.ORG>; Tue, 11 Jan 1994 20:07:42 EST Received: from phx.cam.ac.uk by ppsw1.cam.ac.uk with GB-CAM (PP-6.0) as ppsw.cam.ac.uk id <18057-0@ppsw1.cam.ac.uk>; Wed, 12 Jan 1994 01:07:16 +0000 Date: 12 Jan 1994 01:07:10 +0000 (GMT) From: Chris Thompson Subject: Re: [explanation of "Improper setbox" error message in 3.141] In-Reply-To: <9401111415.AA16786@taptet.sscl.uwo.ca> To: tex-implementors@MATH.AMS.ORG Cc: Chet Creider , Robert Hunt Message-Id: Content-Transfer-Encoding: 7BIT Chet Creider asks for an explanation of change 399 (tex82.bug numbering), applied in TeX 3.141, that introduced the error: Sorry, \setbox is not allowed after \halign in a display, or between \accent and an accented character. This was a fix for a bug discovered by Robert Hunt. (I cannot find its history in Barbara's numbered message sequence, by the way.) The problem is that \setbox, alone of the commands processed by |prefixed_command|, can leave the semantic nest at a different level when it returns. This is because the parsing occurs only up to the "{" in "\setbox0=\hbox{...}", a new horizontal (or vertical, for \vbox) mode level has been created, and notes left on the save stack to say what to do at "}" time: namely store the result in a specific box register, possibly \global'ly. In the two situations described in the message, TeX allows any number of "assignments" (via routine |do_assignments|, which calls |prefixed_command| as long as the next command is of the right sort). This allows things like changing TeX parameters that are acted on at closing-$$ time, in the first case, or changing font between an accent and the character it is applied to, in the second. But in both cases TeX expects the semantic nest (and current list) to be untouched by this process. If the commands included \setbox's, this wasn't true, and one could get various "This can't happen" errors. My recollection is that Robert discovered the math mode \halign situation first, and that we then found the \accent problem by inspection of the code. In TeX 3.14 or earlier, \'{\setbox0=\vbox{o}} (which is not so different from Chet's example) will generate ! This can't happen (vpack). \setbox 0=\vbox {o} \'#1->{\accent 19 #1 } <*> \'{\setbox0=\vbox{o}} I'm broken. Please show this to someone who can fix can fix Now Chet quite reasonably thinks that as \'{\c{o}} was apparently working in TeX 3.14, he shouldn't have to rewrite all the occurrences as \c{\'{o}} (which works because it is \' that uses \accent, and \c that uses \setbox). But it turns out that TeX manged to avoid disaster in this case only accidentally: effectively it was turning it into \c{\'{o}} internally (as an inspection of \showlists output will reveal). Here is what happened: \' is expanded to yield {\accent 19 \c{o}}. \accent reads the 19, remembers the accenting character, and then calls |do_assignments|. \c is expanded to yield \setbox0\hbox{o}...... |prefixed_command| parses up to the "\hbox{": it has created a new horizontal mode level and notes on the save stack. "o" isn't an assignment, so |do_assignments| returns to \accent processing, which is unaware of the change to the semantic nest. \accent sees the "o" and applies the accent to it, and adds the resulting construct to the current list: it thinks it is the original one, but actually it is the new one (luckily they are both horizontal lists!) The "}" terminates the new horizontal mode level, boxes the \'{o} that is in there, and puts it in \box0. The rest of the expansion of \c now creates the effect of \c{\'{o}}. I think that it would be really quite hard for TeX to identify the cases in which it can `get away' with a \setbox in this way! Chris Thompson Cambridge University Computing Service Internet: cet1@phx.cam.ac.uk JANET: cet1@uk.ac.cam.phx 12-Jan-1994 17:54:56-GMT,2093;000000000001 Return-Path: <@AWIUNI11.EDVZ.UNIVIE.AC.AT:A8131DAL@AWIUNI11.EDVZ.UNIVIE.AC.AT> Received: from vs3002.ams.org by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA04877; Wed, 12 Jan 94 10:52:43 MST Received: from AWIUNI11.EDVZ.UniVie.AC.AT (helios.edvz.univie.ac.at) by MATH.AMS.ORG (PMDF #2306 ) id <01H7LB48HI40PBI664@MATH.AMS.ORG>; Wed, 12 Jan 1994 10:16:30 EST Received: from AWIUNI11.EDVZ.UNIVIE.AC.AT by AWIUNI11.EDVZ.UniVie.AC.AT (IBM VM SMTP V2R2) with BSMTP id 3180; Wed, 12 Jan 94 16:15:53 MEZ Received: from AWIUNI11.EDVZ.UNIVIE.AC.AT (NJE origin A8131DAL@AWIUNI11) by AWIUNI11.EDVZ.UNIVIE.AC.AT (LMail V1.1d/1.7f) with BSMTP id 8997; Wed, 12 Jan 1994 16:15:50 +0100 Date: Wed, 12 Jan 94 16:10:19 MEZ From: Peter Schmitt Subject: Re: [explanation of "Improper setbox" error message in 3.141] In-Reply-To: Message of 12 Jan 1994 01:07:10 +0000 (GMT) from To: tex-implementors@MATH.AMS.ORG Cc: Chet Creider Message-Id: <01H7LB49B8PEPBI664@MATH.AMS.ORG> Content-Transfer-Encoding: 7BIT >Chet Creider asks for an explanation of change 399 (tex82.bug > >Now Chet quite reasonably thinks that as \'{\c{o}} was apparently >working in TeX 3.14, he shouldn't have to rewrite all the occurrences >as \c{\'{o}} (which works because it is \' that uses \accent, and \c >that uses \setbox). But it turns out that TeX manged to avoid disaster I cannot comment on implementational details but I have a suggestion: Instead of rewriting it should be possible to solve the problem on the macro level -- has this already be considered? Peter Schmitt a8131dal@awiuni11.edvz.univie.ac.at schmitt@awirap.bitnet ----------------------------------------------------------------------------- Institute of Mathematics Strudlhofgasse 4 University of Vienna A-1090 Wien Austria 12-Jan-1994 18:42:25-GMT,1985;000000000001 Return-Path: Received: from vs3002.ams.org by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA05944; Wed, 12 Jan 94 11:42:14 MST Received: from taptet.sscl.uwo.ca by MATH.AMS.ORG (PMDF #2306 ) id <01H7LHASGCM8PBI302@MATH.AMS.ORG>; Wed, 12 Jan 1994 13:13:39 EST Date: 12 Jan 1994 10:40:58 -0500 (EST) From: Chet Creider Subject: Re: [explanation of "Improper setbox" error message in 3.141] To: A8131DAL@AWIUNI11.EDVZ.UniVie.AC.AT Cc: tex-implementors@MATH.AMS.ORG Message-Id: <9401121540.AA19609@taptet.sscl.uwo.ca> Content-Transfer-Encoding: 7BIT > >Chet Creider asks for an explanation of change 399 (tex82.bug > > > >Now Chet quite reasonably thinks that as \'{\c{o}} was apparently > >working in TeX 3.14, he shouldn't have to rewrite all the occurrences > >as \c{\'{o}} (which works because it is \' that uses \accent, and \c > >that uses \setbox). But it turns out that TeX manged to avoid disaster > > I cannot comment on implementational details but I have a suggestion: > Instead of rewriting it should be possible to solve the problem on the > macro level -- has this already be considered? > > > Peter Schmitt a8131dal@awiuni11.edvz.univie.ac.at Chris Thompson's explanation has satisfied my intellectual curiousity, and sed has taken care of my practical problems. (I am almost certain as well that a rewrite of the macro for \c could solve the problem, but I haven't done this yet.) As someone from the `other side of the fence' in a certain sense (I am very fond of and a heavy user of troff and groff), I would like to thank the readers of tex-implementors@mat.ams.org for their kind interest and concern with my `Improper setbox' problem. Your expertise leaves me breathless as well! I hope there won't be a next time, but it seems to be in the nature of things that there will be, so let me sign off with `until next time': Until next time, Chet 12-Jan-1994 19:00:43-GMT,1985;000000000001 Return-Path: Received: from vs3002.ams.org by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA06083; Wed, 12 Jan 94 12:00:35 MST Received: from taptet.sscl.uwo.ca by MATH.AMS.ORG (PMDF #2306 ) id <01H7LBUQL88GPBI70E@MATH.AMS.ORG>; Wed, 12 Jan 1994 10:37:50 EST Date: 12 Jan 1994 10:40:58 -0500 (EST) From: Chet Creider Subject: Re: [explanation of "Improper setbox" error message in 3.141] To: A8131DAL@AWIUNI11.EDVZ.UniVie.AC.AT Cc: tex-implementors@MATH.AMS.ORG Message-Id: <9401121540.AA19609@taptet.sscl.uwo.ca> Content-Transfer-Encoding: 7BIT > >Chet Creider asks for an explanation of change 399 (tex82.bug > > > >Now Chet quite reasonably thinks that as \'{\c{o}} was apparently > >working in TeX 3.14, he shouldn't have to rewrite all the occurrences > >as \c{\'{o}} (which works because it is \' that uses \accent, and \c > >that uses \setbox). But it turns out that TeX manged to avoid disaster > > I cannot comment on implementational details but I have a suggestion: > Instead of rewriting it should be possible to solve the problem on the > macro level -- has this already be considered? > > > Peter Schmitt a8131dal@awiuni11.edvz.univie.ac.at Chris Thompson's explanation has satisfied my intellectual curiousity, and sed has taken care of my practical problems. (I am almost certain as well that a rewrite of the macro for \c could solve the problem, but I haven't done this yet.) As someone from the `other side of the fence' in a certain sense (I am very fond of and a heavy user of troff and groff), I would like to thank the readers of tex-implementors@mat.ams.org for their kind interest and concern with my `Improper setbox' problem. Your expertise leaves me breathless as well! I hope there won't be a next time, but it seems to be in the nature of things that there will be, so let me sign off with `until next time': Until next time, Chet 12-Jan-1994 19:00:51-GMT,5657;000000000001 Return-Path: Received: from VS3002.AMS.ORG by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AB06083; Wed, 12 Jan 94 12:00:46 MST Received: from MATH.AMS.ORG by MATH.AMS.ORG (PMDF #2306 ) id <01H7L5YQ5FHCP2R15G@MATH.AMS.ORG>; Wed, 12 Jan 1994 10:46:52 EST Date: 12 Jan 1994 10:46:39 -0500 (EST) From: bbeeton Subject: Re: [explanation of "Improper setbox" error message in 3.141] In-Reply-To: <01H7LB49B8PEPBI664@MATH.AMS.ORG> To: A8131DAL@AWIUNI11.EDVZ.UniVie.AC.AT Cc: tex-implementors@MATH.AMS.ORG, creider@taptet.sscl.uwo.ca Message-Id: <758389599.449825.BNB@MATH.AMS.ORG> Content-Transfer-Encoding: 7BIT Mail-System-Version: regarding \c{\'{o}}, it is well known by old-time texers that there has always been a prohibition on direct input of multiple accents on one character outside of math mode. i thought that this was explicit in the texbook, but when i look into my copy (admittedly still the first edition, and i haven't been diligent in posting errata and updates) all i find is this statement on p.54: (excerpted from the file texbook.tex; please observe that this is copyright) \ddanger Appendix B shows that plain \TeX\ handles most of the accents by using \TeX's ^|\accent| primitive. For example, |\'#1| is equivalent to |{\accent19 #1}|, where |#1| is the argument being accented. The general rule is that |\accent|\ puts an accent over the next character; the \ tells where that accent appears in the current font. The accent is assumed to be properly positioned for a character whose height equals the ^{x-height} of the current font; taller or shorter characters cause the accent to be raised or lowered, taking due account of the slantedness of the fonts of accenter and accentee. The width of the final construction is the width of the character being accented, regardless of the width of the accent. Mode-independent commands like font changes may appear between the accent number and the character to be accented, but grouping operations must not ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ intervene. If it turns out that no suitable character is present, the ^^^^^^^^^ accent will appear by itself as if you had said |\char|\ instead of\/ |\accent|\. For example, |\'{}| produces \'{}. the highlighted text covers the territory in question, i believe, although, to someone not familiar with the innards of tex, it certainly isn't crystal clear. i've had discussions on this with knuth, but at the moment can't find anything in writing. his belief is that languages that require more than one accent on particular letters should have fonts constructed explicitly for that purpose. this is an extension of his position that under-accents aren't handled in a more graceful manner for the same reason, and his justification is that designed accent-letter combinations usually look significantly better, i.e. more normal to a literate native, than piece accents. (nobody disagrees, but it's certainly more than a little inconvenient.) i'm quite sure that he didn't consider the requirements of linguistic transcription. i did discuss the matter of under-accents with him over a period of several years, and never managed to provide a convincing argument for an \underaccent primitive; i'm afraid that my failed attempts may have helped harden his position so that no one else was able later to obtain his agreement, even with better arguments than i could muster. here's the next double-danger paragraph from the same page: \ddanger It's important to remember that these conventions we have discussed for accents and special letters are not built into \TeX\ itself; they belong only to the plain \TeX\ format, which uses the Computer Modern fonts. Quite different conventions will be appropriate when other fonts are involved; format designers should provide rules for how to obtain accents and special characters in their particular systems. Plain \TeX\ works well enough when accents are infrequent, but the conventions of this chapter are by no means recommended for large-scale applications of \TeX\ to other languages. For example, a well-designed \TeX\ font for ^{French} might well treat accents as ligatures, so that one could |e'crire de cette manie`re nai"ve en franc/ais| without backslashes. (See the remarks about Norwegian in Chapter~8.) ^^{foreign languages} at the math society, we have implemented multiple accents with macros. here are several examples of "weird" accents, alone and in combination: % % both acute and under-dot \def \acudot#1{{\oalign{\accent19 #1\crcr\hidewidth.\hidewidth}}} % % both circumflex and under-dot \def \cfudot#1{{\oalign{\accent94 #1\crcr\hidewidth.\hidewidth}}} % Smashes repeated from AMS-TeX; PLAIN implements only full \smash . \newif\iftop@ \newif\ifbot@ \def\topsmash{\top@true\bot@false\smash@} \def\botsmash{\top@false\bot@true\smash@} \def\smash{\top@true\bot@true\smash@} \def\smash@{\relax\ifmmode\def\next{\mathpalette\mathsm@sh}% \else\let\next\makesm@sh\fi \next } \def\finsm@sh{\iftop@\ht\z@\z@\fi\ifbot@\dp\z@\z@\fi\box\z@} \def\smash@cc#1{\botsmash{\lower1ex\hbox{#1}}} % Under-accents designed, and normally used, as over-accents. \def \udr@cc#1#2{\ifmmode\udr@cc@{#1}{$#2$}\else\udr@cc@{#1}{#2}\fi} \def \udr@cc@#1#2{{\lineskiplimit\z@ \oalign{#2\crcr\hidewidth\smash@cc{#1}\hidewidth}}} \def \utilde#1{\udr@cc{\rm\char"7E}{#1}} \def \uarc#1{\udr@cc{\rm\char"15}{#1}} -- bb 12-Jan-1994 19:00:59-GMT,1985;000000000001 Return-Path: Received: from VS3002.AMS.ORG by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AB06083; Wed, 12 Jan 94 12:00:53 MST Received: from taptet.sscl.uwo.ca by MATH.AMS.ORG (PMDF #2306 ) id <01H7LD3ZJ3E8PBHV2H@MATH.AMS.ORG>; Wed, 12 Jan 1994 11:13:32 EST Date: 12 Jan 1994 10:40:58 -0500 (EST) From: Chet Creider Subject: Re: [explanation of "Improper setbox" error message in 3.141] To: A8131DAL@AWIUNI11.EDVZ.UniVie.AC.AT Cc: tex-implementors@MATH.AMS.ORG Message-Id: <9401121540.AA19609@taptet.sscl.uwo.ca> Content-Transfer-Encoding: 7BIT > >Chet Creider asks for an explanation of change 399 (tex82.bug > > > >Now Chet quite reasonably thinks that as \'{\c{o}} was apparently > >working in TeX 3.14, he shouldn't have to rewrite all the occurrences > >as \c{\'{o}} (which works because it is \' that uses \accent, and \c > >that uses \setbox). But it turns out that TeX manged to avoid disaster > > I cannot comment on implementational details but I have a suggestion: > Instead of rewriting it should be possible to solve the problem on the > macro level -- has this already be considered? > > > Peter Schmitt a8131dal@awiuni11.edvz.univie.ac.at Chris Thompson's explanation has satisfied my intellectual curiousity, and sed has taken care of my practical problems. (I am almost certain as well that a rewrite of the macro for \c could solve the problem, but I haven't done this yet.) As someone from the `other side of the fence' in a certain sense (I am very fond of and a heavy user of troff and groff), I would like to thank the readers of tex-implementors@mat.ams.org for their kind interest and concern with my `Improper setbox' problem. Your expertise leaves me breathless as well! I hope there won't be a next time, but it seems to be in the nature of things that there will be, so let me sign off with `until next time': Until next time, Chet 12-Jan-1994 19:06:06-GMT,1984;000000000001 Return-Path: Received: from vax01.ams.org by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA06290; Wed, 12 Jan 94 12:06:00 MST Received: from taptet.sscl.uwo.ca by MATH.AMS.ORG (PMDF #2306 ) id <01H7LF7D9HR4PBI3H1@MATH.AMS.ORG>; Wed, 12 Jan 1994 12:13:32 EST Date: 12 Jan 1994 10:40:58 -0500 (EST) From: Chet Creider Subject: Re: [explanation of "Improper setbox" error message in 3.141] To: A8131DAL@AWIUNI11.EDVZ.UniVie.AC.AT Cc: tex-implementors@MATH.AMS.ORG Message-Id: <9401121540.AA19609@taptet.sscl.uwo.ca> Content-Transfer-Encoding: 7BIT > >Chet Creider asks for an explanation of change 399 (tex82.bug > > > >Now Chet quite reasonably thinks that as \'{\c{o}} was apparently > >working in TeX 3.14, he shouldn't have to rewrite all the occurrences > >as \c{\'{o}} (which works because it is \' that uses \accent, and \c > >that uses \setbox). But it turns out that TeX manged to avoid disaster > > I cannot comment on implementational details but I have a suggestion: > Instead of rewriting it should be possible to solve the problem on the > macro level -- has this already be considered? > > > Peter Schmitt a8131dal@awiuni11.edvz.univie.ac.at Chris Thompson's explanation has satisfied my intellectual curiousity, and sed has taken care of my practical problems. (I am almost certain as well that a rewrite of the macro for \c could solve the problem, but I haven't done this yet.) As someone from the `other side of the fence' in a certain sense (I am very fond of and a heavy user of troff and groff), I would like to thank the readers of tex-implementors@mat.ams.org for their kind interest and concern with my `Improper setbox' problem. Your expertise leaves me breathless as well! I hope there won't be a next time, but it seems to be in the nature of things that there will be, so let me sign off with `until next time': Until next time, Chet 14-Jan-1994 1:39:59-GMT,789;000000000001 Received: from june.cs.washington.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA07008; Thu, 13 Jan 94 18:39:57 MST Return-Path: Received: from localhost (mackay@localhost) by june.cs.washington.edu (8.6.4/7.1ju+) id RAA08724; Thu, 13 Jan 1994 17:40:00 -0800 Date: Thu, 13 Jan 1994 17:40:00 -0800 From: mackay@cs.washington.edu (Pierre MacKay) Message-Id: <199401140140.RAA08724@june.cs.washington.edu> To: unixtex@u.washington.edu Cc: beebe@math.utah.edu In-Reply-To: Unix TeX distribution's message of Tue, 11 Jan 94 08:25:23 -0800 <9401111625.AA24313@stein1.u.washington.edu> Subject: Re: \setbox problem solved [creider@taptet.sscl.uwo.ca: Re: addendum to problem] Doubling the braces works. both \c{{\'o}} and \'{{\c{o}}} give the desired effect. 14-Jan-1994 1:58:13-GMT,1455;000000000001 Received: from vs3002.ams.org by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA07393; Thu, 13 Jan 94 18:58:09 MST Return-Path: mackay@MATH.AMS.ORG Received: from june.cs.washington.edu by MATH.AMS.ORG (PMDF #2306 ) id <01H7NB362C2OPBI843@MATH.AMS.ORG>; Thu, 13 Jan 1994 20:37:17 EST Received: from localhost (mackay@localhost) by june.cs.washington.edu (8.6.4/7.1ju+) id RAA08352; Thu, 13 Jan 1994 17:36:48 -0800 Date: 13 Jan 1994 17:36:48 -0800 From: mackay@cs.washington.edu (Pierre MacKay) Subject: Re: explanation of "Improper setbox" error message in 3.141 In-Reply-To: Chet Creider's message of 11 Jan 1994 09:15:47 -0500 (EST) <9401111415.AA16786@taptet.sscl.uwo.ca> To: creider@taptet.sscl.uwo.ca Cc: tex-implementors@MATH.AMS.ORG Message-Id: <199401140136.RAA08352@june.cs.washington.edu> Content-Transfer-Encoding: 7BIT We do not touch that part of TeX, so I can't understand why the change has occurred. We will look into it. Meanwhile, there is a fix that I have confirmed as working on my TeX3.141 \'{\c{o}} may not work but \'{{\c{o}}} does and so does \c{{\'o}} Email concerned with UnixTeX distribution software should be sent primarily to: UnixTeX@u.washington.edu Elizabeth Tachikawa otherwise to: mackay@cs.washington.edu Pierre A. MacKay Smail: Northwest Computing Support Center Resident Druid for Thomson Hall, Mail Stop DR-10 Unix-flavored TeX University of Washington Seattle, WA 98195 (206) 543-6259 28-Feb-1994 18:26:26-GMT,1394;000000000001 Return-Path: Received: from math.ams.org by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA25090; Mon, 28 Feb 94 11:26:13 MST Received: from sun2.nsfnet-relay.ac.uk by MATH.AMS.ORG (PMDF #2306 ) id <01H9F47HUCGW8Y5IWT@MATH.AMS.ORG>; Mon, 28 Feb 1994 12:50:43 EST Date: 28 Feb 1994 17:20:12 +0000 (GMT) From: CHAA006@VAX.RHBNC.AC.UK Subject: 2 queries: p/d change file for MFT (VAX/VMS), and utility DIFF -> .CH? To: tex-implementors Reply-To: Philip Taylor (RHBNC) Message-Id: <3620070B_00200A20.0097ABE689160E8C$34_1@UK.AC.RHBNC.VAX> Content-Transfer-Encoding: 7BIT Via: uk.ac.rhbnc.vax; Mon, 28 Feb 1994 17:20:24 +0000 Actually-To: Originally-To: $TEX-IMPLEMENTORS Mailer: Janet_Mailshr V3.5 ( 13-OCT-1989 14:07:27 ) Dear Colleagues -- I am currently bootstrapping a complete VAX/VMS TeX kit for the first time in many years, and would appreciate help on two points. (1)~Is anyone aware of a public-domain change file for MFT under VAX/VMS (I have only the K&S change file, and David Kellerman has indicated that he is not willing to allow it to enter the public domain), and (2)~is there available a utility for generating WEB .CH files from a DIFF listing (either VAX/VMS DIFFERENCES or one of the GNU DIFF programs)? Philip Taylor, RHBNC 9-Mar-1994 15:44:54-GMT,3253;000000000001 Return-Path: Received: from math.ams.org by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA18775; Wed, 9 Mar 94 08:44:47 MST Received: from MATH.AMS.ORG by MATH.AMS.ORG (PMDF #2306 ) id <01H9RJ8G39LC9I47EL@MATH.AMS.ORG>; Wed, 9 Mar 1994 10:26:31 EST Date: 09 Mar 1994 10:26:11 -0500 (EST) From: bbeeton Subject: [andrew.trevorrow@anu.edu.au (Andrew K Trevorrow): new TeX bug] To: tex-implementors@MATH.AMS.ORG Message-Id: <763226771.586965.BNB@MATH.AMS.ORG> Content-Transfer-Encoding: 7BIT Mail-System-Version: i've received the attached bug report from andrew trevorrow. please send comments back promptly; as soon as the problem has been verified, i'll forward it to knuth. (it's getting to be time for his annual tex-inspection tour.) thanks. -- bb -------------------- Date: 09 Mar 1994 16:59:50 -0500 (EST) From: andrew.trevorrow@anu.edu.au (Andrew K Trevorrow) To: bnb@MATH.AMS.ORG Subject: new TeX bug Hi Barbara, I think I've found a bug in TeX. Please pass on the following note to the TeX implementors to verify my analysis. ---------------- Over the last couple of years a few OzTeX users have reported a strange bug in which a character at the start of a word changes for no obvious reason. I was never able to reproduce the problem until the other day when Ole Michael Selberg sent me the vital clue: the problem only happens if font_mem_size is increased and the format file is NOT rebuilt. (OzTeX users don't have to recompile TeX to change font_mem_size; they simply edit a number in a configuration file.) Now font_mem_size is supposed to be one of the parameters that can differ in INITEX and VIRTEX. The problem is that non_address is set to font_mem_size, so when bchar_label[f] values are set to non_address and stored in a format file by INITEX they will not be recognized as non-address values by a VIRTEX that uses a different font_mem_size! Note that if font_mem_size in VIRTEX is smaller than the INITEX value then a fatal format error will occur when loading bchar_label[nullfont] (which was set to non_address by INITEX). If font_mem_size in VIRTEX is larger than the INITEX value then far nastier problems can occur, such as a character at the start of a word changing. One solution would be to treat font_mem_size like hash_size and the other parameters that require format files to be rebuilt if their values change. A better solution is to set non_address to -1; this allows font_mem_size to be different in INITEX and VIRTEX. Here are the changes needed to tex.web: @x @!font_index=0..font_mem_size; {index into |font_info|} @y @!font_index=-1..font_mem_size; {index into |font_info|} @z @x @d non_address==font_mem_size {a spurious |font_index|} @y @d non_address==-1 {a spurious |font_index|} @z @x if bchar_label[hf]non_address then {put left boundary at beginning of new line} @z @x undump(0)(font_mem_size)(bchar_label[k]); @y undump(non_address)(font_mem_size-1)(bchar_label[k]); @z I've included these changes in a new version of OzTeX and they fix the bug. Andrew Trevorrow akt150@huxley.anu.edu.au 9-Mar-1994 19:03:10-GMT,1331;000000000001 Return-Path: <@HEARN.nic.SURFnet.nl:WSULIVAN@IRLEARN.UCD.IE> Received: from math.ams.org by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA22405; Wed, 9 Mar 94 12:03:05 MST Received: from HEARN.nic.SURFnet.nl by MATH.AMS.ORG (PMDF #2306 ) id <01H9RPPPUEE88Y6LJ0@MATH.AMS.ORG>; Wed, 9 Mar 1994 13:16:29 EST Received: from IRLEARN.UCD.IE by HEARN.nic.SURFnet.nl (IBM VM SMTP V2R2) with BSMTP id 1971; Wed, 09 Mar 94 19:15:22 CET Received: from IRLEARN.UCD.IE (NJE origin WSULIVAN@IRLEARN) by IRLEARN.UCD.IE (LMail V1.2a/1.8a) with BSMTP id 9164; Wed, 9 Mar 1994 18:20:10 +0000 Date: 09 Mar 1994 18:10:36 +0000 (GMT) From: "Wayne G. Sullivan" Subject: font_mem_size To: tex-implementors@MATH.AMS.ORG Message-Id: <01H9RPPQULG28Y6LJ0@MATH.AMS.ORG> Content-Transfer-Encoding: 7BIT In order to qualify as a BUG of TeX, I believe it is necessary for the bug to be in tex.web. If TeX misbehaves because of a change file, it does not seem quite fair to blame DEK. I can find no place in tex.web where it is suggested that production versions of TeX should have a larger font_mem_size than that for INITEX. Actually it is a good idea, but anyone who implements such a change is responsible for checking that the changes introduced do not produce bugs. Wayne Sullivan 10-Mar-1994 10:16:56-GMT,2438;000000000001 Return-Path: Received: from math.ams.org by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA07505; Thu, 10 Mar 94 03:16:50 MST Received: from ifi.informatik.uni-stuttgart.de by MATH.AMS.ORG (PMDF #2306 ) id <01H9SLM66B008Y6O77@MATH.AMS.ORG>; Thu, 10 Mar 1994 04:29:49 EST Received: from azu.informatik.uni-stuttgart.de by ifi.informatik.uni-stuttgart.de with SMTP; Thu, 10 Mar 94 10:29:31 +0100 Received: by azu.informatik.uni-stuttgart.de; Thu, 10 Mar 94 10:29:16 +0100 Date: 10 Mar 1994 10:29:16 +0100 From: Bernd Raichle Subject: Re: font_mem_size In-Reply-To: "Wayne G. Sullivan"'s message of 09 Mar 1994 18:10:36 +0000 (GMT) <01H9RPPQULG28Y6LJ0@MATH.AMS.ORG> To: tex-implementors@MATH.AMS.ORG Message-Id: <9403100929.AA11762@azu.informatik.uni-stuttgart.de> Content-Transfer-Encoding: 7BIT on 09 Mar 1994 18:10:36 +0000 (GMT), "Wayne G. Sullivan" said: Wayne> In order to qualify as a BUG of TeX, I believe it is necessary for the Wayne> bug to be in tex.web. If TeX misbehaves because of a change file, it Wayne> does not seem quite fair to blame DEK. I can find no place in tex.web Wayne> where it is suggested that production versions of TeX should have a larger Wayne> font_mem_size than that for INITEX. The definition of the ``constant'' |font_mem_size| is in the section commented with @ The following parameters can be changed at compile time to extend or reduce \TeX's capacity. They may have different values in \.{INITEX} and ^^^^^^^^^^^^^^^^^^^^^^^^^ in production versions of \TeX. The bug in TeX.web is either that a) the (constant) value of |font_mem_size| is used to mark a |non_address| in the tfm info (array |bchar_label|) which is then saved in the format file (= bug in program code) or b) that the value of |font_mem_size| is allowed to have different values in IniTeX and VirTeX (= bug in documentation). Btw, if you want to make an implementation with user configurable sizes of the main mem, font mem, trie mem, etc., it is necessary to make the definition of |non_address| invariant of |font_mem_size| to allow a changeable size of the |font_info| array. (I know that this change is in the change files of emTeX and brTeX/PasTeX, but neither Eberhard nor myself have identified this as a bug in TeX.web :-(.) Bernd Raichle 10-Mar-1994 13:22:04-GMT,4776;000000000001 Return-Path: <71172.524@CompuServe.COM> Received: from math.ams.org by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA11757; Thu, 10 Mar 94 06:21:59 MST Received: from dub-img-1.compuserve.com by MATH.AMS.ORG (PMDF #2306 ) id <01H9ST70HYHC8Y6NG4@MATH.AMS.ORG>; Thu, 10 Mar 1994 08:07:12 EST Received: from localhost by dub-img-1.compuserve.com (8.6.4/5.930129sam) id IAA03987; Thu, 10 Mar 1994 08:05:50 -0500 Date: 10 Mar 1994 08:03:11 -0500 (EST) From: Berthold Horn <71172.524@CompuServe.COM> Subject: andrews bug et alia To: Peter Breitenlohner Cc: Barbara Beeton , TeX Implementirs , Andrew Trevorrow Message-Id: <940310130310_71172.524_DHQ25-1@CompuServe.COM> Content-Transfer-Encoding: 7BIT Dear Barbara (and Peter, Chris, Andrew, ...), > 2. berthold horns msg from Dec 17 > ad 2: non_address=max_halfword is probably OK as well, I have not checked > all implications. I prefer =0 and this has the definite advantage that it > does catch old formats that need to be rebuilt. (Having to rebuild formats > when the program changes - even if the pool checksum doesn't change - > is certainly ok.) Well, there is nothing wrong with using max_halfword for this that I can see (and it is in the spirit of using some `impossibly large' number) and I am *not* convinced that there aren't problems with using 0. But I'll be happy to change it if that in fact can be shown to be safe... > ad 3: that is entirely up to implementors, the 262144 never shows up in > tex.web. But bigTeX has to set some reasonable limit on the size of > the mem array otherwise a stupid paging system uses up enormous amounts of > paging space and non-paging systems are completely sunk. > Cetainly 256K is as good as any other number of the right size. Re: max_halfword. This is used mostly to (i) indicate invalid values (see above for example), and (ii) to limit how big various arrays *can* get. I don't see what this has to do with paging systems. Nothing is ever allocated of size max_halfword. I am *not* talking here about making a `bigg TeX'. However, note that a `dynamic' TeX *cannot* have max_halfword set to 262144, since it must allow things to get bigger than in current `big' TeX's (Many TeX jobs --- such as the `LaTeX Companion --- already now get close to the current limit, or have to split to avoid it --- so we will see more of this). > ad 4: It would be tempting to increase font_max once max_halfword and > max_quarterword have been increased. TeX uses at present only one-byte > font numbers in the DVI file, i.e., range 0..255. Clearly TeX's dvi writing > routines could certainly be adapted to a larger range, no problem here. > But: Extending this range may have implications on existing DVI software. > Some DVI drivers may rely on one-byte font numbers (re: driver standard?). > Therefore I would be very careful at this point!! Right, which is why it is time to upgrade the standards for DVI drivers! Presently the (level 0) standard is inconsistent in that on the one hand, the driver *must* support multi-byte font numbers, yet it need not support font numbers larger than 255. This is an urgent issue, since many jobs now are approaching the 255 limit --- such as the `LaTeX Companion', and some journals that Elsevier does. This is not to say that DVI drivers need to support that many fonts actually being used simultaneously --- just how large internal font numbers are allowed to get. > ad 1: I can't understand this problem. In VIRTEX mem_min must be <=mem_bot, > and mem_min>=min_halfword=null. Now mem_bot is a glue spec, hence can never > occur when traversing a list. If mem_min is mem_bot-1 or mem_bot-2 the one > or two extra words are never used and if mem_min is also never used (done in undump memory). Hence the word mem[mem_min] > is either a glue spec or unused. This can never give a problem > with tests such as p>mem_min when traversing lists. > It might be nicer to test for p<>null but I think this is no bug. > Maybe only don knows why he has formulated this one test in a different way, > but probably he forgotten the reasoning behind that. Believe me, this very definitely *is* a bug! Think about what happens when you extend the variable length node list downward. You can't very well then go back over all list structures and change `null' to the new `mem_min'! > A bug might creep in if someone is dynamically extending the mem array during > the run of VIRTEX and is not doing it properly (mimicking the behaviour of > undump). I would say any problems introduced here are due to improper sys-dep > modifications. Regards, Berthold. 10-Mar-1994 13:58:51-GMT,1521;000000000001 Return-Path: Received: from math.ams.org by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA11875; Thu, 10 Mar 94 06:58:45 MST Received: from ppsw1.cam.ac.uk (gray.csi.cam.ac.uk) by MATH.AMS.ORG (PMDF #2306 ) id <01H9STFM5FBK8Y6RFA@MATH.AMS.ORG>; Thu, 10 Mar 1994 08:13:37 EST Received: from phx.cam.ac.uk by ppsw1.cam.ac.uk with GB-CAM (PP-6.0) as ppsw.cam.ac.uk id <16895-0@ppsw1.cam.ac.uk>; Thu, 10 Mar 1994 13:13:00 +0000 Date: 10 Mar 1994 13:12:54 +0000 (GMT) From: Chris Thompson Subject: Re: font_mem_size To: tex-implementors@MATH.AMS.ORG Message-Id: Content-Transfer-Encoding: 7BIT I agree with Bernd Raichle (and with Peter Breitenlohner, according to e-mail received from him): there is no doubt that |font_mem_size| is meant to be among the parameters that can differ between INITeX and TeX, or between differently parameterised TeX's using the same format file. Bernd says that if this were in fact not the case, then the bug would be > b) that the value of |font_mem_size| is allowed to have different > values in IniTeX and VirTeX (= bug in documentation). To this one can add that if the value is not meant to change, then it should be dumped in the format file, like |eqtb_size|, |hash_prime| and so forth. The absence of this would be a bug (or at least, a serious infelicity) in the code. Chris Thompson Cambridge University Computing Service Internet: cet1@phx.cam.ac.uk JANET: cet1@uk.ac.cam.phx 10-Mar-1994 17:46:02-GMT,2798;000000000001 Return-Path: Received: from math.ams.org by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA14912; Thu, 10 Mar 94 10:45:54 MST Received: from MZDMZA.ZDV.UNI-MAINZ.DE (vzdmzd.zdv.Uni-Mainz.DE) by MATH.AMS.ORG (PMDF #2306 ) id <01H9T12DURSG8Y5O2A@MATH.AMS.ORG>; Thu, 10 Mar 1994 11:52:37 EST Received: from MZDMZA.ZDV.UNI-MAINZ.DE by MZDMZA.ZDV.UNI-MAINZ.DE (PMDF V4.2-11 #4432) id <01H9TDL16NOG8WWCOL@MZDMZA.ZDV.UNI-MAINZ.DE>; Thu, 10 Mar 1994 17:50:28 +0100 Date: 10 Mar 1994 17:50:28 +0100 From: Frank Mittelbach Subject: Re: font_mem_size To: tex-implementors@MATH.AMS.ORG Message-Id: <01H9TDL17Q9E8WWCOL@MZDMZA.ZDV.UNI-MAINZ.DE> X-Vms-To: IN"tex-implementors@MATH.AMS.ORG" X-Vms-Cc: MITTELBACH Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT To: IN%"tex-implementors@MATH.AMS.ORG" > Subj: [andrew.trevorrow@anu.edu.au (Andrew K Trevorrow): new TeX bug] > > > Now font_mem_size is supposed to be one of the parameters that can differ > in INITEX and VIRTEX. The problem is that non_address is set to font_mem_size, > so when bchar_label[f] values are set to non_address and stored in a format > file by INITEX they will not be recognized as non-address values by a VIRTEX > that uses a different font_mem_size! > > Note that if font_mem_size in VIRTEX is smaller than the INITEX value > then a fatal format error will occur when loading bchar_label[nullfont] > (which was set to non_address by INITEX). If font_mem_size in VIRTEX is > larger than the INITEX value then far nastier problems can occur, such as > a character at the start of a word changing. I can't agree with Wayne on the point of this not being mentioned in tex.web. the font_mem_size is listed under: @ The following parameters can be changed at compile time to extend or reduce \TeX's capacity. They may have different values in \.{INITEX} and in production versions of \TeX. half a year ago i was hit by the same problem (call it an error or not :-) when i was preparing the LaTeX Companion. I had to enlarge the font_mem_size several times (web2c implementation) to allow for more fonts being loaded during runtime. Since the parameter was listed under the above heading i only regenerated virtex (and initex) but didn't produce new formats. The result were very weird errors like ligatures appearing at the begin of a word etc etc. I finally found that this was due to my change of the parameter without rerunning initex. I filed the problem away due to time shortage but i thought and still think it classifies under a bug, at least the parameter need to be moved to the next section in tex.web. However if there is a fix for the problem it would even be better to fix it. cheers frank 10-Mar-1994 18:02:02-GMT,3408;000000000001 Return-Path: Received: from math.ams.org by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA15067; Thu, 10 Mar 94 11:01:47 MST Received: from MZDMZA.ZDV.UNI-MAINZ.DE (vzdmzd.zdv.Uni-Mainz.DE) by MATH.AMS.ORG (PMDF #2306 ) id <01H9T12DURSG8Y5O2A@MATH.AMS.ORG>; Thu, 10 Mar 1994 11:56:37 EST Received: from MZDMZA.ZDV.UNI-MAINZ.DE by MZDMZA.ZDV.UNI-MAINZ.DE (PMDF V4.2-11 #4432) id <01H9TDL3ZNV48WWCOL@MZDMZA.ZDV.UNI-MAINZ.DE>; Thu, 10 Mar 1994 17:50:32 +0100 Date: 10 Mar 1994 17:50:32 +0100 From: Frank Mittelbach Subject: problems with the value of prevdepth To: tex-implementors@MATH.AMS.ORG Message-Id: <01H9TDL40GSY8WWCOL@MZDMZA.ZDV.UNI-MAINZ.DE> X-Vms-To: IN"tex-implementors@MATH.AMS.ORG" X-Vms-Cc: MITTELBACH Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT To: IN%"tex-implementors@MATH.AMS.ORG" since Andrew was faster on font_mem_size i would like to report another problem we enountered recently and hear your opinion about it. LaTeX has a command \vspace*{} that is supposed to produce extra vertical space which doesn't even vanishes between page breaks. The amount of extra space should be exactly . For this reason the command looks (if in vmode) at \prevdepth produces an invisible rule (to avoid getting discarded just after a page break) then a \penalty10000 followed by \vskip (another \vskip\z@ to guard against a following \unskip) followed by setting \prevdepth to the value encountered before the rule. This should give exactly the right space, for example, if placed at the beginning of a page it should lower the first line by exactly but unfortunately it doesn't. According to the TeX book \prevdepth is set to -1000pt at the beginning of a vertical list. This is done for the main vertical list as well, however it is not done for the individual main vertical list that forms a page. As a result, the depth of the last line on a preceding page influences the value of \prevdepth at the beginning of the next. this doesn't really matter since TeX doesn't look at prevdepth when it places the first line on the page (using \topskip instead) but it does very much matter when a macro looks at the internal quantity. The reason for current implementation is clear: if something is left on recent contributions, the value of \prevdepth is important since it reflects the depth of the last line in recent contributions and the implementation needs to preserve this value so the the next line contributed gets an appropriate interline spacing. However, since there is no way of determining on the macro level whether recent contributions are empty or not, there is no way to find out if the value of \prevdepth actually reflects the truth resulty in very ugly results on twolcoumn layout and other situations if you are unlucky. One can certainly argue that this is correct by definition: the main vertical list is a single list and therefore prevdepth is never supposed to be reset. However, I think that this interpretation is not natural; my suggestion would be to apply the following algorithm: In the output routine set \prevdepth to -1000pt iff the recent contributions are completely emptied otherwise leave it untouched since it reflects the depth of the last box as it will be seen on the macro level. cheers frank 11-Mar-1994 13:11:03-GMT,1321;000000000001 Return-Path: <71172.524@CompuServe.COM> Received: from math.ams.org by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA04363; Fri, 11 Mar 94 06:10:53 MST Received: from arl-img-1.compuserve.com by MATH.AMS.ORG (PMDF #2306 ) id <01H9U69FB8ZK8Y6NG1@MATH.AMS.ORG>; Fri, 11 Mar 1994 07:31:12 EST Received: from localhost by arl-img-1.compuserve.com (8.6.4/5.930129sam) id HAA05081; Fri, 11 Mar 1994 07:31:02 -0500 Date: 11 Mar 1994 07:27:39 -0500 (EST) From: Louis Vosloo <71172.524@CompuServe.COM> Subject: clarification To: TeX Implementors Message-Id: <940311122738_71172.524_DHQ57-1@CompuServe.COM> Content-Transfer-Encoding: 7BIT Hi: What I meant in my rumblings about max_half_word is the following: max_half_word should be what the name says it is, namely the *actual* max_half_word for the particular `word' size used in the TeX implementation, --- *not* the max_half_word for some ficticuous 36 bit CPU. And max_half_word should *not* be tied to the initial main memory allocation of iniTeX. --- max_half_word has nothing to do with how large you decide to make TeX's main memory (except that it has to be at least as large). In a dynamic TeX you cannot work with max_half_word set to 262144. Otherwise you can't grow various memory space beyond that. Regards, Berthold. 28-Mar-1994 19:38:27-GMT,1293;000000000001 Return-Path: Received: from math.ams.org by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA18446; Mon, 28 Mar 94 12:38:12 MST Received: from netcom10.netcom.com (netcom11.netcom.com) by MATH.AMS.ORG (PMDF #2306 ) id <01HAIBQQ5XB49TDPBN@MATH.AMS.ORG>; Mon, 28 Mar 1994 14:27:49 EST Received: from localhost by netcom10.netcom.com (8.6.4/SMI-4.1/Netcom) id LAA17402; Mon, 28 Mar 1994 11:28:30 -0800 Date: 28 Mar 1994 11:28:27 -0800 (PST) From: quixote@netcom.com (Don Hosek) Subject: Extending quarterword to 16 bits To: tex-implementors@MATH.AMS.ORG Reply-To: dhosek@quixote.com, tex-implementors@MATH.AMS.ORG Message-Id: <199403281928.LAA17402@netcom10.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: ELM [version 2.4 PL23] Content-Length: 454 Has anyone had experience with doing this? I'm beginning to experiment (with the goal of eliminating the restrictiong of 256 fonts loaded in TeX), but haven't explored all the ramifications (and yes, I know I need to modify \S610). One early unexpected result has been a TeX capacity exceeded error on reading the German hyphenation patterns (the only mods at this point are boosting font_max, max_quarterword and adapting the consistency checks). -dh 28-Mar-1994 19:59:58-GMT,4008;000000000001 Return-Path: Received: from math.ams.org by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA18817; Mon, 28 Mar 94 12:59:53 MST Received: from leeman.york.ac.uk by MATH.AMS.ORG (PMDF #2306 ) id <01HAICK9JHSG9TDMOP@MATH.AMS.ORG>; Mon, 28 Mar 1994 14:50:59 EST Received: from vax.york.ac.uk by leeman.york.ac.uk id <28828-0@leeman.york.ac.uk>; Mon, 28 Mar 1994 20:44:28 +0100 Date: 28 Mar 1994 20:44:28 +0100 From: postmaster@leeman.york.ac.uk Subject: Delivery Report (failure) for spqr@ftp.tex.ac.uk To: tex-implementors@MATH.AMS.ORG Message-Id: <"leeman.yor.823:28.02.94.19.44.22"@york.ac.uk> Content-Identifier: Extending qua... Content-Transfer-Encoding: 7BIT Message-Type: Delivery Report ------------------------------ Start of body part 1 This report relates to your message: Subject: Extending quarterword to 16 bits, Message-ID: <199403281928.LAA17402@netcom10.netcom.com>, To: tex-implementors@MATH.AMS.ORG of Mon, 28 Mar 1994 20:34:43 +0100 Your message was not delivered to spqr@ftp.tex.ac.uk for the following reason: Unknown Address No nameserver addresses for ftp.tex.ac.uk ***** The following information is directed towards the local administrator ***** and is not intended for the end user * * DR generated by: mta leeman.york.ac.uk * in /PRMD=UK.AC/ADMD= /C=GB/ * at Mon, 28 Mar 1994 20:44:22 +0100 * * Converted to RFC 822 at leeman.york.ac.uk * at Mon, 28 Mar 1994 20:44:28 +0100 * * Delivery Report Contents: * * Subject-Submission-Identifier: [/PRMD=UK.AC/ADMD= /C=GB/;<199403281928.LAA17402@netcom10.] * Content-Identifier: Extending qua... * Subject-Intermediate-Trace-Information: /PRMD=UK.AC/ADMD= /C=GB/arrival Mon, 28 Mar 1994 20:34:43 +0100 action Relayed * Subject-Intermediate-Trace-Information: /PRMD=UK.AC/ADMD= /C=GB/arrival Mon, 28 Mar 1994 20:28:27 +0100 action Relayed * Content-Correlator: Subject: Extending quarterword to 16 bits, * Message-ID: <199403281928.LAA17402@netcom10.netcom.com>, * To: tex-implementors@MATH.AMS.ORG* Recipient-Info: spqr@ftp.tex.ac.uk, * /S=spqr/OU=ftp/O=tex/PRMD=UK.AC/ADMD= /C=GB/; * FAILURE reason Unable-To-Transfer (1); * diagnostic Unrecognised-ORName (0); * last trace (ia5 text (2)) Mon, 28 Mar 1994 20:28:27 +0100; * converted eits ia5 text (2); * supplementary info "No nameserver addresses for * ftp.tex.ac.uk"; ****** End of administration information ------------------------------ Start of forwarded message 1 Received: from minster.york.ac.uk by leeman.york.ac.uk with SMTP (PP) id <28692-0@leeman.york.ac.uk>; Mon, 28 Mar 1994 20:34:44 +0100 From: tex-implementors@MATH.AMS.ORG Received: from netcom10.netcom.com (netcom11.netcom.com) by MATH.AMS.ORG (PMDF #2306 ) id <01HAIBQQ5XB49TDPBN@MATH.AMS.ORG>; Mon, 28 Mar 1994 14:27:49 EST Received: from localhost by netcom10.netcom.com (8.6.4/SMI-4.1/Netcom) id LAA17402; Mon, 28 Mar 1994 11:28:30 -0800 Date: 28 Mar 1994 11:28:27 -0800 (PST) >From: quixote@netcom.com (Don Hosek) Subject: Extending quarterword to 16 bits To: tex-implementors@MATH.AMS.ORG Reply-to: dhosek@quixote.com, tex-implementors@MATH.AMS.ORG Message-id: <199403281928.LAA17402@netcom10.netcom.com> MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: ELM [version 2.4 PL23] Content-Length: 454 Has anyone had experience with doing this? I'm beginning to experiment (with the goal of eliminating the restrictiong of 256 fonts loaded in TeX), but haven't explored all the ramifications (and yes, I know I need to modify \S610). One early unexpected result has been a TeX capacity exceeded error on reading the German hyphenation patterns (the only mods at this point are boosting font_max, max_quarterword and adapting the consistency checks). - -dh ------------------------------ End of forwarded message 1 28-Mar-1994 22:27:26-GMT,1697;000000000001 Return-Path: <71172.524@CompuServe.COM> Received: from math.ams.org by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA21617; Mon, 28 Mar 94 15:27:16 MST Received: from dub-img-2.compuserve.com by MATH.AMS.ORG (PMDF #2306 ) id <01HAIGLZX61S9TDRBD@MATH.AMS.ORG>; Mon, 28 Mar 1994 16:46:42 EST Received: from localhost by dub-img-2.compuserve.com (8.6.4/5.930129sam) id QAA13245; Mon, 28 Mar 1994 16:45:33 -0500 Date: 28 Mar 1994 16:41:47 -0500 (EST) From: Berthold Horn <71172.524@CompuServe.COM> Subject: Extending quarterword to 16 bits To: "INTERNET:quixote@netcom.com" Cc: TeX Implementors Message-Id: <940328214146_71172.524_DHQ129-1@CompuServe.COM> Content-Transfer-Encoding: 7BIT Dear Don: > Has anyone had experience with doing this? I'm beginning to experiment > (with the goal of eliminating the restrictiong of 256 fonts loaded > in TeX), but haven't explored all the ramifications (and yes, I know I > need to modify \S610). One early unexpected result has been a TeX > capacity exceeded error on reading the German hyphenation patterns > (the only mods at this point are boosting font_max, max_quarterword > and adapting the consistency checks). Yes, Y&YTeX does this. Its sort of a natural thing to do on machines were the TeX word is 64 bit. No big problems other than you need to modify the code were the font number is written to the DVI file -- to provide for multi-byte font numbers - which I guess is what you are referring to above... And, as you know :=), all decent DVI processors should be able to read multi- byte font numbers -- although most of them don't know what to do with them. Regards, Berthold. 29-Mar-1994 11:42:06-GMT,928;000000000001 Return-Path: Received: from math.ams.org by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA00478; Tue, 29 Mar 94 04:41:54 MST Received: from terminus.cs.umb.edu by MATH.AMS.ORG (PMDF #2306 ) id <01HAJ7NPQN009TDRD3@MATH.AMS.ORG>; Tue, 29 Mar 1994 05:41:33 EST Received: by terminus.cs.umb.edu id AA25088 (5.65c/IDA-1.4.4 for tex-implementors@MATH.AMS.ORG); Tue, 29 Mar 1994 05:41:15 -0500 Date: 29 Mar 1994 05:41:15 -0500 From: "K. Berry" Subject: Re: Extending quarterword to 16 bits To: dhosek@quixote.com, tex-implementors@MATH.AMS.ORG Message-Id: <199403291041.AA25088@terminus.cs.umb.edu> Content-Transfer-Encoding: 7BIT Bernd Raichle sent me some changes to extend web2c TeX to more than 256 fonts. It's in the README file in the web2c distribution. Perhaps I should install the changes into web2c's main change file; have to revisit that. 29-Mar-1994 13:26:28-GMT,2565;000000000001 Return-Path: Received: from math.ams.org by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA04290; Tue, 29 Mar 94 06:26:23 MST Received: from ifi.informatik.uni-stuttgart.de by MATH.AMS.ORG (PMDF #2306 ) id <01HAJC8TE7689TD8QD@MATH.AMS.ORG>; Tue, 29 Mar 1994 07:58:04 EST Received: from azu.informatik.uni-stuttgart.de by ifi.informatik.uni-stuttgart.de with SMTP; Tue, 29 Mar 94 14:50:15 +0200 Received: by azu.informatik.uni-stuttgart.de; Tue, 29 Mar 94 14:49:12 +0200 Date: 29 Mar 1994 14:49:12 +0200 From: Bernd Raichle Subject: Re: Extending quarterword to 16 bits In-Reply-To: Don Hosek's message of 28 Mar 1994 11:28:27 -0800 (PST) <199403281928.LAA17402@netcom10.netcom.com> To: tex-implementors@MATH.AMS.ORG Message-Id: <9403291249.AA09484@azu.informatik.uni-stuttgart.de> Content-Transfer-Encoding: 7BIT on 28 Mar 1994 11:28:27 -0800 (PST), quixote@netcom.com (Don Hosek) said: Don> Has anyone had experience with doing this? I'm beginning to experiment Don> (with the goal of eliminating the restrictiong of 256 fonts loaded Don> in TeX), but haven't explored all the ramifications (and yes, I know I Don> need to modify \S610). Don't forget to change the definiton of |undefined_control_sequence| to leave place in |eqtb| for the additional font identifiers (I have introduced a constant |max_font_max|, which must have the same value for IniTeX and VirTeX and replaces the constant 256 in the original places and definitions). Don> One early unexpected result has been a TeX Don> capacity exceeded error on reading the German hyphenation patterns Don> (the only mods at this point are boosting font_max, max_quarterword Don> and adapting the consistency checks). To read ghyphen.tex it's necessary to blow up the Trie constants (trie_size, trie_op_size). The ``big trie change'' of the original trie structures to allow more than 256 trie opcodes per language (for "ghyphen.max") shouldn't be necessary because you are using larger |quarter_word|s. Berthold Horn <71172.524@CompuServe.COM> said: > And, as you know :=), all decent DVI processors should be able to read multi- > byte font numbers -- although most of them don't know what to do with them. yes, all decent DVI processors should be able to read multi-byte font numbers and if they are good, they can process fonts with a font number > 255.... but there are good DVI processors which are not able to process more than 256 fonts per document (see: DVI driver standard, Level 0). Bernd Raichle 7-Apr-1994 14:25:00-GMT,6490;000000000001 Return-Path: Received: from silverfork.math.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA01923; Thu, 7 Apr 94 08:22:31 MDT Date: Thu, 7 Apr 94 08:22:31 MDT From: "Nelson H. F. Beebe" To: tex-implementors@math.ams.com, tex-archive@math.utah.edu, TWG-TAG@SHSU.edu Cc: beebe X-Us-Mail: "Center for Scientific Computing, University of Utah, Salt Lake City, UT 84112" X-Telephone: +1 801 581 5254 X-Fax: +1 801 581 4148 Subject: URGENT: ftp security alert Message-Id: In case some of you are not on the Computer Emergency Response Team (CERT) mailing list, I'm reposting this urgent message which arrived in my mailbox yesterday afternoon. I worked until late last night to get the ftp server on ftp.math.utah.edu upgraded to this latest version; comparison of sources with the previous version did not find any Trojan Horse code, so I don't believe that our ftp host has been compromised. Ftp access to our site was shut down for a few hours yesterday while I investigated this. The CERT message does not describe how the ftpd code was modified, but examination of the code shows that it would be quite easy to change one of the set*uid() function calls to leave a remote user with root privileges on the ftp server, perhaps only when certain ftp commands were issued, or when a particular username@hostname password was provided. I will shortly be making available the extended ftpd code, but instead of placing it in an anonymous ftp directory where it could be corrupted by a successful breakin, I will make separate arrangements for the transfer of the code with anyone who requests it. During installation and testing on several architectures, I found that the code has undocumented features that are useful, and which I will document before releasing the modified version. The older extended version of the ftpd program that has been available until now in ftp.math.utah.edu:/pub/misc/ftpd.trz has been deleted; if you have copies of ANY ftpd code in your archives, I suggest you seriously consider removing them. From: CERT Advisory Date: Wed, 6 Apr 94 12:51:16 EDT To: cert-advisory@cert.org Subject: CERT Advisory - wuarchive ftpd Trojan Horse Organization: Computer Emergency Response Team : 412-268-7090 Resent-To: cnet@lists.utah.edu Resent-Date: Wed, 6 Apr 94 13:13:16 MDT ============================================================================= CA-94:07 CERT Advisory April 6, 1994 wuarchive ftpd Trojan Horse ----------------------------------------------------------------------------- The CERT Coordination Center has received confirmation that some copies of the source code for the wuarchive FTP daemon (ftpd) were modified by an intruder, and contain a Trojan horse. We strongly recommend that any site running the wuarchive ftpd take steps to immediately install version 2.3, or disable their FTP daemon. ----------------------------------------------------------------------------- I. Description Some copies of the source code for versions 2.2 and 2.1f of the wuarchive ftpd were modified by an intruder, and contain a Trojan horse. If your FTP daemon was compiled from the intruder-modified source code, you are vulnerable. It is possible that previous versions of the source code for the server were modified in a similar manner. If you are running the wuarchive ftpd, but not providing anonymous FTP access, you are still vulnerable to this Trojan horse. II. Impact An intruder can gain root access on a host running an FTP daemon that contains this Trojan horse. III. Solution We strongly recommend that any site running the wuarchive ftpd (version 2.2 or earlier) take steps to immediately install version 2.3. If you cannot install the new version in a timely manner, you should disable FTP service. It is not sufficient to disable anonymous FTP. You must disable the FTP daemon. Sites can obtain version 2.3 via anonymous FTP from ftp.uu.net, in the "/networking/ftp/wuarchive-ftpd" directory. We recommend that you turn off your FTP server until you have installed the new version. Be certain to verify the checksum information to confirm that you have retrieved a valid copy. BSD SVR4 File Checksum Checksum MD5 Digital Signature ----------------- -------- --------- -------------------------------- wu-ftpd-2.3.tar.Z 24416 181 30488 361 e58adc5ce0b6eae34f3f2389e9dc9197 --------------------------------------------------------------------------- The CERT Coordination Center wishes to thank Bryan O'Connor and Chris Myers of Washington University in St. Louis for their invaluable assistance in resolving this problem. CERT also gratefully acknowledges the help of Neil Woods and Karl Strickland. --------------------------------------------------------------------------- If you believe that your system has been compromised, contact the CERT Coordination Center or your representative in the Forum of Incident Response and Security Teams (FIRST). If you wish to send sensitive incident or vulnerability information to CERT via electronic mail, CERT strongly advises that the e-mail be encrypted. CERT can support a shared DES key, PGP (public key available via anonymous FTP on info.cert.org), or PEM (contact CERT for details). Internet E-mail: cert@cert.org Telephone: 412-268-7090 (24-hour hotline) CERT personnel answer 8:30 a.m.-5:00 p.m. EST(GMT-5)/EDT(GMT-4), and are on call for emergencies during other hours. CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890 Past advisories, information about FIRST representatives, and other information related to computer security are available via anonymous FTP from info.cert.org. ======================================================================== Nelson H. F. Beebe Tel: +1 801 581 5254 Center for Scientific Computing FAX: +1 801 581 4148 Department of Mathematics, 105 JWB Internet: beebe@math.utah.edu University of Utah Salt Lake City, UT 84112, USA ======================================================================== 30-Apr-1994 11:23:09-GMT,33318;000000000001 Return-Path: Received: from math.ams.org by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA13297; Sat, 30 Apr 94 05:22:59 MDT Received: from csrj.crn.cogs.susx.ac.uk by MATH.AMS.ORG (PMDF #2306 ) id <01HBRZQ4O0YO8Y51DV@MATH.AMS.ORG>; Sat, 30 Apr 1994 07:00:20 EST Received: by csrj.crn.cogs.susx.ac.uk (Smail3.1.28.1 #44) id m0pxChR-00003QC; Sat, 30 Apr 94 11:55 BST Date: 30 Apr 1994 11:55 -0300 (BST) From: alanje@cogs.susx.ac.uk (Alan Jeffrey) Subject: LaTeX installation files To: tex-implementors@MATH.AMS.ORG Message-Id: Content-Transfer-Encoding: 7BIT Dear TeX implementors, As part of the full release of LaTeX2e, we would like to include documentation describing how LaTeX can be installed on as wide a variety of TeX platforms as possible. The details of these installation instructions may be very dependent on particular TeX implementations, so we would like to have as many of these files as possible maintained by experts in the TeX platform in question. We would be grateful for anyone who could take the time to prepare a SYSTEM.l2e file for inclusion in the full release of LaTeX2e, or who could provide any comments on the LaTeX installation procedure. Please find attatched the general LaTeX installation guide, plus a template for writing SYSTEM.l2e files, and a sample web2ctex.l2e installation guide for LaTeX under UNIX web2c TeX. NOTE: Some of the details of this installation are different from the current distribution. For example, the final release will produce a format file called latex.fmt, rather than latex2e.fmt, which is produced by the beta release. We hope to hear back from you, Alan Jeffrey (for the LaTeX3 project team) Alan Jeffrey Tel: +44 273 606755 x 3238 alanje@cogs.susx.ac.uk School of Cognitive and Computing Sciences, Sussex Univ., Brighton BN1 9QH, UK --- cut here for documentation --- % @TeX-file{ % date = "29 April 1994", % filename = "archive.tex", % docstring = "This is a self-extracting archive, containing: % install.l2e % texpert.l2e % othertex.l2e % template.l2e % web2ctex.l2e % They can be extracted by running TeX on this file." % } \def \gobble#1{} \def\checkchar#1#2{\ifnum`#1=#2\else\checkcharwarning{#1}{#2}\fi} \def\checkcharwarning#1#2{\immediate\write16 {Warning: ASCII #2 has been scrambled to character `\expandafter\gobble\string#1'. }} \checkchar{\@}{64} \checkchar{\#}{35} \checkchar{\$}{36} \checkchar{\%}{37} \checkchar{\^}{94} \checkchar{\&}{38} \checkchar{\*}{42} \checkchar{\_}{95} \checkchar{\{}{123} \checkchar{\}}{125} \checkchar{\[}{91} \checkchar{\]}{93} \checkchar{\<}{60} \checkchar{\>}{62} \checkchar{\\}{92} \checkchar{\/}{47} \immediate \write 16{} \immediate \write 16{This is a self-extracting archive, containing:} \message {install.l2e} \message {texpert.l2e} \message {othertex.l2e} \message {template.l2e} \message {web2ctex.l2e} \immediate \write 16{} \errhelp {Press RETURN to extract the files, or X to exit.} \errmessage {To extract these files, press RETURN.} \def \<#1\>{\immediate \write 1{#1}} \def \start(#1){\immediate \openout 1=#1 } \def \stop(#1){\immediate \closeout 1\immediate \write 16{File written on #1.}} \edef \\{\expandafter \gobble \string \\} \catcode `\{=12 \catcode `\}=12 \catcode `\~=12 \catcode `\@=12 \catcode `\#=12 \catcode `\$=12 \catcode `\%=12 \catcode `\^=12 \catcode `\&=12 \catcode `\_=12 \catcode `\|=12 \catcode `\{=12 \catcode `\}=12 \catcode `\[=12 \catcode `\]=12 \catcode `\<=12 \catcode `\`=12 \catcode `\'=12 \catcode `\ =12 \start(install.l2e) \< LaTeX Installation Guide \> \<\> \< 21 April 1994 \> \<\> \ \<======= \> \<\> \ \ \<\> \ \<\> \< * The available documentation. \> \<\> \< * How to find out about LaTeX with your version of TeX. \> \<\> \< * How the installation works. \> \<\> \< * What to do if anything goes wrong. \> \<\> \ \ \<\> \<\> \ \<============= \> \<\> \ \ \ \<\> \ \ \<\> \< * The LaTeX Companion, Goossens, Mittelbach and Samarin, Addison-Wesley \> \< ISBN 0-201-54199-8. \> \<\> \ \<\> \< * LaTeX: A Document Preparation System, Leslie Lamport, Addison-Wesley \> \<\> \<\> \ \<=================== \> \<\> \ \ \ \<\> \ \ \ \<\> \< * emtex.l2e for emTeX on the PC. \> \<\> \< * oztex.l2e for OzTeX on the Macintosh. \> \<\> \< * textures.l2e for Textures on the Macintosh. \> \<\> \< * web2ctex.l2e for web2c TeX on Unix platforms. \> \<\> \< * vmstex.l2e for VMS TeX on VAX platforms. \> \<\> \ \<\> \< * othertex.l2e for any other brand of TeX. \> \<\> \ \<\> \<\> \ \<========================== \> \<\> \ \<\> \< * Saving any old version of LaTeX. \> \<\> \< * Unpacking the distribution. \> \<\> \< * Creating the LaTeX format. \> \<\> \< * Putting the files where LaTeX can read them. \> \<\> \ \<\> \<\> \ \<------------------------------- \> \ \ \ \<\> \<\> \ \<-------------------------- \> \ \ \ \ \ \ \<\> \ \ \ \<\> \ \ \<\> \ \ \ \ \<\> \ \ \ \ \ \<\> \<\> \ \<------------------------- \> \ \ \ \<\> \ \ \ \<\> \<\> \ \<------------------------------------------- \> \ \ \ \<\> \< * the LaTeX inputs directory, which contains LaTeX files. \> \<\> \< * the MakeIndex inputs directory, which contains MakeIndex files. \> \<\> \ \<\> \< * latexbug.tex, testpage.tex and docstrip.tex. \> \<\> \ \<\> \< * .cls, document class files. \> \<\> \< * .clo, document class options files. \> \<\> \< * .sty, package files. \> \<\> \< * .fd, font definition files. \> \<\> \< * .def, files of definitions which may be read by LaTeX while \> \< processing documents. \> \<\> \< * .cfg, TeX expert configuration files. \> \<\> \ \ \<\> \< * .ist, MakeIndex style files. \> \<\> \ \<\> \<\> \ \<===================================== \> \<\> \ \ \ \<\> \ \ \<\> \ \<\> \<\> \ \<======== \> \<\> \ \ \<\> \<\> \<`texsys.cfg': While running iniTeX on latex2e.ltx you may get an error \> \< reporting a problem with texsys.cfg. \> \<\> \< If this happens then you have obtained (or produced) a texsys.cfg that \> \< is not suitable for your system. \> \<\> \< First, read the system.l2e file. This may tell you how to customize \> \< texsys.cfg \> \<\> \< If the system.l2e file does not mention texsys.cfg, then you should \> \< not need a texsys.cfg file. Try deleting texsys.cfg and building the \> \< LaTeX format again. \> \<\> \< If you still get errors, try running LaTeX on dircheck.dtx, and \> \< reading the resulting document. \> \<\> \<\> \<`File missing': Some of the files from the LaTeX distribution are \> \< missing. There are a number of possible reasons for this: \> \<\> \< * the files are missing. You should get the files from the same \> \< place you got the rest of the distribution. If you can't, you \> \< should complain to whoever gave you this distribution. \> \<\> \< * the files are present, but in the wrong directory. You should \> \< move the files to a directory iniTeX can read. \> \<\> \< * the files are present, and in the right directory. IniTeX may \> \< have been set up incorrectly. You may be able to correct this, \> \< depending on your TeX implementation. See the documentation of your \> \< TeX implementation for more details. \> \<\> \<\> \<`Font missing': Some of the fonts (.tfm files) required by LaTeX are \> \< missing. As above, either you have not got the required files, or \> \< iniTeX is not able to find them. So you may need to move them or to \> \< configure iniTeX to look in the correct places. See the documentation \> \< of your TeX implementation for more details. \> \<\> \<\> \<`Out of memory': On TeX implementations with small memory, you may \> \< exhaust iniTeX's memory whilst installing LaTeX. \> \<\> \< You may be able to correct this: \> \<\> \< * Some TeX implementations allow the amount of memory allocated \> \< to TeX to be increased. See the documentation of your TeX \> \< implementation for more details. \> \<\> \< * Some iniTeX implementations allow more memory than others; so \> \< you may be able to run iniTeX on a larger machine and then move \> \< the files across to the smaller machine. \> \<\> \< * If the error happened during the unpacking of the distribution \> \< (i.e. when you run iniTeX on unpack.ins) then try running this \> \< file with normal TeX, for example plain TeX or an old version \> \< of LaTeX. \> \<\> \<\> \ \<\> \< * read the system.l2e file; \> \<\> \< * if this fails, ask your local TeX guru; \> \<\> \< * if this fails, try asking a local TeX mailing list; \> \<\> \< * if this fails, run iniTeX on the file latexbug.tex, fill in the \> \< resulting bug report form, and send it to: \> \<\> \< latex-bugs@rus.uni-stuttgart.de \> \<\> \<\> \<--- Copyright 1994 the LaTeX3 project. --- \> \<--- All rights reserved. --- \> \<\> \stop(install.l2e) \start(texpert.l2e) \< LaTeX installation TeX expert information \> \<\> \< 21 April 1994 \> \<\> \<\> \ \<======= \> \<\> \ \ \<\> \< * The checks performed by ltxcheck.tex \> \<\> \< * How to print the LaTeX source. \> \<\> \< * How to configure the hyphenation patterns for LaTeX. \> \<\> \< * How to configure LaTeX's compatibility mode. \> \<\> \ \<\> \<\> \ \<======================= \> \<\> \ \<\> \<1) The \\@currdir check. \> \< It is useful for LaTeX to know the syntax for the `current directory \> \< (or folder)', or `default directory', if the operating system has \> \< such a concept. \> \<\> \< For example, file abc.tex in this directory, or folder, is specified \> \< by: \> \< ./abc.tex on unix and most DOS/OS2 TeX's, \> \< []abc.tex on VMS \> \< :abc.tex on a Macintosh. \> \< The above possibilities will be found automatically during the \> \< installation. However, if none of these syntaxes works on your \> \< system then the internal macro \\@currdir will be set to be empty \> \< and ltxcheck will report this. \> \<\> \< If your system does have a notion of a current directory, you can \> \< define \\@currdir in texsys.cfg. \> \<\> \< You could also report this to the latex-bug address, so that \> \< later releases can automatically cope with your system. \> \<\> \<2) The \\input@path check. \> \< On some systems TeX cannot check whether a file exists before \> \< trying to input it, unless the filename is expressed as a full path \> \< name, including the directory. On these systems LaTeX needs to be \> \< given a list of directories in which to look for files; the \> \< internal macro \\input@path holds this information. \> \<\> \< When run, ltxcheck will try to locate the file article.cls. \> \< If it fails to find this file (and you have placed it in the \> \< `standard input directory') then you must define \\input@path in \> \< texsys.cfg. \> \<\> \< The files texsys.cfg and dircheck.dtx contain examples of how to do \> \< this but only you know the directories and syntax that should be used \> \< for your installation. \> \<\> \< We hope to build up a better collection of examples in future \> \< releases of LaTeX2e, as it is tested on more TeX systems. \> \<\> \<3) TeX version check. \> \< The final checks test that you are running a recent version of TeX. \> \< If ltxcheck reports that you have TeX2, then you should try to \> \< upgrade TeX (and rebuild LaTeX) as soon as possible. LaTeX2e may be \> \< used with TeX2, but certain features will be missing and you will \> \< not be able to use the new (8-bit) font families that are now \> \< available. \> \<\> \< If ltxcheck reports that your TeX version is older than 3.141, you \> \< will see some strange messages during the installation. This is \> \< because earlier TeXs printed certain line-breaks in messages on the \> \< terminal as ^^J rather than starting a new line. \> \<\> \<\> \ \<========================= \> \<\> \ \ \ \ \<\> \ \ \ \<\> \< \\PassOptionsToClass{a4paper}{article} \> \<\> \ \ \ \ \ \<\> \ \<\> \< makeindex -s gind.ist FILENAME \> \< makeindex -s gglo.ist -o FILENAME.gls FILENAME.glo \> \<\> \<\> \ \<======================= \> \<\> \<*** THIS NEEDS WRITTEN! *** \> \<\> \<\> \ \<============================== \> \<\> \ \<\\documentclass, LaTeX assumes it is a LaTeX 2.09 document, and \> \ \<\> \< * sets a flag \\@compatibilitytrue \> \<\> \< * inputs the file latex209.def \> \<\> \< * inputs a file latex209.cfg if it exists. \> \<\> \ \ \ \ \ \ \ \<\> \<\> \<--- Copyright 1994 the LaTeX3 project. --- \> \<--- All rights reserved. --- \> \<\> \stop(texpert.l2e) \start(othertex.l2e) \< LaTeX installation instructions for unknown implementation \> \<\> \< 10 April 1994 \> \<\> \<\> \ \<======= \> \<\> \ \ \ \ \<\> \ \<\> \< * How to save any old version of LaTeX. \> \<\> \< * How to unpack the LaTeX distribution. \> \<\> \< * How to create the LaTeX format. \> \<\> \< * How to install the LaTeX files. \> \<\> \< * How to check the LaTeX installation. \> \<\> \< * What to do if the installation didn't work. \> \<\> \ \ \ \ \ \<\> \<\> \ \<=============================== \> \<\> \ \ \<\> \ \ \<\> \ \ \ \ \ \<\> \< * If the LaTeX inputs are separate from the other TeX inputs, then you \> \< should make a copy of the LaTeX inputs directory, and call it \> \< `latex209'. \> \<\> \< * If the LaTeX inputs are kept with the other TeX inputs, then you \> \< should create a new directory called `latex209', and copy any file \> \< ending with .sty from the LaTeX inputs directory into the latex209 \> \< directory. \> \<\> \ \ \ \<\> \< * The `latex209' format is used rather than `latex'. \> \<\> \< * The `latex209' directory is searched before the LaTeX inputs directory. \> \<\> \ \<\> \<\> \ \<========================== \> \<\> \ \<`unpack.ins'. The details of how to do this will depend on your TeX \> \ \<\> \<\> \ \<========================= \> \<\> \ \<`latex.ltx' and save the resulting format file as `latex.fmt' in the TeX \> \ \<`latex', or a `LaTeX' option to your TeX implementation. The details of \> \ \<\> \<\> \ \<=========================================== \> \<\> \ \ \<\> \< latexbug.tex testpage.tex docstrip.tex. \> \<\> \ \<\> \< .cls .clo .sty .fd .def .cfg \> \<\> \ \ \<\> \< gind.ist gglo.ist \> \<\> \ \<\> \<\> \ \<===================================== \> \<\> \ \ \ \ \<\> \<\> \ \<======== \> \<\> \ \ \ \<\> \ \<`PROBLEMS' section in install.l2e. \> \<\> \<\> \<--- Copyright 1994 the LaTeX3 project --- \> \<--- All rights reserved. --- \> \<\> \stop(othertex.l2e) \start(template.l2e) \< \> \<\> \< This file contains a template for system.l2e files. If you want to \> \< write a system.l2e file for your TeX implementation, then this is a \> \< good place to start! \> \<\> \< All of the places where you can add customization are indicated by a \> \< tag like . The tags are: \> \<\> \< ... This material is intended for the author of a \> \< system.l2e file. Please delete it before showing it to users! \> \<\> \< ... You may delete this material if you wish. \> \<\> \< ... Please write a description here. \> \<\> \< Replace this with the name of your TeX \> \< implementation, e.g. `FooTeX v1.4'. \> \<\> \< Replace this with today's date, e.g. `1 April 1994'. \> \<\> \< Replace this with the current year, e.g. `1994'. \> \<\> \< Replace this with your name, e.g. `Jane Doe'. \> \<\> \< Remember, a lot of users won't bother reading install.l2e, they'll \> \< just be reading this file! \> \<\> \< If you'd like to distribute this file to other users of your TeX \> \< implementation, please EMail it to latex-bugs@rus.uni-stuttgart.de. \> \<\> \< \> \<\> \< LaTeX installation instructions for \> \<\> \< \> \<\> \<\> \ \<======= \> \<\> \ \<. Before reading this file, you should read \> \ \<\> \ \<\> \< * How to save any old version of LaTeX. \> \<\> \< \> \< * How to configure LaTeX. \> \< \> \<\> \< * How to unpack the LaTeX distribution. \> \<\> \< * How to create the LaTeX format. \> \<\> \< * How to install the LaTeX files. \> \<\> \< \> \< * What to do if you have any problems. \> \< \> \<\> \< \> \< * Name any system-specific sections, e.g. `Running LaTeX with FooTeX v \> \< 1.2 or older'. These should appear as sections below! \> \< \> \<\> \<\> \ \<=============================== \> \<\> \ \ \<\> \< \> \< Describe how to save the old format as `latex209.fmt' and the old \> \< inputs in a directory called `latex209'. You might also describe how \> \< to run LaTeX2e and LaTeX 2.09 in parallel. \> \< \> \<\> \< \> \<\> \ \<================= \> \<\> \< \> \< Describe any configuration which has do be done. For example, LaTeX2e \> \< uses more memory than LaTeX 2.09, so you may need to tell users to \> \< increase one of TeX's memory parameters. \> \<\> \< If your TeX implementation requires a texsys.cfg file, you shold \> \< describe a sample one, and tell users to cut it out, edit it as \> \< appropriate, and save it as texsys.cfg. For example, under OzTeX 1.5, \> \< an appropriate example texsys.cfg file would be: \> \<\> \< \\def\\@currdir{:} \> \< \\def\\input@path{% \> \< {Hard-Disk:TeX:My-inputs}% \> \< {Hard-Disk:TeX:TeX-inputs}% \> \< } \> \<\> \< See dircheck.dtx and texpert.l2e for more details about texsys.cfg. \> \< \> \<\> \< \> \<\> \ \<========================== \> \<\> \< \> \< Describe how to run iniTeX on unpack.ins. This won't generate a .fmt \> \< file. \> \< \> \<\> \<\> \ \<========================= \> \<\> \< \> \< Describe how to run iniTeX on latex.ltx. This will generate a .fmt \> \< file, and you should tell users to put it in an appropriate \> \< directory. You may need to include some other system-specific \> \< instructions, e.g. editing CONFIG files or writing shell scripts. \> \< You may also want to show a sample texsys.cfg file. \> \< \> \<\> \<\> \ \<=========================================== \> \<\> \< \> \< Describe how to move the following files into a LaTeX inputs directory: \> \<\> \< latexbug.tex testpage.tex docstrip.tex. \> \< *.cls *.clo *.sty *.fd *.def *.cfg \> \<\> \< and put *.ist in a MakeIndex inputs directory. \> \< \> \<\> \<\> \ \<===================================== \> \<\> \< \> \< Describe how to run LaTeX (yes, some users may not have run LaTeX \> \< before!) on ltxcheck.tex. Say that it's going to produce some `OK' \> \< messages, and perhaps some `BAD' warnings. \> \< \> \<\> \< \> \<\> \ \<======== \> \<\> \< \> \< Describe any problems users may come across in this TeX \> \< implementation, and clues on how to cure them! Try copying the style \> \< of the `PROBLEMS' section in install.l2e. \> \< \> \<\> \ \<`PROBLEMS' section in install.l2e. \> \<\> \< \> \<\> \<\> \< \> \<\> \< SYSTEM-SPECIFIC SECTIONS \> \< ======================== \> \<\> \< Put any other system-specific material here, e.g. `How to install \> \< LaTeX with versions of FooTeX older than 1.2'. \> \<\> \< \> \<\> \<\> \<--- Copyright and the LaTeX3 project --- \> \<--- All rights reserved. --- \> \<\> \stop(template.l2e) \start(web2ctex.l2e) \< LaTeX installation instructions for web2c Unix TeX \> \<\> \< 18 April 1994 \> \<\> \<\> \ \<======= \> \<\> \ \ \ \<\> \ \<\> \< * How to save any old version of LaTeX. \> \<\> \< * How to unpack the LaTeX distribution. \> \<\> \< * How to create the LaTeX format. \> \<\> \< * How to install the LaTeX files. \> \<\> \ \ \<\> \ \ \<\> \< setenv LATEXINPUTS /usr/local/lib/tex/inputs/latex \> \<\> \ \ \<\> \< setenv LATEXFORMATS /usr/local/lib/tex/formats \> \<\> \ \ \<\> \< setenv LATEXBIN /usr/local/bin \> \<\> \ \ \<\> \< setenv LATEXDIST /usr/local/lib/tex/latex/src \> \<\> \<\> \ \<=============================== \> \<\> \ \ \<\> \ \<\> \< cd $LATEXFORMATS \> \< mv latex.fmt latex209.fmt \> \<\> \ \ \ \<\> \< cd $LATEXINPUTS \> \< mkdir ../latex209 \> \< cp *.sty ../latex209 \> \<\> \ \<\> \< cd $LATEXINPUTS \> \< mkdir ../latex209 \> \< cp * ../latex209 \> \<\> \ \ \<\> \< #!/bin/sh \> \< TEXINPUTS=${LATEX209INPUTS:- \\ \> \< .:/usr/local/lib/tex/inputs/latex209:$TEXINPUTS} \> \< export TEXINPUTS \> \< virtex \\&latex209 $* \> \<\> \<\> \ \<========================== \> \<\> \ \<\> \< cd $LATEXDIST \> \< initex unpack.ins \> \<\> \ \<\> \<\> \ \<========================= \> \<\> \ \<\> \< initex latex.ltx \> \<\> \ \<\> \< mv latex.fmt $LATEXFORMATS \> \<\> \ \ \<\> \< cd $LATEXBIN \> \< ln virtex latex \> \<\> \<\> \ \<=========================================== \> \<\> \ \<\> \< cd $LATEXDIST \> \< mv latexbug.tex testpage.tex docstrip.tex \\ \> \< *.cls *.clo *.sty *.fd *.def *.cfg \\ \> \< $LATEXINPUTS \> \<\> \ \<\> \<\> \ \<===================================== \> \<\> \ \<\> \< cd $LATEXDIST \> \< latex ltxcheck \> \<\> \ \<\> \<\> \<--- Copyright 1994 the LaTeX3 project. --- \> \<--- All rights reserved. --- \> \<\> \<\> \stop(web2ctex.l2e) \catcode`\ =12 \ifx\LaTeX\isanundefinedcontrolsequence \expandafter\end \else \makeatletter\expandafter\@@end \fi