Date: 14 March 91 Message No: 039 To: TeX implementors and distributors From: Barbara Beeton Subject: Messages from DEK, part 4 ************************************************************************ >>> \TeX logo; some problems with \loop i accidentally misfiled this with another problem that had already been solved; it should have been sent to you months ago. ------- Date: Mon 24 Jun 91 14:39:46-EST From: Michael Downes Subject: \TeX % These %'s are so that you can move this file out of mail % and \TeX{} it as is to run the tests given below. % % What version of plain.tex were you using when you checked the % spacefactor after \TeX? The one running on the TeXserver is % presumably quite recent since the version of TeX is 3.1, from % the standard Unix distribution. The following test demonstrates % that the spacefactor after \TeX{} has to be manually adjusted % to get proper spacing when punctuation follows (if \nonfrenchspacing % is in effect). This can be corrected so easily by adding % \spacefactor\@m at the end of \TeX's definition that I % don't know why it hasn't been done already. Perhaps there's % some reason not to do so that Knuth can explain. [ dek: That would have been better but I think it's too late now to make such a change ] % The space after the first period differs from the space after % the second period, as demonstrated by the \showlists command. \tracingonline=1 \showboxbreadth=\maxdimen \TeX{}. Next. Third.\showlists % If Knuth changes plain.tex to fix \multispan perhaps he'll be % willing to consider another obvious improvement: % % Redefine \loop, as described in TUGboat vol 8 no 2 July 1987 % by Alois Kabelschacht. % % This allows an \else branch on the repeat condition to be used, % which seems rather important in light of the fact that TeX \ifnum % and \ifdim tests only allow <, =, and > comparisons, with no % "not" operator or <= or >= combinations. Knuth might be unwilling % to do this, however, since it would require corresponding changes % in the TeXbook in the description of plain.tex; and it might be [ dek: All the macros in Plain TeX are merely simple examples that can be improved ad infinitum ... I cannot keep doing it ] % only 99.8% backward compatible. [However, no existing TeX file % will fail to run under the following redefinition unless it % refers to the internal pieces of \loop (\body and \next), and % perhaps the most likely reason someone might have done so would % be to compensate for the lack of an \else possibility!!] \def\loop#1\repeat{\def\iterate{#1\expandafter\iterate\fi}% \iterate \let\iterate\relax} % The following example illustrates an \else condition in % the internal loop. It takes an even number and keeps % dividing it until the result is odd. Try a large % power of 2, e.g., 65536. \newcount\n \newlinechar=`\& \loop \message{&Enter a large even number (RETURN to stop): }% \read-1 to\answer \n=0\answer\relax [ dek: ^^^^^^ wow, a trick I didn't know ] \ifnum\n>0 % Braces to localize \iterate {\loop \divide \n by 2 \message{&N divided by 2 = \number\n}% \ifodd\n \else\repeat}% \repeat \bye ------- comment by bb: i thought the definition of \TeX had been changed, because the following definition accompanied DEK's article of October '90 on "The future of TeX and METAFONT": \def\TeX{T\hbox{\hskip-.1667em\lower.424ex\hbox{E}\hskip-.125em X}} i'm pretty sure if that had been my addition, i would have marked it as such, or would have made the change at a more general level. but i could very well be misremembering. ------- Date: Fri, 3 JAN 92 22:14:36 GMT Originally-from: TEX "Brian {Hamilton Kelly} " From: TEX@rmcs.cranfield.ac.uk Subject: RE: flash!!! notice that tex update is about to happen [ ... ] Brian PS I'd love to see some way of using \loop... within an \halign; at present it falls over because each & cancels a level of grouping, and so the definition of \body (or is it \repeat) keels over. But I guess this is too big a change. [ dek: Well \dosplits on page 397 does iterate within \valign (which is similar) ] ------- <<< end \TeX logo; some problems with \loop ************************************************************************ >>> cedilla accent macro in plain.tex Date: Mon, 23 Sep 91 11:56:15 +0200 From: Bernd Raichle Subject: TeX Bug Report -- plain.tex, cedilla accent macro Dear Ms. Beeton, I've found a small bug in `plain.tex' (and a missing index entry in the TeXbook). Perhaps someone has reported it before, but I have seen no fix for it... 1. There's a missing index entry for "ligatures" in the TeXbook. Page 306 contains the answer of exercise 5.1. This answer explains how to supress unwanted ligatures. [ dek: No ... p 19 (ex 5.1, about suppressing unwanted ligs) is indexed. see p 457 "an answer page is not indexed unless ..." ] 2a. The \c macro in `plain.tex' produces a box with the wrong dimensions (height = depth = 0pt) for arguments with height != 1ex. Fix 1: exchange the \unhbox\z@ and \hidewidth\char24\hidewidth in the macro definition [ dek: good $2.56 \ooops ] \def\c#1{\setbox\z@\hbox{#1}\ifdim\ht\z@=1ex\accent24 #1% \else{\ooalign{\unhbox\z@\crcr\hidewidth\char24\hidewidth}}\fi} 2b. For characters with depth != 0pt, the "cedilla" character is not lowered. I don't know of any use for this, because there's only the c-cedille accent. But the idea used in the proposed fix can be used for the under-dot and under-bar accent (and \AA) too. The accent characters of these macros are misplaced if used within a slanted font. Fix 2: use the \accent primitive and a changed ex-value to shift the accent character to the correct place \def\c#1{{\dimen@ 1ex% % Compute new ex value: % The cedilla accent should not be shifted for uppercase characters, % => new-ex := height(#1). {\setbox\z@\hbox{#1}\dimen@\ht\z@ % but we have to shift it down, if the character has depth. % => new-ex := new-ex + depth(#1) \advance\dimen@\dp\z@ % Set the `ex' value (fontdimen change is always global), \fontdimen5\font\dimen@}% % ... set the accent char, reset `ex' to the old value % and do the rest. \accent24\fontdimen5\font\dimen@ #1}} Yours, Bernd Raichle (raichle@azu.informatik.uni-stuttgart.de) PS: Please can you add me to the `tex-implementors' list? Thanks in advance. ------- Date: Sun, 29 Sep 91 15:37:10 BST From: Chris Thompson Subject: Re: [[Bernd Raichle : TeX BugReport -- plain.tex, cedi]] Dear Barbara, > 1. There's a missing index entry for "ligatures" in the TeXbook. > Page 306 contains the answer of exercise 5.1. This answer explains > how to supress unwanted ligatures. Yes, I think it plausible that 306 should appear in the list. It doesn't in the most recent 'texbook.tex' I have access to. > 2a. The \c macro in `plain.tex' produces a box with the wrong dimensions > (height = depth = 0pt) for arguments with height != 1ex. > > Fix 1: exchange the \unhbox\z@ and \hidewidth\char24\hidewidth in > the macro definition > > \def\c#1{\setbox\z@\hbox{#1}\ifdim\ht\z@=1ex\accent24 #1% > \else{\ooalign{\unhbox\z@\crcr\hidewidth\char24\hidewidth}}\fi} Amazing that this hasn't come to light earlier: \hbox{\c C} has zero height and depth as stated! Bernd's fix would appear to be the right one: but maybe there is some subtle reason why the alignment is written that way round at the moment---it's such a counterintuitive thing to do! > 2b. For characters with depth != 0pt, the "cedilla" character is not > lowered. I don't know of any use for this, because there's only the > c-cedille accent. But the idea used in the proposed fix can be > used for the under-dot and under-bar accent (and \AA) too. The > accent characters of these macros are misplaced if used within a > slanted font. > > Fix 2: use the \accent primitive and a changed ex-value to shift > the accent character to the correct place > > \def\c#1{{\dimen@ 1ex% > % Compute new ex value: > % The cedilla accent should not be shifted for uppercase characters, > % => new-ex := height(#1). > {\setbox\z@\hbox{#1}\dimen@\ht\z@ > % but we have to shift it down, if the character has depth. > % => new-ex := new-ex + depth(#1) > \advance\dimen@\dp\z@ > % Set the `ex' value (fontdimen change is always global), > \fontdimen5\font\dimen@}% > % ... set the accent char, reset `ex' to the old value > % and do the rest. > \accent24\fontdimen5\font\dimen@ #1}} This is a much more ambitious change, and I have doubts about its having sufficient backwards compatibility, and its robustness. An interesting technique, though, which relies on the x-height of the current font being recorded before the |do_assignments| call in |make_accent|. I think you should show it to Don together with the rest. Chris Thompson <<< end cedilla accent macro in plain.tex ************************************************************************ >>> missing \mathsurround in plain.tex Date: Mon, 4 Nov 91 13:35:11 +0100 From: schoepf@sc.ZIB-Berlin.DE (Rainer Schoepf) Organization: Konrad-Zuse-Zentrum fuer Informationstechnik Berlin Subject: Glitches in plain.tex Barbara, while revamping the LaTeX files I found that some macros from plain.tex lack the \m@th (i.e. \mathsurround=0pt) assignment. The macros in question are: \overrightarrow \underrightarrow [ dek: (scratched out \underrightarrow) \overleftarrow ] \overbrace \underbrace \notin/\c@ncel \rightleftharpoons/\rlh@ [ dek: $2.56 x 3 A359, A360, A361 ] What do you think? I append a demo file. Rainer ------------------demo for plain tex-------------------- text$\overrightarrow{abcdef}$text text$a \notin b$text \mathsurround =10pt text$\overrightarrow{abcdef}$text text$a \notin b$text text$a \rightleftharpoons b$text \bye <<< end missing \mathsurround in plain.tex ************************************************************************ >>> \arrowvert code, plain.tex comment by bb: there are several symbols in cmex* that are meant as midsections of arrows, brackets, etc., but which are also given \cs names. these include \arrowvert \Arrowvert \bracevert it seems that as long as these are referenced indirectly, through \uparrow, \downarrow, etc., they are well behaved, but when they are referenced by the \cs name, the wrong symbol is produced. i'm not the only one who finds the \delimiter values assigned in plain somewhat mysterious. if these really are errors, there's a different claimant for each one: \arrowvert -- Phil Taylor, \Arrowvert -- me, \bracevert -- Chris Thompson. if the values are correct though, we'd really appreciate a good explanation of how this works. re the comments by michael barr regarding how much memory is required for rules vs. characters, i know that's been explained before, but perhaps it's time to do it again. i shall ask chris thompson or brian {hk}. ------- Date: Mon, 11 NOV 91 17:43:28 BST Reply-to: Philip Taylor (RHBNC) From: CHAA006@vax.rhbnc.ac.uk Subject: [Surely not another] bug in Plain.TeX ? For a book on French linguistics, I need up/down arrows which span rows in an \halign; I use \uparrow, \downarrow and \arrowvert. In both the MS/DOS (emTeX) and VAX/VMS versions of Plain.TeX, \arrowvert translates to \delimiter"33C000. Character "3C in family 3 (cmex10) is the centre part of a brace, not a vertical arrow ... [ dek: right, as stated on page 150. I admit these names are not the best, but you are supposed to regard them as _verts_ (with differing weights) derived from arrows/braces _not_ as arrows/braces ] ** Phil. P.S. Plain version 3.0 (can't find a date). ------- Date: Mon, 18 NOV 91 10:57:30 BST Reply-to: Philip Taylor (RHBNC) From: CHAA006@vax.rhbnc.ac.uk Subject: Re: [Surely not another] bug in Plain.TeX ? >>> however, now that i look at this, i'm wondering why you haven't just >>> used \uparrow, \downarrow, and \updownarrow, forcing them to whatever >>> size you want with phantoms. or have you? if so, and you're really >>> getting the wrong pieces, then there's a problem in the .tfm file too. I did, in the end; here's the current version: % \newbox \arrowbox \setbox \arrowbox = \hbox {\let|=\strut\smash{$\left\updownarrow\matrix{|\cr|\cr|\cr|\cr}\right.$}} \def \arrow {\copy \arrowbox} % \Begin {columns} \options = {\listindent = 0.25 \listindent} % \+&&Il&&&&effondr{\'e}&&&&&&&&une chaise.&\cr \+&&Pierre&&s'est&&assis&&sur&&&&&&un si{\`e}ge.&\cr \omit&\arrow&&&&\arrow&&&&&&&&\arrow&&\cr \+&&L'{\'e}tudiant&&&&install{\'e}&&&&&&&&un tabouret.&\cr \+&&&&&&&&&&&&&&un canap{\'e}.&\cr \+&&\multispan 4{\qquad \leftarrowfill\rlap {$\joinrel \rightarrow$}}&& \multispan 2{\llap {$\leftarrow$}$\joinrel$\rightarrowfill}&&&&& \multispan 2{\llap {$\leftarrow$}$\joinrel$\rightarrowfill}&\cr % \End {columns} [ ... ] ------- Date: Wed 20 Nov 91 07:02:41-EST From: bbeeton To: CET1@phx.cam.ac.uk by the way, phil taylor has found another plain bug -- the character referenced by \arrowvert is wrong; following his lead, i discovered that \Arrowvert also looks bad. (these are rarely used, but even so, it's surprising they haven't been found before; i think they've been this way since versions >1.) phil is concocting a routine to print out all the plain math characters for checking. -- bb ------- Date: Thu, 21 Nov 91 16:39:06 GMT From: Chris Thompson [ ... ] I met Phil Taylor at the UKTeX meeting in Oxford yesterday, and he told me about the \arrowvert..\Arrowvert problem. I was surprised that such a bug had gone unnoticed so long. Are you both sure about this? I get the appearance described on page 150 of the TeXbook in test programs. (All this complicated by the variable-character codes in cmex10, by which a character rarely means itself! "3C as varchar is actually repeating bits of "3F, and "3D as a varchar is repeating bits of "77.) There was a change in plain \fmtversion 2.92 (I think) in which the definitions of \arrowvert, \Arrowvert and \bracevert were changed from "33C, "33D & "33E to "33C000, "33D000 & "33E000: I never understood in what circumstances this could make a difference! [ dek: Yes, see the bottom of page 156 ] Chris Thompson ------- Date: Fri, 22 NOV 91 11:02:27 BST Reply-to: Philip Taylor (RHBNC) From: CHAA006@vax.rhbnc.ac.uk Subject: Arrowvert (forgot to cc you) Dear Chris --- >>> I was using tests like >>> $$\left\arrowvert X\sp h \over J_y \right\Arrowvert$$ >>> and they seem to work. Have you got an example which fails? Yes ! $ \arrowvert $ ! [I suppose this means I must be abusing \arrowvert, [ dek: ^^ \bigg would produce a particular size I will pay Phil $2.56 ] but I can't for the life of me see why ...] ** Phil. ------- Date: Fri, 22 Nov 91 15:37:37 GMT From: Chris Thompson To: Philip Taylor (RHBNC) Subject: RE: \arrowvert..\Arrowvert Phil, Ah, I see! Although $\left\arrowvert...$ works, $\arrowvert$ doesn't. The trouble is, I don't see how it can be made to... When \arrowvert is used in the context of a , only the top 15 bits of the 27-bit number following \delimiter are used. Before the change in plain 2.92 (if that is in fact when it was) this would have produced \mathchar"0000 (clearly wrong); now it produces \mathchar"033C (unfortunately, still wrong). cmex10 character "3C as a math character is the middle piece of a large \lbrace as shown on p.432, but when used as a (after \left, or the macros \bigl, \Biggl, etc.) its varchar definition is used, and that says that it should be made up of a lot of copies of character "3F (no top, middle or bottom piece used). If the definition of \arrowvert was changed to "033F000, then the context would work, but the one wouldn't: instead it would be like \updownarrow. [ dek: Next version of plain has a good compromise: \lmoustache "437A340 \arrowvert "026A33C \rmoustache "437B341 \Arrowvert "026B33D \lgroup "462833A \bracevert "077C33E \rgroup "462933B ] Chris Thompson ------- Date: Thu, 21 Nov 91 11:31:24 EST X-ListName: TeX-Related Network Discussion List From: barr@triples.Math.McGill.CA Subject: Optimizing TeX? Let me begin by mentioning a misprint in the Book. On page 358, line -8 (17th printing, Jan. 1990), it says \mathchardef\mapstochar="322F \def\mapsto{\mapstochar\rightarrow} and the "322F should be (and is, in plain.tex) "3237. [ dek: $2.56 was paid to Karl Berry for this on 19 Sep 91. Labrea sources haven't changed yet but my texbook.tex had this correct as of 18 Sep 91 acc. to errata.tex ] The reason I noticed this was that a colleague had tried to make a \mapsfrom macro and discovered a curious fact. The \mapstochar is not just a vertical line, but has a blip in the middle on the right hand side that effectively ruins it for any other purpose. I told my colleague to use a rule and he did. I know from something that appeared in UKTeX a ffew weeks ago that rules are expensive in space. There is a reason for this. It requires 4 real numbers to specify a rule (the space of rules is a 4-manifold and fewer numbers will not do, no matter how you describe them). [ dek: not true; 3 numbers (height, width, depth) suffice in context ] Possibly 4 16 bit numbers would have given sufficient precision, but Knuth coded all dimensions as 32 bit numbers. So, it presumably takes 16 bytes to specify a rule and it is going to be much more wasteful of space to use a rule than it would have been to use the \mapstochar. Is this correct? More to the point, how can one find out about coding TeX to optimize for space? For time? Knuth drops a few clues in the discussion on pp. 373-374, but that is almost the only place this is done. For instance, can anyone tell me the relative cost of factoring macros into smaller ones, assuming you never reuse the pieces? Michael Barr ------- Date: Fri, 22 Nov 91 17:07:28 GMT From: Chris Thompson Subject: This and that Barbara, You write > there was another in that category reported just > today by michael barr -- the \mapstochar. if you read comp.text.tex, > look for his report, because it's asking a couple more basic questions, > namely how much memory space do certain techniques require, and what's > the most efficient way to do certain things. I follow comp.text.tex only intermittently, as its volume is really rather high. I took a look at Michael Barr's posting, and have posted a reply. He is certainly right about \mapstochar: the TeXbook said "322F in 1984, and the latest texbook.tex from labrea still says it; on the other hand plain.tex has always (correctly) had "3237 since 1.0 (I am fairly sure of this: despite the absence of a plain.tex.history file, I do do compares of old with new each time I upgrade and note down the salient changes). Chris Thompson <<< end \arrowvert code, plain.tex ************************************************************************ >>> MF -- bugs or features? (also, some ACP errata) Date: Tue, 22 Oct 91 12:04:23 +0100 From: schoepf@sc.ZIB-Berlin.DE (Rainer Schoepf) Organization: Konrad-Zuse-Zentrum fuer Informationstechnik Berlin Subject: Questionable features of Metafont Barbara, here is the report about two features of Metafont that I find questionable. I hesitate to call them bugs as it is said nowhere in the book that Metafont should not behave that way. Number 1: --------- The book says that addto V also P; is "essentially the same as" V := V + P; But this is only true if the evaluation of the picture expression P does *not* change the value of the picture variable V as a side effect. The second expression is correctly evaluated left to right. The first one, however, uses the value of V *after* P has been evaluated. Looking into the program one sees that "addto" reads the token list for V, evaluates the expression P, and converts the token list for P into an edge structure afterwards. I assume that the same behaviour happens with "cull". [ dek: I suppose so -- just as you would expect in C when comparing x=x+f(x) to x+=f(x) when f has side effects ] Number 2: --------- Define the following macro: def xxx = begingroup save x; newinternal x; .... endgroup enddef; After a hundred expansions Metafont gives you an "capacity exceeded" error since every call to newinternal statically allocates a slot in an internal array, which is not freed again at the end of the group. However, in this case, it is very easy to free the slot again. [ dek: ^^^^^^^^^ STRONGLY DISAGREE that _any_ change can be described as ``very easy''! Bugs or features? At least, this behaviour should be documented! [ dek: Maybe in TUGboat. Certainly the ``capacity exceeded'' error tells you that you've exceeded the number of internals. ] [ ... ] Rainer <<< end MF -- bugs or features? (also, some ACP errata) ************************************************************************ >>> MFbook errata Date: Tue, 5 Nov 1991 05:48:03 +0100 From: Lutz Birkhahn Subject: Errors in METAFONTbook (C&T Vol. C) Barbara, just for the record, here are some minor bugs in the METAFONTbook (C & T vol. C) index: "openwindow", "or", and "string" each are METAFONT primitives, so they deserve to get a starred entry (preceded with an asterisk `*') in the index on pages 353, 354, and 356, respectively. This error shows up in my edition from 1986 (first printing, I think) as well as in the source code I have, stating "Fifth printing, revised, March 1990" (although the C & T Publication info table you posted recently said that the 4th printing of Volume C, Sept 1991, is the latest...). [ dek: 3 x $2.56 many thanks C354^2 C356 ] Bye, Lutz Lutz Birkhahn (Germany) email: lutz@bisun.nbg.sub.org (don't use another!) F"urther Str. 6 +-------------------------------------------------- D-W-8501 Cadolzburg 2 | "It is an error to not have enough arguments" Voice: 09103 / 2886 | (Hype Programmer's Guide) <<< end MFbook errata [ dek: notes to myself only boolean was done as I had intended 353 numeric 356 string 357 transform 354 openwindow or pair path pen picture ] ######################################################################## %%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % Character code reference %%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % % Upper case letters: ABCDEFGHIJKLMNOPQRSTUVWXYZ % Lower case letters: abcdefghijklmnopqrstuvwxyz % Digits: 0123456789 % Square, curly, angle braces, parentheses: [] {} <> () % Backslash, slash, vertical bar: \ / | % Punctuation: . ? ! , : ; % Underscore, hyphen, equals sign: _ - = % Quotes--right left double: ' ` " %"at", "number" "dollar", "percent", "and": @ # $ % & % "hat", "star", "plus", "tilde": ^ * + ~ % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%% [ end of message 039 ]