diff options
author | Norbert Preining <norbert@preining.info> | 2021-05-27 03:01:40 +0000 |
---|---|---|
committer | Norbert Preining <norbert@preining.info> | 2021-05-27 03:01:40 +0000 |
commit | 5f1cfa686748068fedb95d8dafda3dc7f999c948 (patch) | |
tree | 874fa8430be12fe4633924f3b707428170316a46 /info | |
parent | 8982c52e00ffb3fb5a913fc60913ebd9070f091a (diff) |
CTAN sync 202105270301
Diffstat (limited to 'info')
-rw-r--r-- | info/digests/tex-implementors/README | 18 | ||||
-rw-r--r-- | info/digests/tex-implementors/message.22 (renamed from info/digests/tex-implementors/022) | 0 | ||||
-rw-r--r-- | info/digests/tex-implementors/message.23 (renamed from info/digests/tex-implementors/023) | 0 | ||||
-rw-r--r-- | info/digests/tex-implementors/message.24 (renamed from info/digests/tex-implementors/024) | 0 | ||||
-rw-r--r-- | info/digests/tex-implementors/message.25 (renamed from info/digests/tex-implementors/025) | 0 | ||||
-rw-r--r-- | info/digests/tex-implementors/message.26 (renamed from info/digests/tex-implementors/026) | 0 | ||||
-rw-r--r-- | info/digests/tex-implementors/message.27 (renamed from info/digests/tex-implementors/027) | 0 | ||||
-rw-r--r-- | info/digests/tex-implementors/message.28 (renamed from info/digests/tex-implementors/028) | 0 | ||||
-rw-r--r-- | info/digests/tex-implementors/message.29 (renamed from info/digests/tex-implementors/029) | 0 | ||||
-rw-r--r-- | info/digests/tex-implementors/message.30 (renamed from info/digests/tex-implementors/030) | 0 | ||||
-rw-r--r-- | info/digests/tex-implementors/message.31 (renamed from info/digests/tex-implementors/031) | 0 | ||||
-rw-r--r-- | info/digests/tex-implementors/message.32 (renamed from info/digests/tex-implementors/032) | 0 | ||||
-rw-r--r-- | info/digests/tex-implementors/message.33 (renamed from info/digests/tex-implementors/033) | 0 | ||||
-rw-r--r-- | info/digests/tex-implementors/message.34 (renamed from info/digests/tex-implementors/034) | 0 | ||||
-rw-r--r-- | info/digests/tex-implementors/message.35 (renamed from info/digests/tex-implementors/035) | 0 | ||||
-rw-r--r-- | info/digests/tex-implementors/message.36 (renamed from info/digests/tex-implementors/036) | 0 | ||||
-rw-r--r-- | info/digests/tex-implementors/message.37 (renamed from info/digests/tex-implementors/037) | 0 | ||||
-rw-r--r-- | info/digests/tex-implementors/message.38 (renamed from info/digests/tex-implementors/038) | 0 | ||||
-rw-r--r-- | info/digests/tex-implementors/message.39 (renamed from info/digests/tex-implementors/039) | 0 | ||||
-rw-r--r-- | info/digests/tex-implementors/message.40 (renamed from info/digests/tex-implementors/040) | 0 | ||||
-rw-r--r-- | info/digests/tex-implementors/message.41 (renamed from info/digests/tex-implementors/041) | 0 | ||||
-rw-r--r-- | info/digests/tex-implementors/message.42 (renamed from info/digests/tex-implementors/042) | 0 | ||||
-rw-r--r-- | info/digests/tex-implementors/message.44 | 1290 | ||||
-rw-r--r-- | info/digests/tex-implementors/message.45 | 1596 |
24 files changed, 2904 insertions, 0 deletions
diff --git a/info/digests/tex-implementors/README b/info/digests/tex-implementors/README new file mode 100644 index 0000000000..1044fd91a4 --- /dev/null +++ b/info/digests/tex-implementors/README @@ -0,0 +1,18 @@ +(Version of 2021-05-26.) + +This directory contains messages posted to the original incarnation of +the private tex-implementors list, from around November 1987 to January 1995. +Some of the messages are from Knuth, and comments from Knuth are +interspersed with some of the reports. + +Messages 20, 21, and 43 are absent, for unknown reasons. + +Additional files *.bug and others are also from around that time. +The labrea* files are file listings of what was on the main +Stanford distribution server (labrea.[cs.]stanford.edu) at various dates. + +For questions or comments about this material, the best place to post is +the public list, tex-k@tug.org (https://lists.tug.org/tex-k). + +For other past updates to TeX and Metafont, and information on reporting +new bugs, the list of known bugs, etc., see https://tug.org/texmfbug. diff --git a/info/digests/tex-implementors/022 b/info/digests/tex-implementors/message.22 index 5840761828..5840761828 100644 --- a/info/digests/tex-implementors/022 +++ b/info/digests/tex-implementors/message.22 diff --git a/info/digests/tex-implementors/023 b/info/digests/tex-implementors/message.23 index ecd29551b0..ecd29551b0 100644 --- a/info/digests/tex-implementors/023 +++ b/info/digests/tex-implementors/message.23 diff --git a/info/digests/tex-implementors/024 b/info/digests/tex-implementors/message.24 index 2a939b131c..2a939b131c 100644 --- a/info/digests/tex-implementors/024 +++ b/info/digests/tex-implementors/message.24 diff --git a/info/digests/tex-implementors/025 b/info/digests/tex-implementors/message.25 index 843358cfb4..843358cfb4 100644 --- a/info/digests/tex-implementors/025 +++ b/info/digests/tex-implementors/message.25 diff --git a/info/digests/tex-implementors/026 b/info/digests/tex-implementors/message.26 index d1cafa76fc..d1cafa76fc 100644 --- a/info/digests/tex-implementors/026 +++ b/info/digests/tex-implementors/message.26 diff --git a/info/digests/tex-implementors/027 b/info/digests/tex-implementors/message.27 index 7e7cbb25af..7e7cbb25af 100644 --- a/info/digests/tex-implementors/027 +++ b/info/digests/tex-implementors/message.27 diff --git a/info/digests/tex-implementors/028 b/info/digests/tex-implementors/message.28 index a8091fcaad..a8091fcaad 100644 --- a/info/digests/tex-implementors/028 +++ b/info/digests/tex-implementors/message.28 diff --git a/info/digests/tex-implementors/029 b/info/digests/tex-implementors/message.29 index e570480dd2..e570480dd2 100644 --- a/info/digests/tex-implementors/029 +++ b/info/digests/tex-implementors/message.29 diff --git a/info/digests/tex-implementors/030 b/info/digests/tex-implementors/message.30 index ae42aa301a..ae42aa301a 100644 --- a/info/digests/tex-implementors/030 +++ b/info/digests/tex-implementors/message.30 diff --git a/info/digests/tex-implementors/031 b/info/digests/tex-implementors/message.31 index 467fe56f78..467fe56f78 100644 --- a/info/digests/tex-implementors/031 +++ b/info/digests/tex-implementors/message.31 diff --git a/info/digests/tex-implementors/032 b/info/digests/tex-implementors/message.32 index 0f9426bccf..0f9426bccf 100644 --- a/info/digests/tex-implementors/032 +++ b/info/digests/tex-implementors/message.32 diff --git a/info/digests/tex-implementors/033 b/info/digests/tex-implementors/message.33 index dffe11ce22..dffe11ce22 100644 --- a/info/digests/tex-implementors/033 +++ b/info/digests/tex-implementors/message.33 diff --git a/info/digests/tex-implementors/034 b/info/digests/tex-implementors/message.34 index 72f510eb97..72f510eb97 100644 --- a/info/digests/tex-implementors/034 +++ b/info/digests/tex-implementors/message.34 diff --git a/info/digests/tex-implementors/035 b/info/digests/tex-implementors/message.35 index d4412eba65..d4412eba65 100644 --- a/info/digests/tex-implementors/035 +++ b/info/digests/tex-implementors/message.35 diff --git a/info/digests/tex-implementors/036 b/info/digests/tex-implementors/message.36 index 1a9a31fa85..1a9a31fa85 100644 --- a/info/digests/tex-implementors/036 +++ b/info/digests/tex-implementors/message.36 diff --git a/info/digests/tex-implementors/037 b/info/digests/tex-implementors/message.37 index f19a3018a3..f19a3018a3 100644 --- a/info/digests/tex-implementors/037 +++ b/info/digests/tex-implementors/message.37 diff --git a/info/digests/tex-implementors/038 b/info/digests/tex-implementors/message.38 index 1a72ea20b1..1a72ea20b1 100644 --- a/info/digests/tex-implementors/038 +++ b/info/digests/tex-implementors/message.38 diff --git a/info/digests/tex-implementors/039 b/info/digests/tex-implementors/message.39 index 8dd5efb829..8dd5efb829 100644 --- a/info/digests/tex-implementors/039 +++ b/info/digests/tex-implementors/message.39 diff --git a/info/digests/tex-implementors/040 b/info/digests/tex-implementors/message.40 index 12ca5aa7ab..12ca5aa7ab 100644 --- a/info/digests/tex-implementors/040 +++ b/info/digests/tex-implementors/message.40 diff --git a/info/digests/tex-implementors/041 b/info/digests/tex-implementors/message.41 index ebf24c72f8..ebf24c72f8 100644 --- a/info/digests/tex-implementors/041 +++ b/info/digests/tex-implementors/message.41 diff --git a/info/digests/tex-implementors/042 b/info/digests/tex-implementors/message.42 index 89cfb879cf..89cfb879cf 100644 --- a/info/digests/tex-implementors/042 +++ b/info/digests/tex-implementors/message.42 diff --git a/info/digests/tex-implementors/message.44 b/info/digests/tex-implementors/message.44 new file mode 100644 index 0000000000..c2defa8449 --- /dev/null +++ b/info/digests/tex-implementors/message.44 @@ -0,0 +1,1290 @@ +TeX 3.14159 and other updates -- file 1 of 2 + +This and the following messages contain the details of bug reports +sent to Don Knuth, edited somewhat for brevity, and his responses. + +As already announced, the new release -- TeX 3.14159, MF 2.718 and +related TeX- and MFware -- is at labrea.stanford.edu in the file +~ftp/alpha/tex95.tar.gz . No arrangements have been made yet to +install the unpacked versions into the /tex area at labrea, from +which it can be mirrored to CTAN; I will try to do that as soon +as possible. + +This message begins with a complete contents list of the main topics +in this collection, to help you find items of interest quickly. I +have just sent out the reward checks with the annotated originals +of the reports as Don returned them to me. They should be arriving +at their destinations soon. + + +######################################################################## + +Contents: + >>> TeXbook / MFbook / documentation bugs + +++ glitch in errata.five at labrea + +++ MFbook, page 134 and others from Robert Hunt + +++ MFbook, page 143 + +++ MFbook, several from Denis Roegel + +++ Spurious TAB in errorlog.tex + >>> The TeX program + +++ trap_zero_glue bugette + +++ font_mem_max and other memory parameters + [ continued in file message.045 ] + >>> plain.tex + +++ \oalign and \d{} + +++ hyphenation inhibited by struts + +++ TeXbook, page 363, in \endinsert + >>> Metafont + +++ arithmetic overflow with z=whatever[z',z''] + +++ several reports from Bogus{\l}aw Jackowski + >>> CM fonts + +++ missing "cmchar"s in bigdel.mf + +++ shaved_stem vs. cap_stem in greeku.mf + +++ miscellanea from Robert Hunt, mostly in CM sources + +++ cap_ess in cmmi12 and larger + +++ possible glitch in cmbx5 and cmbx6 + +++ arithmetic overflow in CMinch + +++ sterling sign + >>> Fontware + +++ testfont.tex + +++ VPtoVF + +************************************************************************ +[ dek -- + Robert Hunt: C134 $2.56, C207 $2.56, C257 $2.56, A354 $2.56, + A359 $2.56, A360 $2.56, A361 $2.56, A362 $2.56, + A362 $2.56, E95(97) $2.56, E187 $2.56, E113 $2.56, + E233 $2.56, E438 $2.56, C129 $2.56, E491 $2.56 + Chris Thompson: C206 $2.56, TeX\S549 $327.68 + Michael Barr: A357 $2.56 + Peter Schmitt: C143 $.32 + Marek Ry\'cko: A31 $2.56 + Bogus\l{}aw Jackowski: MF\S815 $327.68, CSCSPU bugfix $2.56 + Denis B. Roegel: C94 $2.56, C107 $2.56, C355 $2.56 + Eberhard Mattes: TeX\S634 $2.56 + Jim Sterken: TeX\S625 $2.56 + Rainer Schoepf: B503 $2.56 + Bernd Raichle: A374 $.32 + Barbara Beeton: C354 $2.56 + Berthold Horn: TeX\S1323 $20.48 + Pierre MacKay: E291 $.32 + Walter Carlip: TeX\S717 $10.24 + Andrew K. Trevorrow: TeX\S549 $20.48 + Yannis Haralambous: E239 $2.56 + J"org Knappen: A356 $2.56 + Petr Sojka: A356 $2.56 + Ulrik Vieth: A363 $2.56 +] + +>>> TeXbook / MFbook / documentation bugs + + +++ glitch in errata.five at labrea + +in errata.five: + \bugonpage C282, the three lines following the chart (9/39/89) +should be ^ + \bugonpage C282, the three lines following the chart (9/30/89) +[ dek * ] + + ---------------------------------------------------------------------- + + +++ MFbook, page 134 and others from Robert Hunt + +Date: Thu, 16 Apr 92 15:57:44 BST +From: Chris Thompson <CET1@phx.cam.ac.uk> +To: Barbara Beeton <BNB@MATH.AMS.COM> +Cc: Robert Hunt <REH10@phx.cam.ac.uk> +Subject: MFbook p.134 bug from Robert Hunt + +Here is another one from Robert: + +> MFbook, page 134 (line 7933 of mfbook.tex) should read +> ...if $t\le 0$, precontrol~$t$ of~$p$ is~$z_0$. +> (rather than $z_n$). +[ dek -- $2.56 +] + +He's right. The z_n has somehow got duplicated from the previous +sentence. + +Chris Thompson +JANET: cet1@uk.ac.cam.phx +Internet: cet1@phx.cam.ac.uk +------- +Date: Thu, 07 May 92 22:37:53 BST +From: Chris Thompson <CET1@phx.cam.ac.uk> +To: Barbara Beeton <BNB@MATH.AMS.COM> +Cc: Robert Hunt <REH10@phx.cam.ac.uk> +Subject: Miscellany from Robert Hunt + +Barbara, + + Here are three things from Robert Hunt (his messages to me marked +with ">"): + +1. (7 May): +[ this has been resolved already ] + +2. (22 Apr, after I had been publicising the errata.* files locally): +> Is there any way of telling how far back it's necessary to go through +> the "Bugs in Computers and Typesetting" files in order to make sure +> that you have all the necessary changes? I very recently bought a copy +> of the softback version of the METAFONTbook, which says "6th printing, +> revised, February 1991" inside; but some of the changes listed in even +> only the third file (which covers the period up to June 1987) have not +> been made to it. As a typical example, the correction to page 14 (to +> mention Paul de Casteljau as the discoverer of the recursive midpoint +> rule) has not been made; but the correction to page 348, to include +> his name in the index, has! The same is true of the bugs listed in the +> fourth file and so on, which makes the book somewhat inconsistent in +> places. Is it possible that the printers have accidentally lost some +> of the updates, perhaps? +[ dek -- yes + AW totally screwed this up and i was bl**dy *ngry +] + +I must admit I didn't entirely believe this until Robert actually +turned up with his copy of the book today: the example he gives is +certainly correct. Very odd. Do you know whether anything more than +usually peculiar happened to the 6th softcover printing? (The current +mfbook.tex at labrea purports to represent the 7th softcover printing.) +If not, who could answer Robert's questions? + +3. (7 May): +> My candidate for the most trivial error in the METAFONTbook: on page +> 207, line 10, "-.00005" should read "-0.0005". + +Yes, that is an error, not yet fixed in mfbook.tex. But I'm sure we can +find one yet more trivial, can't we? ... + +Actually, I tried to reproduce the numbers on pages 206-207 by +[ dek -- $2.56 +] +compiling io.mf (from labrea) with mode=lowres;autorounding:={0 or 1}; +tracingspecs:=1 and I get numbers a teeny bit different from what is +in the text. For example, instead of "point (10.85146,-0.0005), where +there was a horizontal tangent, has been rounded to (10.85872,0)", I get +(10.85147,-0.00049) and (10.85873,0). Maybe the rounding details in MF +have changed since DEK did the run that produced these numbers. +[ dek -- $2.56 + Yes that was either bug #550 or 560. or both +] + +Chris Thompson +JANET: cet1@uk.ac.cam.phx +Internet: cet1@phx.cam.ac.uk +------- +Date: 19 May 1992 22:50:35 -0300 (BST) +From: Chris Thompson <CET1@phx.cam.ac.uk> +Subject: Yet another MFbook bug from Robert Hunt + +Barbara, + + The following from Robert Hunt (11 May; I was ill last week and +am only now getting round to clearing some of the backlog): +[ dek -- (and here i sit on a chilly day in California 26 Feb 199_5_, + coughing as I try to reduce the _secondary_ backlog.) + Hope you're feeling better by now, Chris! +] + +> On page 257 of the METAFONTbook, line 5 (the large centred display), +> the bracketed entries |numeric| |<| |numeric| (etc.) should read +> \<numeric> |<| \<numeric> instead. +[ dek -- $2.56 + (maybe should be $2.57 instead?) +] + +He's right: the two stacks (boolean, numeric, pair, string, transform) +should be <...> types, not boldface words, for consistency with the +rest of Appendix B. Not fixed in the latest mfbook.tex available to me. + +Chris Thompson +------- +[ dek -- However -- Why was I not told this in 1992 or 1993? + I could then have fixed the final printing of MFbook. + Changes since 93 affect the electronic copy _only_; + the hardcopy is frozen now for vols A, B, C, E. +] + + ---------------------------------------------------------------------- + + +++ MFbook, page 143 + +Date: Thu, 08 Jul 93 15:03:58 MEZ +From: Peter Schmitt <A8131DAL@AWIUNI11.EDVZ.UniVie.AC.AT> +To: INFO-TEX <@cunyvm.cuny.edu:INFO-TEX@SHSU.BITNET> +Subject: bugs in MFbook and TeXbook + +Since this topic is just discussed: + I recently noticed two `bugs' in the MFbook which + --- as far as I could see from the Errata --- have not + yet been corrected: + +%%%% +The METAFONTbook +Fourth printing, revised, September 1991 + +[ first one has been fixed ] + +page 143, line 2 : `giving the next exprs:' + should read `giving the next expressions:' +%%%% + +[...] + +Peter + +Peter Schmitt a8131dal@awiuni11.edvz.univie.ac.at + schmitt@awirap.bitnet +----------------------------------------------------------------------------- +Institute of Mathematics Strudlhofgasse 4 +[ dek -- great name ^^^^^^^^^^^^^^ +] +University of Vienna A-1090 Wien + Austria +------- +Date: 08 Jul 1993 15:37:56 -0300 (BST) +From: Chris Thompson <CET1@phx.cam.ac.uk> +To: Peter Schmitt <A8131DAL@AWIUNI11.EDVZ.UNIVIE.AC.AT> +Subject: Re: [bugs in MFbook and TeXbook] + +Reply to Peter Schmitt, copied to Barbara Beeton. + +[...] + +> page 143, line 2 : `giving the next exprs:' +> should read `giving the next expressions:' +> %%%% + +This is unchanged in the most recent mfbook.tex available to me. +It does read rather oddly. I wonder whether the 'expr' was meant +to be in \tt? +[ dek -- 32\cents +] + +Chris Thompson +------- +[ dek -- Not an error -- when you input _expr.mf_ the computer types + _``Gimme an expr: ''_ and I was just appropriating that + neologism into English. Like `ftp' and `grep'. + However I do admint that a reasonable person might wonder at + my idiosyncratic style, so I'll change to \tt and pay the + normal reward of 32\cents for suggestions. +] + + ---------------------------------------------------------------------- + + +++ MFbook, several from Denis Roegel + +Date: 04 May 1994 16:58:42 +0200 +From: "Denis B. Roegel" <Denis.Roegel@loria.fr> +Cc: roegel@lorraine.loria.fr (Denis B. Roegel) +Subject: bugs in the METAFONTbook + +Mrs Beeton, + +I found two small bugs in my copy of the +METAFONTbook (hardcopy). I went through the last +erratas and found no mention of them. + +Here they are: + +1) page 94: last paragraph, 4th line: the word "are" + is duplicated. +[ dek -- $2.56 +] + +2) [resolved ] + +Thak you, + +Denis. (roegel@loria.fr) +------- +Date: 05 May 1994 17:14:40 +0200 (MET DST) +From: "Denis B. Roegel" <Denis.Roegel@loria.fr> +Subject: Re: bugs in the METAFONTbook + +[...] + +Maybe there is another bug in the MFbook: + +In the first paragraph of page 115, the instruction +"endchar" in the program at the end of chapter 12 +is mentionned. However, there is no "endchar" in +the program at the end of chapter 12. +[ dek -- $2.56 page 107 +] + +Denis. +------- +(reply, 05 May 1994) +thanks for your additional report. +the "dangerous bend" program in the file manfnt.mf is just a bit +different from what is in the mfbook, and does end with an +"endchar" -- preceded by another line not in the mfbook. for +some reason, this bug (i'm sure it is!) sounds familiar to me, +but i can't find a reference, and it's not corrected in any of +the errata files. +onto the dek list it goes ... +cheers. -- bb +------- + + ---------------------------------------------------------------------- + + +++ Spurious TAB in errorlog.tex + +[ from comp.text.tex, 21 Jan 95 ] +Date: 20 Jan 1995 12:38:36 GMT +From: schwab@issan.informatik.uni-dortmund.de (Andreas Schwab) +Subject: Spurious TAB in errorlog.tex + +There is a spurious TAB in the file systems/knuth/errata/errorlog.tex, +as found on the CTAN, in line 2867, containing the text "(Mattes and +Raichle). @1036". This TAB (after the word Mattes) causes a Greek Psi +[ dek * ] +to be typeset where a space should have been, looking a bit funny :-). + +-- +Andreas Schwab "And now for something +schwab@issan.informatik.uni-dortmund.de completely different" +=========================================================================== +[ dek -- _Thanks_ +] + +<<< end TeXbook / MFbook / documentation bugs + +************************************************************************ + +>>> The TeX program + + +++ trap_zero_glue bugette + +Date: 28 Oct 1993 16:26:02 +0000 (GMT) +From: Chris Thompson <CET1@phx.cam.ac.uk> +To: Rainer Schoepf <Schoepf@sc.ZIB-Berlin.DE> +Subject: Re: [interesting effect in overfull box printout] + +Rainer, + +Yes, I think you have discovered a bugette. CC'ing this to Barbara. + +You write (omiting the history as to why you were changing latex.tex) +> +> Studying TeX the program I found what I think is an oversight: +> whenever a glue node is generated, either when scanning a glue +> specification in assignment, as well as in glue register arithmetic, +> the procedure trap_zero_glue is called to replace references to zero +> glue to a reference to the special object zero_glue. + +Actually, this is a bit too strong. |trap_zero_glue| is only called +when setting a `glue register or parameter', as the preamble to section +1229 says. For example, in + + \setbox0=\hbox{Foo\hskip 0pt plus 0pt minus 0pt Bar} + +the glue node doesn't point to |zero_glue|, but to a private |glue_spec| +with zero contents. + +> The only +> exception to this rule is scanning the glue specification after +> \tabskip in preparation of an alignment preamble. Therefore, +> +> \tabskip=\z@ +> +> generates a new glue node with zero fields, whereas +> +> \tabskip=\z@skip +> +> generates only a reference to zero_glue. + +I agree. This breaks the invariant promised in #1229. +[ dek -- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +] + +> Now, since the overfull box +> printer checks only for equivalence with zero_glue, a blank is printed +> in the first case. + +[The code in |short_display| (section 175)] + +> The only other difference I could find is in TeX's +> processing of alignment entries: in a certain case the tabskip glue +> reference is replaced by zero_glue unless it is already zero_glue, +> i.e. this code is executed without it really being necessary. + +I can find no way other than |short_display| of making the difference +visible, which is why I call it a bugette rather than a bug. Some +glue parameters are tested for being zero by pointer comparison with +|zero_glue|, but \tabskip isn't one of them. + +> I cannot think of a reason why this behaviour should influence +> anything other than the overfull box printing, yet I think it should +[ dek -- also tracingparagraphs \S857 +] +> be changed in the next update to tex.web. It seems to me that a simple +> call to trap_zero_glue should suffice. + +Specifically, in |get_preamble_token|, section 782. There will need +to be a forward declaration of |trap_zero_glue| as well. +[ dek -- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +] + +> What do you think? + +I think it should go on Barbara's list for Don. + +Chris Thompson +------- +Date: 28 Oct 1993 17:39:56 +0100 +From: schoepf@sc.ZIB-Berlin.DE (Rainer Schoepf) +To: Chris Thompson <CET1@phx.cam.ac.uk> +Cc: Barbara Beeton <BNB@MATH.AMS.ORG>, Rainer Schoepf <Schoepf@sc.ZIB-Berlin.DE> +Subject: Re: [interesting effect in overfull box printout] + +Chris, + +I wrote: + + > > The only other difference I could find is in TeX's + > > processing of alignment entries: in a certain case the tabskip glue + > > reference is replaced by zero_glue unless it is already zero_glue, + > > i.e. this code is executed without it really being necessary. + +to which you replied: + + > I can find no way other than |short_display| of making the difference + > visible, which is why I call it a bugette rather than a bug. + +I agree. + + > Some + > glue parameters are tested for being zero by pointer comparison with + > |zero_glue|, but \tabskip isn't one of them. + +But it is, in the piece of code labelled +[ dek -- ---? that's _not_ a pointer comparison to zero_glue +] + + <Nullify |width(q)| and the tabskip glue following this column@> + +If I understand this correctly, the local variable s points to a copy +of the tabskip glue of that point. But that doesn't influence the +outcome in any way. +------- +Date: 28 Oct 1993 18:06:22 +0000 (GMT) +From: Chris Thompson <CET1@phx.cam.ac.uk> +To: Rainer Schoepf <Schoepf@sc.ZIB-Berlin.DE> +Subject: Re: [interesting effect in overfull box printout] + +Rainer, + +> > Some +> > glue parameters are tested for being zero by pointer comparison with +> > |zero_glue|, but \tabskip isn't one of them. +> +> But it is, in the piece of code labelled +> +> <Nullify |width(q)| and the tabskip glue following this column@> +> +> If I understand this correctly, the local variable s points to a copy +> of the tabskip glue of that point. But that doesn't influence the +> outcome in any way. + +Maybe I expressed that wrongly. I meant that there were no cases of +comparing \tabskip directly out of |equiv(glue_base+tab_skip_code)| +with |zero_glue|, in the way that there is for \spaceskip and +\xspaceskip in |main_control|, for example. The code in section 802 +that you mention is comparing glue copied from \tabskip (sharing its +|glue_spec|, admittedly) and as you say it doesn't effect the outcome, +as the test against the glue already being |zero_glue| is only an +optimization and could be omitted entirely. + +Chris Thompson +Internet: cet1@phx.cam.ac.uk +JANET: cet1@uk.ac.cam.phx +------- +[ dek -- I hesitate to change anything here, on the off chance that I did + have a reason for the ``redundant'' code in \S802 ... something + way back in my memory warns me to leave this alone. I will just + change the slightly-false comment in \S1229. + Of course I am 99.9999% certain that I could safely make the + change you suggest, but it is a big pain to handle the forward + referencing [I probably would put \S1229 into a section of its + own named Declare the procedure trap_zero_glue, and place that + in 782.] -- requires reprinting many pages of the book. Much + too much trouble for very little gain at this late late stage. +] + + ---------------------------------------------------------------------- + + +++ font_mem_max and other memory parameters + +Date: 17 Dec 1993 16:01:52 -0500 (EST) +From: Berthold Horn <71172.524@CompuServe.COM> +Subject: Re: where to send bug report + +Dear Barbara: + +[...] + +[ dek * ] +(1) OK, here it is. I don't know whether to call it a `real' bug since it +only comes up if one implements Knuth's scheme for growing +main memory in TeX (which is why TeX implementers haven't +run into it before --- except possibly Barry Smith? with Textures). +But then Knuth did describe how it is supposed to work... + +In 174 (page 71 of `TeX: the program') it should say: + + begin while p \ne null do +[ dek -- No this is not robust in the presence of clobbered lists -- You + are asking me to _undo_ one of the important corrections I made + years ago. +] + +instead of: + + begin while p > mem_min do + +On machines with fixed main memory (or in iniTeX), these happen to be +equivalent because` mem_min' is zero, just as `null' is zero. But when +[ dek -- ?? null is -30000 on my system at home, for instance. +] +memory grows downwards, then `mem_min' is negative, and one can get +caught in a delightful infinite loop while looking for the null at the end of +a list! The same problem occurs in 182 (page 74), Fortunately nowhere else. + +An alternate `fix' would be to redefine null to be the same as memmin, +but that would be a very poor solution since in dynamic allocation, +mem_min changes from time to time. + +(2) While I have your attention, I'd like to complain about a recent +implementaiton decision +that is a pain for dynamic memory allocation. For `bcharlabel' is used +`fontmemptr'. For a system with fixed allocations, this is a reasonable +[ dek - ^^^ size +] +way to say this doesn't point to any valid font, but its no good if font memory +can grow. I replaced this with `maxhalfword', which is fixed. Plus, when a +format file is read in, I try and figure out what value of fontmemptr was used +when it was dumped and replace that with `maxhalfword'. Its important for +a format file not too have too many frozen in dependencies on allocations. +One should be able to handle at least variations in size of main memory, +string pool size, font memory size, hyphenation table size etc. + +(3) By the way, I am wondering why we still seem to be using maxhalfword = +262144 +when there aren't really any 36 bit machines left (been I while since I hacked + on a PDP6 or PDP10 :=), and everyone is using +[ dek -- ^^^^^^^^ in fantasy land +] +64 bit words. Doesn't make sense in a 32 bit address space world... + +(4) Finally, I'd like to recommend that --- given that we are using 64 bit +words --- +the TeX 82 limitation in fontmax == 256 be lifted. We did this in Y&YTeX on +[ dek -- ^^^^^^^^^ + This would break the _Pascal_ implementation that still exists, + I think? +] +an experimental basis and it involves only a tiny change where font definitions +are written to the DVI file, and a tiny change where font changes are written +to the DVI file. DVI processors are already supposed to be able to +understand the multi-byte font commands (despite the fact that TeX 82 +never generates them) - although, the `level 0' standard does allow them +to support only 256 internal font numbers (a weird and wonderful contraction +if you ask me). + +[...] +[ dek -- These things are up to implementors' discretion. + Something in the back of my mind triggers a caution flag -- + not only in the memory for hyphenation but also in the \span + feature of alignments, I fear (?) Good luck. +] + +Berthold & Blenda. +------- +Date: 09 Mar 1994 16:59:50 -0500 (EST) +From: andrew.trevorrow@anu.edu.au (Andrew K Trevorrow) +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 +[ dek -- Now many compilers will refuse to pack properly +] + +@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} +@y +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 +------- +Date: 09 Mar 1994 11:08:17 -0500 (EST) +From: Louis Vosloo <71172.524@CompuServe.COM> +Subject: [andrew.trevorrow@anu.edu.au (Andrew K Trevorrow): new TeX bug] + +Dear Barbara: + +I believe I already reported on this problem. font_mem_max is used +[ dek -- ^^^ size +] +as a special value for bchar etc. Which is fine if font_mem_max never +changes, but for a `dynamic' TeX (like Y&YTeX) this doesn't work. + +My solution was to change this to max_half_word. + +In addition, my format undumping code tries to figure out +what value was used in the dumped format and then replaces that +systematically with max_half_word. +That way it can handle `old' format files made before the fix as well. + +Berthold K.P. Horn +71172.524@compuserve.com +------- +Date: 09 Mar 1994 11:25:40 -0500 (EST) +From: Berthold Horn <71172.524@CompuServe.COM> +Subject: [andrew.trevorrow@anu.edu.au (Andrew K Trevorrow): new TeX bug] + +Dear Barbara: + +The following is extracted from email I sent to you on 93/Dec/17. +The bug reported by Trevor is mentioned below in item (2) + +Regards, Berthold. + +... + +(1) OK, here it is. I don't know whether to call it a `real' bug since it +only comes up if one implements Knuth's scheme [...] + + [ remainder of message as above ] +------- +Date: 09 Mar 1994 17:02:14 +0000 (GMT) +From: Chris Thompson <CET1@phx.cam.ac.uk> +To: Barbara Beeton <BNB@MATH.AMS.ORG> +Cc: Andrew Trevorrow <andrew.trevorrow@anu.edu.au> +Subject: Andrew Trevorrow's new TeX bug + +Barbara, + + I am replying directly to you rather than to the tex-implementors list, +with a copy to Andrew. + +> ... 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.) +[ dek -- ^^^^^^ + exponentially decreasing, actually, although I am one year + behind plan (not two) +] + +About time :-) It gets later every year... +[ dek -- \check +] + +> 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. + +Yes, this is a bug, and a quite nasty one too. Introduced by the changes +in TeX version 3, so presumably Andrew only gets the smaller reward. +[ dek -- (Berthold) +] + +> 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. + +Putting |non_address| at the other end of the range seems to be the +right solution. I think it could equally well be set to 0 as to -1. +[ dek -- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +] +The values in the |bchar_label| array can never be this small naturally: +they are true indices into |font_info| rather than offset ones. + +There is a technical problem about making this change to TeX. One needs +[ dek -- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +] +to force old format files to be invalid, because the |non_address| +values in them would be wrongly interpreted (even more so than at +present, that is!). This wouldn't happen "naturally". + +My MVS version of TeX has hacks to make |font_index| a signed 16-bit +value, starting at |font_mem_base| (currently dumped in the format file) +rather than zero. I can foresee myself having to rework this... + +Chris Thompson +Cambridge University Computing Service +------- +Date: 09 Mar 1994 13:04:02 -0500 (EST) +From: bbeeton <BNB@MATH.AMS.ORG> +To: CET1@phx.cam.ac.uk +Cc: BNB@MATH.AMS.ORG, andrew.trevorrow@anu.edu.au +Subject: Re: Andrew Trevorrow's new TeX bug + +chris and andrew, +berthold horn has reminded me that he reported this bug in december; +i did forward his message to you then, chris, but it seems to have +got lost. attached is the forwarded message, along with some of +today's commentary from berthold. he avers that setting non_address +to -1 won't work under certain circumstances, and proposes another +solution that does work for him. + +this seems to be more contentious than i expected. perhaps a wider +discussion is warranted -- i've already received (but not read) +a few other messages on the subject, including one from peter +breitenlohner. +cheers. -- bb + -------------------- + +Date: 17 Dec 1993 16:27:33 -0500 (EST) +From: bbeeton <BNB@MATH.AMS.ORG> +To: cet1@cus.cam.ac.uk +Subject: [Berthold Horn <71172.524@CompuServe.COM>: Re: where to send bug + report] + +chris, +would appreciate it if you could verify this bug report, and +perhaps comment on the other points made in the message. + +best wishes for the holidays. + -- bb + --------------- + +Date: 17 Dec 1993 16:01:52 -0500 (EST) +From: Berthold Horn <71172.524@CompuServe.COM> +To: bbeeton <BNB@MATH.AMS.ORG> +Subject: Re: where to send bug report + +Dear Barbara: + +[...] + +(1) OK, here it is. I don't know whether to call it a `real' bug since it +only comes up if one implements Knuth's scheme [...] + + [ remainder of message as above ] + + -------------------- + +Date: 09 Mar 1994 11:08:17 -0500 (EST) +From: Berthold Horn <71172.524@CompuServe.COM> +To: bbeeton <BNB@MATH.AMS.ORG> +Subject: [andrew.trevorrow@anu.edu.au (Andrew K Trevorrow): new TeX bug] + +Dear Barbara: + +I believe I already reported on this problem. font_mem_max is used +as a special value for bchar etc. Which is fine if font_mem_max never +changes, but for a `dynamic' TeX (like Y&YTeX) this doesn't work. + +My solution was to change this to max_half_word. + +In addition, my format undumping code tries to figure out +what value was used in the dumped format and then replaces that +systematically with max_half_word. +That way it can handle `old' format files made before the fix as well. + +Berthold K.P. Horn +71172.524@compuserve.com +------- +Date: 09 Mar 1994 18:39:51 +0000 (GMT) +From: Peter Breitenlohner <PEB%DMUMPIWH.BITNET@vm.gmd.de> +To: bbeeton <BNB@MATH.AMS.ORG> +Subject: Re: [andrew.trevorrow@anu.edu.au (Andrew K Trevorrow): new TeX bug] + +Barbara, +1. this is definitely a bug +2. The fix is no good (incomplete). There is at least one place in + tex.web which now says + if bchar_label[hf]<non_address + and changing non_address from very large too very small requires a change + here too (I'll check if there are more places) +3. I dislike the change of font_index=0..font_mem_size into + font_index=-1..font_mem_size because on some systems that may have + the effect that 4 bytes instead 2 bytes are required for a font_index +4. I think one can safely set non_address=0 but I have to check that + and will send you a complete fix tomorrow. +5. I will also reformulate my "bug or design feature" msg from some + time ago and would like to ask you to forward it to don. +regards Peter +------- +(reply, 09 Mar 1994) +thanks much, peter. +[ forwarded all previous mail to peter ] +------- +Date: 09 Mar 1994 11:51:32 -0800 (PST) +From: drf@frame.com (David Fuchs) +Subject: Re: [andrew.trevorrow@anu.edu.au (Andrew K Trevorrow): new TeX bug] + +I'd forward it along to dek; [...] + + -drf +------- +(reply, 09 Mar 1994) +what's becoming clear about this particular bug is that it impinges +on some of the system-dependent areas, in particular, how various +implementors choose to implement the ability to change the size of +various memory blocks at run time. since more implementations do +have that ability now than formerly, and they all seem to be +implemented differently (though not all techniques are public), +this is potentially a rats nest. so information is important not +only on what the bug is and how you can make it happen, but what +else is related and where it might go wrong if fix x is adopted. +i think the present participants are capable of doing a pretty +thorough job. +------- +Date: 10 Mar 1994 11:27:26 +0000 (GMT) +From: Peter Breitenlohner <PEB%DMUMPIWH.BITNET@vm.gmd.de> +To: Barbara Beeton <bnb@MATH.AMS.ORG>, + Chris Thompson <cet1@phoenix.cambridge.ac.uk>, + Andrew Trevorrow <andrew.trevorrow@anu.edu.au>, + Berthold Horn <71172.524@compuserve.com> +Subject: andrews bug et alia + +hi barbara (and chris, andrew, berthold), +thanks for sending the various remarks, here my comments. + +1. andrews bug +yes, this definitely is a bug [...] since font_mem_size +is among those parameters that are explicitely allowed to differ between +VIRTEX and INITEX. + +andrews fix is bad for two reasons + a) the test ...<non_addres must be changed into ...>non_address + b) a bchar_label=-1 fails in undump where the value is tested to be + in the range 0..font_mem_size. +I did not think about Chris's point (invalidating old format files) but +had changed the test in undump anyway (general neatness) and this pays +[ dek - ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +] +nicely since it does catch the old formats that must be rebuilt when +non_address is changed from font_mem_size to 0 (not -1) as I would +recommend. + +I fully agree with Chris that non_address=0 is OK, and I strongly dislike +the -1 for various reasons (among others it unnecessarily forces font_index +to be signed instead of unsigned). + +I have looked into tex.web and am fully convinced that one can +safely set non_address=0 since font_info[0] is occupied +by the first of \nullfont's parameters. + +Here my proposed change: + +@x [30] m.549 l.10678 - bug fix +@d non_address==font_mem_size {a spurious |font_index|} +@y +@d non_address==0 {a spurious left boundary char label} +@z +%--------------------------------------- +@x [41] m.916 l.17965 - bug fix +if bchar_label[hf]<non_address then {put left boundary at beginning of new line} +@y +if bchar_label[hf]>non_address then {put left boundary at beginning of new line} +@z +%--------------------------------------- +@x [50] m.1323 l.24036 - bug fix +undump(0)(font_mem_size)(bchar_label[k]); +@y +undump(0)(fmem_ptr)(bchar_label[k]); +[ dek -- ^^ -1 +] +@z +%--------------------------------------- + +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.) + +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. + +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!! + +ad 1: I can't understand this problem. In VIRTEX mem_min must be <=mem_bot, +[ dek -- Might have lots of stuff between mem_bot and mem_min, with a + special allocation scheme +] +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<mem_bot-2 then mem[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. + +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. +[ dek -- \check +] + +regards peter +------- +Date: 10 Mar 1994 12:57:35 +0000 (GMT) +From: Chris Thompson <CET1@phx.cam.ac.uk> +To: Barbara Beeton <BNB@MATH.AMS.ORG> +Cc: Andrew Trevorrow <andrew.trevorrow@anu.edu.au>, + Peter Breitenlohner <PEB@DMUMPIWH.EARN>, + Berthold Horn <71172.524@CompuServe.COM> +Subject: Re: Andrew Trevorrow's new TeX bug + +Barbara, + +> berthold horn has reminded me that he reported this bug in december; +> i did forward his message to you then, chris, but it seems to have +> got lost. + +I found this message in an archive. Apologies: it arrived too late +to be dealt with before Christmas, and got completely forgotten +afterwards. If you have anything else outstanding on the potential +bug list that I haven't replied to you about, please remind me a.s.a.p. + +> this seems to be more contentious than i expected. perhaps a wider +> discussion is warranted -- i've already received (but not read) +> a few other messages on the subject, including one from peter +> breitenlohner. + +I agree with Peter Breitenlohner (personal communication) and with +Bernd Raichle (in tex-implementors): there is absolutely no doubt +that this is a bug. I don't think Wayne's position is defensible: +I will post something to tex-implementors saying so. + +The main thing is to make sure the bug report is on the list for +Don. We could argue about the merits of particular ways of fixing +it until the cows come home, but it is Don who will actually make +that decision. + +Peter, Andrew and I all seem happy with |non_address| = 0. Peter +writes + +> ... I strongly dislike the -1 for various reasons (among others it +> unnecessarily forces font_index to be signed instead of unsigned). + +(Although an alternative would be to make |bchar_label| an |integer| +array rather than a |font_index| one.) + +Berthold suggests |non_address| = |max_halfword|, but I think this is +not portable. While many implementations may squeeze |font_index| +values into halfwords (indeed, I do myself) there is nothing in tex.web +to prevent |font_mem_size| from being larger than |max_halford|. +[ dek -- ^^ w +] +(There is curiosity, though: |font_params| is an array of |halfword|s. +Can one break TeX by setting \fontdimen<amazingly large number>? I will +have to think about that one.) +[ dek * ] + +I didn't intend my point about forcing the invalidation of old format +files to be a big issue (there are many ways to achieve the desired +effect): just something not to be forgotten. Andrew writes: + +> Maybe it would be a good idea to put some sort of version number (the +> current TeX version?) in format files. I wonder if there is a spot +> that would be guaranteed to catch all old formats? A suitable error +> message would be "This is an old format file; use INITEX to rebuild +> it.". + +It shouldn't be the TeX version number, because sometimes a version +change does not require new format files, which is convenient when +it happens. I have in the past fiddled with the 69069 at the end of the +file to achieve deliberate invalidation in local implementations, but +to get something like Andrew's message consistently one would want +something right at the beginning. + +To take Berthold's 4 sections in order: + +1. The |null| test. (I suspect that this is the only part of the message + I even glanced at in December.) My first inclination is to agree with + Peter's analysis, but I need to go through this in detail again. I + will let you know. + +2. = Andrew's bug, discussed above. + +3. Why not |max_halfword| > 262144 ? This is a question relating to + a particular implementation. + +4. Why not |font_max| > |font_base| + 256 ? I have wondered about that + myself. I don't think I can improve on Peter's analysis: + +> 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!! + +No harm in suggesting it to Don, I suppose. If he doesn't like it, +it is always open to an implementor to provide this extension via +the change file. +[ dek -- right ... see also \span (?) +] + +Chris Thompson +Cambridge University Computing Service +------- +Date: 10 Mar 1994 14:09:12 +0000 (GMT) +From: Peter Breitenlohner <PEB%DMUMPIWH.BITNET@vm.gmd.de> +To: Berthold Horn <71172.524@CompuServe.COM> +Cc: Barbara Beeton <bnb@MATH.AMS.ORG>, + Chris Thompson <cet1@phoenix.cambridge.ac.uk> +Subject: Re: andrews bug et alia + +On 10 Mar 94 08:03:11 EST you said: +> +>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. +> +I think whenever you are dynamically allocating more mem-memory you should +1. never have mem_min<min_halfword=null and +[ dek - ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + Absolutely true (see \S116) +] +2. should never use mem[mem_min] (whatever the present mem_min value) unless + your proposed code change is made +3. never ever use mem[min_halfword]. +I agree a change in mod 174 ( p>mem_min => p<>null ) would be desirable +[ dek -- no, it could cause p to go outside the array bounds. +] +and would make life a little easier for those who want/have to dynamically +enlage mem at the low end. I only disagree that this can be called a bug. +The only point where standard TeX enlarges the low end of mem is when +a format is read and VIRTEX's mem_min is below INITEX's mem_bot. +And for this case Knuth's coding works fine, hence no bug +[ dek -- _NB_: show_mode_list, short_display are designed to avoid + crashing the system when TeX is buggy. See comment in \S182 +] + +regards peter +------- +Date: 12 Mar 1994 12:30:55 +0000 (GMT) +From: Peter Breitenlohner <PEB%DMUMPIWH.BITNET@vm.gmd.de> +To: Andrew K Trevorrow <andrew.trevorrow@anu.edu.au>, + Barbara Beeton <bnb@MATH.AMS.ORG> +Subject: Re: andrews bug et alia + +Hi Andrew, Barbara +On Sat, 12 Mar 94 14:14:40 EST you (andrew) said: +> +>By the way, I think that in your change to undump you should use +>fmem_ptr-1 rather than just fmem_ptr (which is the first UNUSED index +>in the font_info array). +> +To Andrew: That is indeed a good idea since it would catch old formats even +in the rare event that fmem_ptr=font_mem_size! +[ dek -- Actually I once noticed that "Web2C" omits the checking ... + We must make sure this test is _not_ skipped. +] +> +To Barbara: can you please append the above to my messsage with the proposed +fix. +> +regards peter +------- +Date: 10 Mar 1994 17:03:39 +0000 (GMT) +From: Chris Thompson <CET1@phx.cam.ac.uk> +To: Barbara Beeton <BNB@MATH.AMS.ORG> +Cc: Andrew Trevorrow <andrew.trevorrow@anu.edu.au>, + Peter Breitenlohner <PEB@DMUMPIWH.EARN>, + Berthold Horn <71172.524@CompuServe.COM> +Subject: Small TeX bug - \fontdimen <large-number> + +Barbara, + +I wrote: +> (There is curiosity, though: |font_params| is an array of |halfword|s. +> Can one break TeX by setting \fontdimen<amazingly large number>? I will +> have to think about that one.) + +There is, in fact, a bug here. The following code in TeX section 580, +part of |find_font_dimen|, + + begin repeat if fmem_ptr=font_mem_size then + overflow("font memory",font_mem_size); + font_info[fmem_ptr].sc:=0; incr(fmem_ptr); incr(font_params[f]); + until n=font_params[f]; + +contains no precautions to prevent |font_params[f]| from being +incremented from |max_halfword|, its largest legal value. What +happens next is implementation-dependant. In the case of the one +I was experimenting with, |halfword| values wrap quietly from +|max_halfword| to |min_halfword|, and so (for large enough |n|) +the loop test is never satisfied, and one gets a font memory +overflow condition (which is only mildly spurious). + +Possible fixes: make |font_params| an array of |integer|, or +|font_index| (maybe: not sure about this), instead of |halfword|. +Alternatively, in section 578 replace + + if n<=0 then cur_val:=fmem_ptr + +by + + if (n<=0) or (n>max_halfword) then cur_val:=fmem_ptr + +Chris Thompson +Cambridge University Computing Service +------- +Date: 12 Mar 1994 12:47:28 +0000 (GMT) +From: Peter Breitenlohner <PEB%DMUMPIWH.BITNET@vm.gmd.de> +To: Chris Thompson <CET1@PHOENIX.CAMBRIDGE.AC.UK> +Subject: Re: Small TeX bug - \fontdimen <large-number> + +On Thu, 10 Mar 94 17:03:39 GMT you said: +>Barbara, +> +>I wrote: +>> (There is curiosity, though: |font_params| is an array of |halfword|s. +>> Can one break TeX by setting \fontdimen<amazingly large number>? I will +>> have to think about that one.) +> +>There is, in fact, a bug here. The following code in TeX section 580, +>part of |find_font_dimen|, +> +> begin repeat if fmem_ptr=font_mem_size then +> overflow("font memory",font_mem_size); +> font_info[fmem_ptr].sc:=0; incr(fmem_ptr); incr(font_params[f]); +> until n=font_params[f]; +> +>contains no precautions to prevent |font_params[f]| from being +>incremented from |max_halfword|, its largest legal value. What +>happens next is implementation-dependant. In the case of the one +>I was experimenting with, |halfword| values wrap quietly from +>|max_halfword| to |min_halfword|, and so (for large enough |n|) +>the loop test is never satisfied, and one gets a font memory +>overflow condition (which is only mildly spurious). +> +>Possible fixes: make |font_params| an array of |integer|, or +>|font_index| (maybe: not sure about this), instead of |halfword|. +>Alternatively, in section 578 replace +> +> if n<=0 then cur_val:=fmem_ptr +> +>by +> +> if (n<=0) or (n>max_halfword) then cur_val:=fmem_ptr +> +Hi Chris, +1. I agree this is a bug and (from past experience) I would say you are due +for a cheque (a big one). Assuming font_mem_size>max_halfword the program may +[ dek -- $327.68 +] +attempt to assign a value >max_halfword to font_params[f]. If range checking +were on (who is nowadays running TeX with range checking on?) this would give a +"high bound violation" or however this is called in a particular systems. +Knuth has always classified such as bugs. (I once got a cheque for an even +more obscure range checking error.) + +As to a fix I have convinced myself that defining + @!font_params:array[internal_font_number] of font_index; {how many font +solves all problems and introduces no new ones. +In particular I have verified with a `virgin INITEX' with font_mem_size=32767 +that one can say "\fontdimen 32767 \nullfont" with no problems whereas + "\fontdimem 32768 \nullfont" leads to an overflow [font_mem... . +Hence TeX makes sure that font_params[f] is allways in the range +7..font_mem_size, i.e., a subset of font_index. + +As to the other possibilities: your alternative +> if (n<=0) or (n>max_halfword) then cur_val:=fmem_ptr +is not so good since the result is implementation dependent, on some +systems you can use \fontdimen n f with some very large n and on other +systems (or the same system with different switches) you can't. +I think Knuth's policy for such was that an error is not sufficient, +only a fatal error is good enough indication. +And whoever wants to set \fondimen 32000 f is probably out of his mind +anyway. + +2. Did you already have a chance to look at the e-TeX files ? + +regards peter +------- + +<<< end The TeX program + +************************************************************************ diff --git a/info/digests/tex-implementors/message.45 b/info/digests/tex-implementors/message.45 new file mode 100644 index 0000000000..42c30a48a7 --- /dev/null +++ b/info/digests/tex-implementors/message.45 @@ -0,0 +1,1596 @@ +TeX 3.14159 and other updates -- file 2 of 2 + +######################################################################## + +>>> plain.tex + + +++ \oalign and \d{} + +[ the following two reports, from j"org knappen and petr sojka, + cover the same territory, but with different proposals for fixing +[ dek -- ^^^^^^^^^^^^^^ _different_ bugs in the same territory +] + the problem. i've included both since both looked reasonable to me. +] +------- +Newsgroups: comp.text.tex +Date: 17 May 1992 20:28:21 +0000 (GMT) +[ dek -- 1992 again -- I changed \d in 1993 but never had heard of this +] +Organization: Computer Science Dept, University of Tennesee, Knoxville +From: eijkhout@cupid.cs.utk.edu (Victor Eijkhout) +Subject: Re: \d{} + +In article <01GK1PHMODB48WWBZV@VzdmzA.ZDV.Uni-Mainz.DE>, + KNAPPEN@VKPMZD.KPH.Uni-Mainz.de (J%org Knappen) writes: +|> The following line +|> +|> Das ist ein Test von (\d{}) \verb:(\d{}): +|> +|> runs through TeX without any error messages, but produces an underdot which +|> is more than 300pt left off the paper. + +About 1000pt left of the opening bracket to be a bit more precise. + +|> \d{ } also fails, \d{\ } works and +|> produces a dot under ``nothing''. +|> +|> The test above turns out to be a driver's test, too. Two of four +|> dvi-drivers (on our VAX/VMS-system) did not complain nor show the mistake +|> in output. + +What mistake? How can a device driver know that your printer doesn' +have paper 1 meter wide? (With the margin only 20 cm from the right +paper edge :-) + +|> I consider the facts above as a misfeature (not to say bug). + +I consider the posting above as uninformed. + +But seriously, one might wonder what happens here. + +Watch this: + +This is TeX, C Version 3.0 +(/usr/local/lib/TeX/inputs/nul.tex +LaTeX Version 2.09 <7 Dec 1989> +) +*\show\d +> \d=macro: +->\protect \pd . +<*> \show\d + +? i\show\pd +> \pd=macro: +#1->\oalign {#1\crcr \hidewidth .\hidewidth }. +<insert> \show\pd + +(Yes, that's true, I run TeX interactively. I must be just about +the only one on earth to do this.) + +This tells you that \d is essentially a macro with one argument. +You give it the empty argument, so it expands to + \oalign { \crcr \hidewidth .\hidewidth } + +Now, \oalign is essentially \halign, and we know (otherwise look it up) +that \crcr only gives a new line if there was a line to terminate. +Which there isn't in this case, so we get + \halign { \hidewidth .\hidewidth } +[ dek -- ^ \preamble\cr +] + +and since \hidewidth is \hskip -1000pt plus 1fil, you have managed to +move the . 1000pt left of where you intended it to be. + +All of this does make me wonder a bit, though. Why did Knuth use \hidewidth? +Well obviously so that you could put objects under 'nothing'. +[ dek -- under very _narrow_ things +] +But why then \crcr and not just \cr? Well, probably he foresaw +that people might want to put stuff under more than one line, so both +\d{a\cr b} and \d{a\cr b\cr} had to give the same result. + +Hey, waddaya know! Everything is logical after all! + +|> Yours, J"org Knappen. + +Victor. +------- +X-ListName: TeX-Related Network Discussion List <INFO-TeX@SHSU.edu> +Date: 21 May 1992 12:46 +0000 (GMT) +From: J%org Knappen <KNAPPEN@VKPMZD.KPH.Uni-Mainz.de> +Subject: Again \d{}, with a bug fix + + Dear samretanoj, + + After reading Victor's posting carefully, the following bug fix comes to my + mind: +\def\d#1{\oalign{\null#1\crcr\hidewidth.\hidewidth}} +[ dek -- ^^^^^ \relax is better +] + (Barbara, are you listening? Please forward it to DEK) + + It passes the following tests: +Teste \d{}, \d{ }, \d{\ }! + +Mehr Tests: \d{a\cr b} und \d{a\cr b\cr}! +\bye + An analogous fix should be done to \b, both in plain.tex and lplain.tex. + + On drivers: + here is how a good driver (Brian {Hamilton Kelly}'s DVItoLN03) behaves: +This is DVItoLN03, Vax/VMS Version 4.0-3 +[Some more message stuff deleted (JK)] +Warning: Characters '' set off paper +( x = -3768..-3768, y = 342 ) - ignored +Warning: Characters '.' set off paper +( x = -3768..-3756, y = 342 ) - ignored +[153] Warning: Page wider than TeX reported by 510.2450pt + + Yours, J"org Knappen. + + P.S. Originally, I asked my question on the info-tex mailing list. The most + valuable contributions were only sent to the news group comp.text.tex. + Fortunately since one month I have also access to news...I must have missed + much before, even follow-ups to my own postings! +------- +Date: 12 Jan 1995 22:55:33 +0100 (MET) +From: Petr Sojka <sojka@daeron.ics.muni.cz> +Organization: Masaryk University, Brno, The Czech Republic +Subject: Bug in plain.tex -- please pass to DEK + +Barbara, + +here is what I consider as a bug of plain.tex: +You read there: + +% This is the plain TeX format that's described in The TeXbook. +% N.B.: A version number is defined at the very end of this file; +% please change that number whenever the file is modified! +% And don't modify the file under any circumstances. + +... + +\def\oalign#1{\leavevmode\vtop{\baselineskip\z@skip \lineskip.25ex% + \ialign{##\crcr#1\crcr}}} % put characters over each other +\def\ooalign{\lineskiplimit-\maxdimen \oalign} +\def\sh@ft#1{\dimen\z@.00#1ex\multiply\dimen\z@\fontdimen1\font + \kern-.0156\dimen\z@} % compensate for slant in lowered accents +\def\d#1{\oalign{#1\crcr\hidewidth\sh@ft{08}.\hidewidth}} +\def\b#1{\oalign{#1\crcr\hidewidth\sh@ft{29}% + \vbox to.2ex{\hbox{\char22}\vss}\hidewidth}} +\def\c#1{\setbox\z@\hbox{#1}\ifdim\ht\z@=1ex\accent24 #1% + \else{\ooalign{\unhbox\z@\crcr\hidewidth\char24\hidewidth}}\fi} +\def\copyright{{\ooalign{\hfil\raise.07ex\hbox{c}\hfil\crcr\mathhexbox20D}}} + +Simply saying, Don forgot setting of \lineskiplimit to zero +in \oalign as one of the line vertical spacing parameters +besides \baselineskip and \lineskip + I found this bug when having set globally \lineskiplimit to +-2dd and setting e.g. \d{a}. What a surprise -- the dot +wasn't there! Or what do you expect to see with simple +file saying +\lineskiplimit-2dd\d a\bye +? Dot below a or `in a'? + +Will I be sent a check? + +Petr Sojka <sojka@muni.cz> +------- +(reply, 12 Jan 1995) +yep, you're right. it's a bug. +the dot doesn't disappear, exactly, it just hides "in" the a. +\b b does kind of the same thing, but \c c is protected because +it uses \ooalign. + +yes, i think you'll get a check for this one, though i predict +it'll be just a small one, 'cuz the big ones only get awarded +for bugs in tex(.web) itself. +[ i didn't discover the earlier report until after i'd replied; + too bad. ] +------- + + ---------------------------------------------------------------------- + + +++ hyphenation inhibited by struts + +Date: 06 Jan 1994 12:04:38 +0100 +From: Piet van Oostrum <piet@cs.ruu.nl> +Subject: Bug in TeX + +Barbara, + +Could you forward the following to Knuth (I suppose you still act as a +forwarding agent). + +I consider the following a bug in TeX (in fact in the Plain macros): + +The first and last words in a footnote are never hyphenated. + +This is because plain TeX inserts struts, which are rules, and as these are +adjacent to the first and last words, they inhibit hyphenation. + +The solution is to insert \hskip0pt\relax between the struts and the text. +In fact I think it would be better to include this in the definition of +\strut. + +The solution to Exercise 22.8 has the same deficiency. + +Piet* van Oostrum, Dept of Computer Science, Utrecht University, +Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands. +------- +[ dek -- I believe it is also true that the first word of _any_ + paragraph is not hyphenated. (I prefer actually to + disable hyphens on the final word; but anyway this change + is far too drastic to be contemplated at this time.) +] +(reply, 06 Jan 1994) +piet, +thanks for your report. +i'll forward it to knuth, but i know his response: +this isn't a real bug; it's an unfortunate feature, and if he +had thought about it in 1984, he probably would have done what +you suggest. but tex/plain/etc. are now frozen, and he's not +going to make any changes except for indisputable bugs. + +he will probably also suggest that you write this up for tugboat. +so i will beat him to it -- would you write this up in a form +suitable for the "warnings" column? this would best take the +form of a brief, clear description (the description in your +message is certainly clear enough) with an example or two +showing "before" and "after". let me know what you think. +------- +Date: 07 Jan 1994 09:44:09 +0100 +From: Piet van Oostrum <piet@cs.ruu.nl> +Subject: Re: Bug in TeX + +>>>>> bbeeton <BNB@MATH.AMS.ORG> (BB) writes: + +BB> piet, +BB> thanks for your report. +BB> i'll forward it to knuth, but i know his response: [...] + +I'll just wait for DEK's response and then write a warning article about +it. Thanks for your effort. +------- +[ dek -- I certainly agree that he should make such a contribution to + _Warnings_. + NB. There is an \allowhyphens macro [in Appendix D, not in plain] +] + + ---------------------------------------------------------------------- + + +++ TeXbook, page 363, in \endinsert + +Date: 09 Feb 1994 12:29:08 +0100 (MET) +From: vieth@convex.rz.uni-duesseldorf.de (Ulrik Vieth) +Organization: Heinrich-Heine-Universitaet Duesseldorf +Subject: Re: for Knuth: minor typo in MFbook + +Hi Barbara, + +after I printed out all the errata files yesterday, I've checked it +again. Here is what I found out: + +[ this turned out to have been resolved, but i've left the comment + in the report for background. ] +The METAFONTbook, 5th printing, March 1990 is quite a strange mixture. +[ dek -- royal foulup in _many_ printings. Ask Phyllis for copies + of letters I wrote to A-W when i first noticed it ... +] +It does include the changes from errata.five (1989) and errata.six +until 3/13/90, excluding those dated 3/24/90 or later. It does *not* +include the changes from errata.three nor those from errata.four, +unless they happen to fall on pages affected by the later changes. +My conclusion that some of the changes from 3/87 were done, was just +a conincidence since most of them were index corrections on pages +that were changed again in 1989--1990. I'll try to locate a newer +printing of the METAFONTbook next week at the DANTE meeting to check +if they have been done in subsequent printings. However, I couldn't +find any note about the 6th printing in my copy of errata.three. +There seem to be different of that file around. + +[ this is the problem that still remains ... ] +OK, so far about the METAFONTbook. When I was at it, I also checked +my copy of the TeXbook, 18th printing, May 1990. Here, there were +no serious problems. It includes the changes from errata.six until +3/24/90, so it was completed sliightly later than the METAFONTbook, +5th printing. The only small problem I found was the change on page +A363, dated 8/12/89, that should have been in, but isn't. I'll try +[ dek -- he's correct ... this never made it into print. +] +to investigate this in a newer printing as well, but there might be +the odd chance that it came too late when the bunch of changes +dated 3/12/89 were send off and was forgotten with the next bunch +a few months later. In any case, I'll try to find out. + +Greetings, Ulrik Vieth. +------- + +i found this bug for page a363 in errata.six: + + \bugonpage A363, lines 8--9 from the bottom (12/8/89) + + {\ninepoint\parindent=0pt + | \if@mid \dimen@=\ht0 \advance\dimen@ by\dp\z@ |% + |\advance\dimen@ by12\p@|\parbreak% + | \advance\dimen@ by\pagetotal \advance\dimen@ by-\pageshrink| + \par} +[ dek * ] +------- +Date: 18 Feb 1994 18:23:06 +0100 (MET) +From: vieth@convex.rz.uni-duesseldorf.de (Ulrik Vieth) +Subject: Re: for Knuth: minor typo in MFbook + +Hi Barbara, + +I have just returned from the DANTE meeting, where I found a copy of +the 7th printing of the METAFONTbook to check. It appears to me that +the changes from errata.three and errata.four that were missing in +the 5th printing are finally in there. So the problem I reported is +mostly solved. + +About the TeXbook: I've noticed that the famous duplicated exercise bug +that was still present in the 22nd printing (final version) has been +corrected in the 23rd printing. However the change on page A363 (8/12/89) +is missing there as well. Of course it is in plain.tex 3.0 or later, but +apparently page A363 has not been updated in the 18th printing or any +other printing since then. So I guess this is indeed a problem for Knuth +and Addison-Wesley. Although my first problem has disappeared in the end, +this has led to the discovery of another problem still pending, so it +was worthwhile after all. +[ dek -- \check +] + +Ulrik Vieth. +------- + +<<< end plain.tex + +************************************************************************ + +>>> Metafont + + +++ arithmetic overflow with z=whatever[z',z''] + +Date: Mon, 9 May 94 14:44:46 WETDST +From: Tomek Przechlewski <tomasz@panda.bg.univ.gda.pl> +Subject: Bug in Metafont? + +Dear Barbara, + +I am passing the request of my friend Bogus{\l}aw +Jackowski (you have met him in Aston last year). He cannot find the +explanation of MF performance in the example appended below. + +Could you answer why in quite similar situations there are +so different outcomes. Is this a bug in Metafont or a feature? + +I look forward to hearing from you + +--Tomek Przechlewski + +% =================================================================== + +% +% \rm{}The following simple \MF\ program yielded unexpected (to me) results: +% +z1=whatever[(0,328),(100,329-eps)]; +z2=whatever[(0,328),(100,329)]; +z3=whatever[(0,328),(100,329+eps)]; +z4=whatever[(0,328),(100,329+2eps)]; +showdependencies; +end. +%%\def\~{\kern.15em} +% +% \rm{}The log file produced by, e.\~g., sbMF reads as follows: +% +% This is METAFONT, Version 2.71(c)sb13 (preloaded base=plain 93.5.6) +% 23 JUL 1993 17:22 +%%%% originally the ampersand was not preceded by the slash, of course +% ** \&plain aritover.mf +% (aritover.mf +% ! Arithmetic overflow. +% l.5 ...atever[(0,328),(100,329)] +% ; +% ? +% ! Arithmetic overflow. +% l.6 ...er[(0,328),(100,329+eps)] +% ; +% ? +% ! Arithmetic overflow. +% l.6 ...r[(0,328),(100,329+eps)]; +% +% ? +% y4=0.01001x4+328 +% y3=0.01001x3+327.83998 +% y2=0.01x2+327.68 +% y1=0.01x1+328 ) +% +% \rm{}Although Phil Taylor's opinion is that ``.\~.\~. the `bug' appears +% \rm{}to be a feature; the error message is well-defined, and `help' gives +% \rm{}a sensible diagnostic .\~.\~.'' I can hardly agree that this is OK. +% \rm{}Good luck to everybody using equations of the form |z=whatever[z',z'']|. +% +% \rm{}Bogus\l{}aw Jackowski +% \rm{}ul. Tatrza\'nska 6/1 +% \rm{}80-331 Gda\'nsk, Poland. +% +% +% \rm{}P.\~S. For the first time I came up against this situation on 4 III 1993 +% \rm{}(the equation was |z=whatever[(37.0092,419.22664),(280.3105,417.96634)]|). +% \rm{}Since that time I had ``a pleasure'' of encountering it several times. BJ. +%%\let\makefootline\empty\end +------- +Date: Tue, 17 May 94 12:46:02 WETDST +From: Tomek Przechlewski <tomasz@panda.bg.univ.gda.pl> +Subject: B. Jackowki's replay + +Dear Barbara, + +thank you for your responding to Tomek's mail. + +> ...there was another report about METAFONT arithmetic overflow just +> last week... + +Both error messages which are the subject of Pierre MacKay's response +have nothing to do with the METAFONT's behavior I had to struggle with: + +1. +> alpha=diag_ratio(4,stem2-stem3+stem4,y1-y2,x8r-x1l+mid_corr-2apex_corr); + +The `diag_ratio' macro does not make any use of `whatever[...]' construction, +while my troubles are strictly connected with this construction. + +2. +>z4=z5+whatever*(150u,h); + +Here the `! Arithmetic overflow' error occurs because the value of expression +`150u' is too large: for cminch font u=223.51988 at 2540 dpi, hence the +product would be about 33528, which is the number too large for METAFONT +(her actual infinity is 32767.99998). So, once again, `whatever[...]' +construction is not to blame. + +In my example I am using fairly ``regular'' numbers (ranging from zero to +about 300) and, moreover, the behavior of METAFONT seems to be numerically +instable, as changing the numbers by `eps' (in plain METAFONT eps=0.00049) +has apparent impact on `! Arithmetic overflow' error. + +Of course, I am not in a position to insist on prof. Knuth to change +METAFONT, neither I wish to overload him with unnecessary work. Nevertheless, +I would be happy to learn at least when such a situation may occur; then it +will perhaps become clear how to avoid it. + +Cheers. Jacko + +PS: and Tomek. +------- +[ message forwarded to chris thompson, but no response ] + + ---------------------------------------------------------------------- + + +++ several reports from Bogus{\l}aw Jackowski + +Date: 18 Oct 1994 16:06:45 +0100 (MET) +From: Wlodek Bzyl <matwb@halina.univ.gda.pl> +Subject: errors of TeX, MF (from B. Jackowski) + +Hi, Barbara, + +This file contains actually five different files put together to facilitate +electronic transmission and maintenance. Files are separated by `-=-=-= ...' +lines. All of them contain remarks concerning may-be-bugs in various +D. E. Kunth's products. If the authorship of a remark is not stated +explicitly, this means that it is mine (BJ's). + + Bogus\l{}aw Jackowski + ul. Tatrza\'nska 6/1 + 80-331 Gda\'nsk, Poland + + + SYNOPSIS + +1) File ARITOVER.MF: describes troubles with METAFONT's arithmetical overflow + in context of linear equations; I've already sent this file to you, + but for the completeness reason I put it along with other messages. + To see the problem you can compile the file with METAFONT and/or + to print it using MFT utility with PL.MFT data (enclosed separately). + + Perhaps Phil Taylor is right that what I regard as a bug is merely + a feature. If so, I would gladly learn how to avoid the problems + which this `feature' may cause. + +2) File SHUFFLED.TEX: discusses the problem of validity of the + ``shuffled binary property'' of METAFONT operation `intersectiontimes.' + This file can be compiled using TeX + MANMAC macros. + +3) File CSCSPU.CH: contains a minor change to the METAFONT sources + of the CM fonts. + +4) File ITALD.CH: contains a minor change to the METAFONT sources + of the CM fonts. + +5) File 2R1Q2TXB.TEX: contains two minor remarks (possibly out of date) + and one question concerning misprintings in The TeXbook. This file + can be compiled using TeX + MANMAC macros. + +%-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= +% FILE ARITOVER.MF +%-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= +% +% \rm{}The following simple \MF\ program yielded unexpected (to me) results: +% +z1=whatever[(0,328),(100,329-eps)]; + +% [ text removed; complete message appears above ] +%-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= +% END OF FILE ARITOVER.MF +%-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= + + +%-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= +% FILE SHUFFLED.TEX +%-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= + +\let\MFmanual=\! +\input manmac \vsize24cm \pageheight\vsize +\def\rhead{Chapter 14. Paths} +\def\MFbook#1{% + {\def\MF{{\manual 89:;}\-{\manual <=>:\/}}% slant the logo + \sl The~\MF book#1}} +\pageno137 \proofmodefalse + +\vdots + +\bigskip + +[ dek -- p137 +] +\ddanger If the paths intersect more than once, \MF\ has a somewhat +peculiar way of deciding what times $(t,u)$ should be reported by +`$p$~intersectiontimes~$q$'. Suppose $p$ has length~$m$ and $q$ has +length~$n$. \ (Paths of length~0 are first changed into motionless paths +of length~1.) \ \MF\ proceeds to examine subpath~$(k,k+1)$ of~$p$ +versus subpath~$(l,l+1)$ of~$q$, for $k=0$, \dots,~$m-1$ and $l=0$, +\dots,~$n-1$, with $l$ varying most rapidly. This reduces the general +problem to the special case of paths of length~1, and the times $(t,u)$ +for the first such intersection found are added to $(k,l)$. But within +paths of length~1 the search for intersection times is somewhat +different: Instead of reporting the ``lexicographically smallest'' pair +$(t,u)$ that corresponds to an intersection, \MF\ finds the $(t,u)$ +whose ``^{shuffled binary}'' representation $(.t_1u_1t_2u_2\ldots\,)_2$ +is minimum, where $(.t_1t_2\ldots\,)_2$ and $(.u_1u_2\ldots\,)_2$ are +the radix-2 representations of $t$ and~$u$. + +\bigskip + +\vdots + +\bigskip + +\tenpoint + +This is what \MFbook\/ says on page 137. Then follows Exercise 14.17 which +makes use of the ``shuffled binary property.'' Alas, the ``shuffled binary +property'' does not hold. Consider a path $p=(a,b)\dashto(c,d)$. One would +expect that the result of `$p$~\null intersectiontimes~\null reverse~$p$' +should be $(0,1)$, as the shuffled binary representation is for this case +$(.01010\ldots\,)_2$ which is the {\it minimum\/} of the shuffled binary +representations for pairs $(x,1-x)$, ${0\le x\le1}$. + +Indeed, most likely the result will be like that (sometimes within some +accuracy). But if there exist \MF\ numbers $c'$~and~$d'$ such that +$c$~and~$d$ are of the form ${c=a+3c'}$ and ${d=a+3d'}$, the result is +[ dek -- ^ b +] +astonishingly~$(0.5,0.5)$. This apparently contradicts the quoted statement +as the shuffled binary representation of $(0.5,0.5)$ is $(.11)_2$ which is +the {\it maximum\/} of the shuffled binary representations for pairs +$(x,1-x)$, ${0\le x\le1}$. + +Here you have a little \MF\ program which can produce arbitrarily many +`|>>|~|(0.5,0.5)|' messages on your terminal: + + \begintt + path p; numeric a,b,c,d,n; n:=10; + for i:=1 upto n: + a:=uniformdeviate 1000; b:=uniformdeviate 1000; + c:=a+3uniformdeviate 1000; d:=b+3uniformdeviate 1000; + p:=(a,b)--(c,d); + show p intersectiontimes reverse p; + endfor + \endtt + +\medskip + +My basic question is: does the above specification cover all exceptions +from the shuffled binary property? + +Also, I wonder whether it is a ``white lie,'' or a mistake in \MFbook, +or---God forbid!---a bug in \MF\kern.1em? + +[ dek -- ANSWER: + This is an interesting question (but you could have figured it + out from the program. I admit that the documentation is ``terse'', + but the algorithm is pretty enough to reward a close look.) + In fact we _do_ get the minimum shuffled binary, which happens + to be not .0101010101... but .001111111111... [even smaller!]; + which gives (0.5,0.5). + The point .001111111111 seems to lie on both curves only when + there is absolutely no truncation error, and I believe this + happens if and only if the control points z_0 .. controls z, + and z_2 .. z_3 satisfy z_1 - z_0 = z_2 - z_1 = z_3 - z_2 . + Otherwise it's necessary to go to the next higher case. + Of course the intersection point routine is not intended for + such curves -- it is supposed to -|- find genuine crossing points. +] + +\bigskip + +\rightline{\vbox{\halign{#\hss\cr +\it June 10, 1994\cr +\noalign{\medskip} +Bogus\l{}aw Jackowski\cr +ul. Tatrza\'nska 6/1\cr +80-331 Gda¤sk\cr +Poland\cr +}}} + +\end + +%-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= +% END OF FILE SHUFFLED.TEX +%-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= + + +%-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= +% FILE CSCSPU.CH +%-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= + +% Following a change in ROMANU.MF I would suggest a similar change +% in CSCSPU.MF: +% +@x +bulb(3,4,5); % bulb +@y +[ dek -- $2.56 +] +pickup tiny.nib; bulb(3,4,5); % bulb +@z +% +% The original version of CSCSPU generates bad ``dotless'' small cap `j' +% in Computer Concrete CCCSC10 font. + +%-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= +% END OF FILE CSCSPU.CH +%-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= + + +%-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= +% FILE ITALD.CH +%-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= + +% The non-zero depth of the italic digit seven was noticed by 12 years old +% Joanna Ry\'cko. I cannot see any reason for keeping this state of the art. +% It seems that the following change in ITALD.MF would be appropriate: +@x +beginchar("7",9u#,fig_height#,desc_depth#); +@y +beginchar("7",9u#,fig_height#,0); +@z + +[ dek -- I have sworn not to change the TFM files ever again. So this + curious glitch is permanent. (Long ago _all_ italic digits had + the same descender. Later I corrected everything but the 7; + we can live with it. +] + +%-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= +% END OF FILE ITALD.CH +%-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= + + +%-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= +% FILE 2R1Q2TXB.TEX +%-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= + +\input manmac \vsize24cm \pageheight\vsize +\proofmodefalse +\def\rhead{} +\def\rightheadline{} +\font\bsl cmbxsl10 + +\centerline{\bf Two Remarks and One Question} +\centerline{\bf Concerning \bsl The \TeX book} + +\bigskip + +% [ this one has been fixed ] +1)\enspace Noticed by Marek Ry\'cko: In the eighteenth printing of {\sl The +\TeX book\/} Exercise~8.7 appears twice (one after the other). + +\bigskip + +2)\enspace Noticed by Marek Ry\'cko: In the source of {\sl The \TeX book\/} +(incorporating the final corrections made in 1993) on the page~31 a space +precedes improperly the word `\TeX' just after the verbatim quotation: +[ dek -- $2.56 +] + +\medskip + +\noindent `[\dots] after typing something like this: +\begintt +! Undefined control sequence. +l.2 \vship + 1in +? +\endtt +\def\storypage{24} % listing of story.tex +\TeX\ begins its error messages with `|!|', and it shows what it was +reading at the time of the error by displaying two lines of context~[\dots]' + +\medskip + +\tolerance1000 +The reason for this is that after the verbatim quotation there is a command +|\def\storypage{24}|, and there is a space after it. +[ dek -- ^^^^^^ This command is in fact redundant -- I moved it to + manmac.tex but forgot to delete it from texbook.tex +] + +\bigskip + +3)\enspace The ``problem'' raised during the Euro\TeX'94 meeting in Gda\'nsk, +Poland: What is the proper spelling of Addison$\,*\,$Wesley: Addison-Wesley +(back of the cover of {\sl The \TeX book}, prepared probably by the +publisher) or Addison Wesley (the~source of {\sl The \TeX book\/}), or both? + +[ dek -- They flip-flopped several times during the 80s, as they had + different chief graphic designers for their ``corporate image''. + I couldn't keep up. +] + +%-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= +% END OF FILE 2R1Q2TXB.TEX +%-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= +------- + +<<< end Metafont + +************************************************************************ + +>>> CM fonts + + +++ missing "cmchar"s in bigdel.mf + +Date: Sat, 07 Mar 92 15:23:59 GMT +From: Chris Thompson <CET1@phoenix.cambridge.ac.uk> +Cc: REH10@phoenix.cambridge.ac.uk +Subject: Missing "cmchar"s in bigdel.mf + +Barbara, + +[ dek -- E95,E97 $2.56 +] +Robert Hunt (reh10@phx.cam.ac.uk) has pointed out that in bigdel.mf +the expected "cmchar"s on line 596 (character `077) and line 645 +(character `167) are missing. (As "cmchar" is usually a no-op, this +only matters if you are trying to play the sort of games described +on pp.312-313 of the METAFONTbook.) It seems to be just an oversight: +perhaps you can add it to DEK's list? + +Chris Thompson +JANET: cet1@uk.ac.cam.phx +------- + + ---------------------------------------------------------------------- + + +++ shaved_stem vs. cap_stem in greeku.mf + +Date: 14 May 1993 17:38:30 -0300 (BST) +From: Chris Thompson <CET1@phx.cam.ac.uk> +To: Barbara Beeton <BNB@MATH.AMS.ORG> +Cc: Robert Hunt <REH10@phx.cam.ac.uk> +Subject: Re: [Minor CM fonts bug] + +Barbara, + +Robert Hunt reports the following: +> Line 196 of greeku.mf, which currently reads +[ dek -- E187,E189 $2.56 +] +> +> lft x1l=lft x2l=hround(.5w-.5cap_stem); top y1=h; bot y2=0; +> +> should read +> +> lft x1l=lft x2l=hround(.5w-.5shaved_stem); top y1=h; bot y2=0; +> +> Exactly the same bug also occurs on line 215. (These are in the +[ dek -- ^^^ 216 +] +> character programs for capital Phi and Psi respectively.) + +This looks right to me: at some stage 'shaved_stem' was introduced +to these programs instead of 'cap_stem', but these two occurrences +were missed. + +Chris Thompson +Cambridge University Computing Service +------- + + ---------------------------------------------------------------------- + + +++ miscellanea from Robert Hunt, mostly in CM sources + +Date: 29 Mar 1994 21:01:42 -0300 (BST) +From: Robert Hunt <REH10@phx.cam.ac.uk> +Cc: Chris Thompson <CET1@phx.cam.ac.uk> +Subject: TeX bugs + +Dear Barbara, + +I've been saving up several bugs I've found in the Computer Modern sources, the +METAFONTbook and Plain TeX for quite a while, and am now sending them on to you +for DEK. Perhaps you could add them to his list of things to look at next time +he reviews TeX etc. - I fully realise that this probably won't be for some +quite considerable time! +[ dek - ^^^^^^^^^^^^^^^ ^^^^ +] + +This message is, I'm afraid, rather long, but I thought it'd be better to send +you everything in one go rather than split it up into lots of separate +messages. Each of the bugs is separated by a line of ------'s below. +[ dek -- well done +] + +Thanks & best wishes, +Robert Hunt. + + ------------------------------------------------------------------------------ + +There seems to be a recurrent error in the code for the various Computer Modern +[ dek -- OK on pE481 +] +integral signs. For example, in the code for the \displaystyle integral sign in +bigop.mf, the line + lft x5r=hround(.5w-.5stem); +[ dek -- E113, E115 $2.56 + four places in bigop.mf + " " " ebigop.mf +] +should actually read + lft x5r=hround(.5w-.5max_size); +as the character is max_size pixels wide at z5. (In fact, the stem parameter +does not feature in the program for this character in any other way!) Similar +comments apply to all the other sizes and styles of integral signs. + + ------------------------------------------------------------------------------ + +In the code for the Computer Modern partial differential sign in italms.mf, the +line + path p; p=pulled_super_arc.l(3,4)(pull); +[ dek -- E233 $2.56 +] +should be replaced by + path p; {{interim superness:=more_super; p=pulled_super_arc.l(3,4)(pull)}}; + + ------------------------------------------------------------------------------ + +In symbol.mf, the code for the Computer Modern elementary division operator has +a bug causing the dots to be drawn with diameter dot_size+rule_thickness rather +than dot_size. (It's clear that they're meant to be of diameter dot_size +[ dek -- ^^^^^ No, the dots are the correct size but the + defs of x_3,y_3 are inappropriate + E438 $2.56 +] +because of the definition of x3.) The reason that the code doesn't work is that +pos doesn't know the breadth of rule.nib, so doesn't subtract anything off from +[ dek -- currentbreadth is in fact set from the pickup fine.nib of the + integral sigh (by chance) -- I should make my intentions clear, + without changing the character image that I got by luck. +] +dot_size. Various fixes are possible (such as changing the font_setup routine +in cmbase.mf to define breadth_[rule.nib]=rule_thickness), but the simplest +seems to be to insert a line saying "pickup fine.nib;" just after the draw +command. + + ------------------------------------------------------------------------------ + +There seems to be an error in the syntax definition for <path expression> on +page 213 of the METAFONTbook (and also in the simplified definition on page +129). I hope that I haven't embarrassed myself by misunderstanding it! + +The syntax as given doesn't seem to allow "(0,0)..(1,0)" as a +<path expression>. A <path join> (".." here, with empty direction specifiers) +must be followed by either "cycle" or <path tertiary>. A <path tertiary> must +start with a <path primary>. But "(1,0)" cannot be a <path primary>, as it is +[ dek -- C129 $2.56 +] +not a <path argument> or <path variable>, nor is it "(<path expression>)" +(since "1,0" without the brackets is not a valid <path expression>). +[ dek -- <pair tertiary< movves from subexpr level to tertiary level +] + + ------------------------------------------------------------------------------ + +There is a low-resolution anomaly that arises in the Computer Modern equals +sign and several other such characters. Each of the bars of "=" is meant to be +drawn by an identical _circular_ pen. However, at low resolutions (e.g., +300dpi, with mode CanonCX) the character can often turn out looking like the +following: + + xxxxxxxxxxxx + xxxxxxxxxxxxxx + + xxxxxxxxxxxxxx + xxxxxxxxxxxx + +which doesn't have the symmetry one would expect at the end-points of the +lines. This is due to the way in which the heights of the two bars are chosen; +the centre-points of the bars are at heights math_axis+.5spread and +math_axis-.5spread. Now math_axis has been chosen to be a good.y position for +rule.nib, and spread has been chosen to be an integer+eps; but this means that +if spread is an _odd_ integer (+eps) then the edges of the nib when it draws +the two bars are at almost exactly the _least_ optimal heights for drawing! +(I.e., an integer+.5+1/2eps.) This results in a loss of vertical symmetry at +the end-points of each bar. + +My suggested solution for this is to ensure that spread is always an even +integer (apart from the correction of size eps), as follows: + def compute_spread(expr normal_spread,big_spread)= + spread#:=math_spread[normal_spread,big_spread]; + spread:=2ceiling(spread#*hppp/2)+2eps; enddef; +[ dek -- E491 $2.56 ^ I left this out. _I_ _don't_ _know_ + _why_, but it caused the equal isgn to look like + xxx---x + xx---x + + xx---x + xxx---x + quite asymmetric! + I don't have time to fool around, but I guess this definition + is an improvement even though the 2eps should've been + good too ... + +0 OK + +eps OK + +2eps NG + +3eps NG + +1/3 NG +] +This does have the disadvantage that at very low resolutions characters can end +up being rather widely spread. + + ------------------------------------------------------------------------------ + +The character "H" in font cmssdc10, at pixels_per_inch=300 and mag=magstep1 +(the other parameters are unimportant), demonstrates a rounding problem which +is in fact present in a very great number of the Computer Modern character +definitions. At the top and bottom left of the left-hand stem, a pixel has been +cut out; but on the right of the left-hand stem, and on both sides of the +right-hand stem, these pixels are filled in. This makes the character very +asymmetric. + +The problem is caused because the stem is drawn with a pen of non-zero +thickness which is turning a corner, and because of a nicety which is discussed +in the METAFONTbook on the top of page 200. Basically, the line + lft x1l=lft x2l=hround max(2u,3u-.5cap_stem); x3=x4=w-x1; +in the definition of "H" in romanu.mf should be replaced by the two lines + lft x1l=lft x2l=hround max(2u,3u-.5cap_stem)-eps; + rt x3r=rt x4r=w-hround max(2u,3u-.5cap_stem); +(or something equivalent to these two). We want to avoid the vertices of the +"tiny" pen polygon (which is being used to draw the character) passing through +any ambiguous points whenever it turns a corner, and to do that we want its +centre to lie at a half-integer minus eps whenever it's at the left-hand side +of a stroke region, and at a half-integer (exactly) when it's at the right-hand +side of a stroke. (By "half-integer" here I mean either an integer or an +integer plus 1/2, dependent on the breadth of the "tiny" nib.) Since the "pos" +command of cmbase sets the distance between x$l and x$r to be an integer plus +eps (because the breadth of the tiny pen is set to an integer minus eps by the +font_setup routine), the command "lft x1l=hround(...)-eps" sets lft x1l to an +integer minus eps and rt x1r to exactly an integer; whereas "rt +x3r=hround(...)" sets rt x3r to an integer and lft x3l to an integer minus eps. +These commands therefore ensure that the stroke will have left-right symmetry. + +So the general rule which seems to be required is that in many of the CM +programs, + lft x$l=hround(...); +should be replaced by + lft x$l=hround(...)-eps; +whereas + rt x$r=hround(...); +should be left alone. Unfortunately this isn't a hard-and-fast rule, so would +be difficult to do automatically; in particular, commands such as + lft x$l=w-rt x$$r=hround(...); +need to be split into two statements. + +In fact, even the METAFONT logo font itself is subject to this problem! The "F" +character in logo.mf can suffer from asymmetry of the top bar, with pixels +being lost at the left-hand side (the right-hand side being alright). A quick +solution would seem to be to set leftstemloc to an integer minus eps instead of +exactly an integer, but I haven't checked this carefully to make sure it would +work correctly. + +Is it worth doing anything about this? It's a very minor problem, and to put it +[ dek -- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + To raise this question is to answer it! +] +right would require an awful lot of changes to the Computer Modern source +files. Unless some super-whazzo solution involving changing the "lft" macro +(etc.) can be thought up, it would be a very large amount of work. + + ------------------------------------------------------------------------------ + +There are a number of infelicities and/or bugs in the Plain TeX format. I've +listed some I know about below in approximately decreasing order of importance; +some (especially near the end of the list) are a little esoteric. + +% The Plain TeX \skew macro does not work properly with variable-size accents +% such as \widetilde. The following rewrite corrects that. +[ dek -- And makes people wonder why divide by 2 instead of using half + the skew originally! +] +% +\def\skew#1#2#3{{\muskip\z@#1mu\divide\muskip\z@\tw@ \mkern\muskip\z@ + #2{\mkern-\muskip\z@{#3}\mkern\muskip\z@}\mkern-\muskip\z@}{}} +[ dek -- p359 $2.56 +] +% +% The maths spacing inserted by \bmod is incorrect in script or scriptscript +% styles, because \nonscript was not used. +% +\def\bmod{\nonscript\mskip-\medmuskip\mkern5mu + \mathbin{\rm mod}\penalty900\mkern5mu\nonscript\mskip-\medmuskip} +[ dek -- p361 $2.56 + I hope this won't mess up too many people who have already + compensated for this bug. +] +% +% \displaylines does not work correctly if \tabskip happens to be non-zero when +% it is called (for instance, if the user does an \halign of his own with a +% non-zero \tabskip, just before using $$\displaylines{...}$$). +% +\def\displaylines#1{\displ@y \tabskip\z@skip + \halign{\hbox to\displaywidth{$\@lign\hfil\displaystyle##\hfil$}\crcr + #1\crcr}} +[ dek -- p362 $2.56 +] +% +% If a maths display is started when \prevdepth=-1000pt, the \openup adjustment +% which \displ@y automatically inserts before the first line of the display to +% compensate for the change in the value of \baselineskip should be omitted. +% +\def\displ@y{\global\dt@ptrue\openup\jot\m@th + \everycr{\noalign{\ifdt@p \global\dt@pfalse \ifdim\prevdepth>-1000\p@ + \vskip-\lineskiplimit \vskip\normallineskiplimit \fi + \else \penalty\interdisplaylinepenalty \fi}}} +[ dek -- p362 $2.56 + It is _very_ hard to reach this situation! + \noindent $$ \displaylines ... seems to be the simplese. +] +% +% [ \d{} and \b{} were reported earlier; see above under >>> plain.tex; +% this is the first report of \@vereq, i believe ] +% The \d and \b accent macros don't work if the user has set \lineskiplimit to +% a negative value, say around -2pt or less. The \@vereq macro (used only by +[ dek -- esplicitly ^ +] +% \cong) suffers from a similar problem. +% +\def\d#1{{\lineskiplimit\maxdimen\oalign{#1\crcr\hidewidth.\hidewidth}}} +\def\b#1{{\lineskiplimit\maxdimen\oalign{#1\crcr + \hidewidth\vbox to.2ex{\hbox{\char22}\vss}\hidewidth}}} +\def\@vereq#1#2{\lower.5\p@\vbox{\lineskiplimit\maxdimen\lineskip-.5\p@ + \ialign{$\m@th#1\hfil##\hfil$\crcr#2\crcr=\crcr}}} +[ dek -- p360 $2.56 +] +% +% Several definitions in Plain TeX contain excess tokens (typically redundant +% "=" signs, "by" keywords, etc.). Some (e.g. \m@th) are executed so frequently +% that it's worth removing them, which the following definitions do. +% +% [ removed ] +% +% [ removed some suggested hyphenations +% +% [ removed some suggested enhancements to operators like \sin ] +% +% \settabs breaks spectacularly in the (somewhat unlikely) eventuality of it +[ dek -- ^^^^^^^^^^^^^ agreed +] +% being followed by an \if; for example, +% \settabs \ifdim\hsize<8in 3 \else 4 \fi\columns +[ dek -- p354 $2.56 +] +% +\let\temp=\+ \let\+=\relax + +\def\sett@b{\ifx\next\+\def\nxt{\afterassignment\s@tt@b\let\nxt}% + \else\let\nxt\s@tcols\fi \let\next\relax \nxt} +\def\s@tt@b{\let\nxt\relax\us@false\m@ketabbox} + +\let\+=\temp +% +% English authors would greatly prefer to use English spellings in their +% command names! +% +% [ removed ] + + ------------------------------------------------------------------------------ + +[ additional bugs summarized; separate reports included above ] +------- +(reply, 29 Mar 1994) +robert, +thanks very much for your collection. + +a comment on plain.tex. knuth has communicated to me that he +will never again change plain.tex ; here is his response to a +suggestion sent to him in february 1993: + + [ dek: These macros look very good but I cannot change plain TeX + any more at this late date. _Ever_._ + (Wish I had thought of them in 1985!) + He should publish them in TUGboat. + ] + +presumably if there is a very bad and obscure bug *that doesn't +take effect very often* he might consider making an exception, +but his ideal now is that the entire tex system remain stable, +permanently. his recommendation that remaining problems, and +suggested improvements, be published in tugboat must be taken +at face value. if i don't pay attention to such comments, and +send in everything that's sent to me, i put myself in danger +of incurring his severe displeasure, which would jeopardize my +welcome to forward real bugs. if you really do want to submit +these suggestions for plain.tex to him, you should do it yourself +by regular post. his address is + + Prof. Donald E. Knuth + Department of Computer Science + Stanford University + Stanford, CA 94305 U.S.A. + +you could mention that i wouldn't forward them, or not, as you +wish. (i'll let you know what i do forward when i next put a +package together; that should be within the coming month.) + +regarding the computer modern sources, he may feel the same way +as about plain.tex, but it's never been tested. +------- +Date: 11 Apr 1994 21:42:27 -0300 (BST) +From: Robert Hunt <REH10@phx.cam.ac.uk> +To: bbeeton <BNB@MATH.AMS.ORG>, Chris Thompson <CET1@phx.cam.ac.uk> +Subject: Re: TeX bugs + +Dear Barbara, + +Thanks for your message about my bug collection. I understand DEK's position on +Plain TeX, that he doesn't want to change it any more, and will certainly +respect that. (Though I suppose I would be grateful if when you forward the +rest of my list to him, you would just add a one-liner saying that there used +to be several Plain TeX bug-fixes there but that you've removed them with my +co-operation for this very reason!) + +How would I go about publishing them in TUGboat? [...] +------- + +[ dek -- Barbara, I relented this time only because his macros were elegant + and instructive and (with the exception of \bmod) unlikely to + make existing .tex files obsolete. + The \bmod bug is something I'm sure people have compensated for, + e.g., by inserting a thin space where it now will look better + without any such manual tuning up ... + but I decided the correction desirable anyway. + + For example, I had to change the MS to Concrete Math in seven places. + We could tell people to put the old def of \bmod in their files + if they don't wish to change. (That's what I decided to do with + Concrete Math.) + + I do expect to be EXTREMELY hardnosed about ANY future changes + to plain.tex, however. My thought is that this might as well be + the one last chance for changes -- since \d was so badly in need + of correction (four separate changes to it!) + Therefore, _please_ _keep_ telling people so exactly what you have + been telling them so kindly about the frozen-ness of plain.tex. +] + + ---------------------------------------------------------------------- + + +++ cap_ess in cmmi12 and larger + +Date: 01 Feb 1994 18:17:07 +0100 +Reply-to: METAFONT Distribution List <metafont@ens.fr> +From: KNAPPEN@VKPMZD.kph.Uni-Mainz.DE +Subject: c-cmmi.mf (Sauter tools) revisited: Bug in cap_ess +[ dek -- ^^^^^^^^^^^^ This is something I have nothing to do with... +] + +Bug report in c-cmmi.mf + +At 17.28pt the middle part of the letter S in cmmi looks too thin. I have +gone into the parameters and found the following formula for +cap_ess (design_size>10, rest omitted): + +cap_ess#:=(-design_size*5 + 380)/360 pt#; + +this means that the parameter cap_ess# decreases with design_size and will +reach zero at 76 pt! So why that decrease? Let's look at the Knuthian +parameters for cmr, cmmi and cmti: + +font 5 6 7 8 9 10 12 (pt#) +cmr 14 19 23 27 31 35 43 (1/36 pt#) +cmmi 13.5 18.5 22.5 26 30 33 32 +cmti -- -- 21 24 27 31 34 + +For all font but cmmi12, cap_ess of cmmi is between the values of cmr and +cmti, but closer to the cmr value. It look as if for cmmi12 a value of 42 +was aimed at, but for some reasons 32 has become a feature of this font. If +you look sharply at the S in cmmi12 (at 600dpi), you might find it a little +too light besides the letter R, but this is at the edge of visibility (at +least for my eye), therefore I'd never noticed it without looking at the +parameters. +[ dek -- As far as I know, there was no good formula for the ess widths; + I just played until they seemed right -- I defer to committee for + these things. +] + +However, further decrease of cap_ess is a bad idea, it should increase +again from design_size=12 on. + +Here a proposed formula for design_size>12, it yields 320/360 pt# at +12 and increases then, never getting bigger then the cmr-value: + +(design_size*9 + 216) / 360pt# + +It will be, however, lower then the value of cap_ess in cmti. +Since roman letters may appear in matematical formulae, the alignment +to the cmr parameters is imho the more important case. + +Fortunately, a change in the parameter cap_ess does not affect the font +metrics (or have I missed something?), therefore we can make a change here +[ dek -- ^^^^^^^^^ true -- anybody can change to + heart's content +] +without disturbing documents using the Sauter fonts. + +Comments? + +Yours, J"org Knappen. +------- + + ---------------------------------------------------------------------- + + +++ possible glitch in cmbx5 and cmbx6 + +Date: 15 Dec 1994 12:01:51 -0800 (PST) +From: kinch@netcom.com (Richard J. Kinch) +To: tex-implementors@MATH.AMS.ORG +Subject: Bug in cmbx5 and cmbx6 + +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 +------- + +[ dek -- It's okay to change the shapes of CM fonts as long as you don't + change the TFM files. I haven't time to fix this problem + since I don't consider enlarged cmbx an important font ... + I was unable to see the notches on the A, but I agree that the 7 + [drawn outline of 7, with a lump on the top] looks cancerous. + Not a problem at the sizes intended. Ultrabold is where + meta-ness can be expected to break first. + + (Congrats on METAFOG) +] + + ---------------------------------------------------------------------- + + +++ arithmetic overflow in CMinch + +Date: 05 May 1994 14:08:55 -0700 +From: mackay@cs.washington.edu (Pierre MacKay) +To: BNB@MATH.AMS.ORG +Cc: Bob@microprograms.com, mackay@cs.washington.edu, unixtex@u.washington.edu +Subject: Arithmetic overflow in CMinch + +Bob Harris (bob@microprograms.com) got in touch with me a couple +of days ago to report that it was not popssible to run +cminch with a 2540dpi LinotypeThreeZeroZero mode_def. + +The letter W and the numeral 3 generate the +! Arithmetic overflow +message, and the problem is far too serious to +be turned off with warningcheck:=0; +even if you wanted to do that. + +The offending lines were easy enough to spot: + in romanu.mf one third of the way through "The letter W" +[ dek -- E291 32\cents +] + +alpha=diag_ratio(4,stem2-stem3+stem4,y1-y2,x8r-x1l+mid_corr-2apex_corr); + + in romand.mf. halfway through "The numeral 3" + +z4=z5+whatever*(150u,h); + +Fortunately both of these statements generate ratios, so that the +raw arguments can be reduced consistently with no change in the results. +I extract from my email messages, slightly edited. + + > Think of "whatever" (in this manifestation) + > as a path of infinite length along the angle + > specified by (150u,h) + > Since the angle (15u,0.1h) is exactly the same + > ---I checked it with expr.mf, and there is no + > loss of precision---there is the answer. + > Write the offending line as + +z4=z5+whatever*(15u,0.1h); + + > The same trick that works for 3 works for W, though it requires a + > little more editing. + +alpha=diag_ratio(4,.1(stem2-stem3+stem4), + .1(y1-y2),.1(x8r-x1l+mid_corr-2apex_corr); +[ dek -- This doesn't fit on page E113 and besides it is too kludgy -- + bad style ... + What I shall really do is redefine diag_ratio -- it's pointless + to multiply by y and divide by y again! + + > This has the effect of calculating on a dpi measure of 254, but since what + > we are looking for is a ratio, it makes no difference. I ran with + > both calculations using the ljfour mode (effectively that means one + > calculation at 600dpi and one at 60dpi) and got exactly the same ratio + + > There is a small rounding difference in the 2540dpi file + + > 600dpi gives a diag_ratio of 1.03595 + > 2540 dpi gives a diag_ratio of 1.03609 + + > That may well be an artifact of some decisions in the parameter file. + > I doubt that .00014 is enough to worry about in this context. + > (The ratio that results after the ! arithmetic overflow is, of course, + > grossly out of line. + +I was a bit puzzled at first to explain why this hadn't showed up before, +since I have made up fonts at 9600dpi and even 14454dpi, but the answer +lies in the peculiarity of a 72.27pt font. Even a 17pt parameter file +has to be run at magstep 3 before its em-square reaches 1000 pixels in +width at 2540dpi. But there could be real problems with cmr17 at the +9600dpi that Lance Carnes uses to derive his Chelgraph outlines from. + +I wonder if DEK would be interested in preempting this problem, since +the solution is so painless, and will not affect TFM checksums. +------- + + ---------------------------------------------------------------------- + + +++ sterling sign + +Date: 04 Jan 1995 00:29:37 +0100 +Reply-to: METAFONT Distribution List <metafont@ens.fr> +From: Yannis Haralambous <Yannis.Haralambous@univ-lille1.fr> +Subject: error in CM fonts + +IMHO the following error has to be corrected: + +In file italp.mf, character "Sterling sign", line -7, replace +rt x9r=hround(w-u); +[ dek -- E239 $2.56 +] +by +rt x9l=hround(w-u); +Otherwise the results are bad in typewriter style and catastrophic in +sans-serif. The funny thing is that I could _swear_ that on the image +of the character the code is correct [probably a typo by Addison-Wesley]. + +Yannis +------- +Date: 04 Jan 1995 10:35:54 +0100 +Reply-to: METAFONT Distribution List <metafont@ens.fr> +From: Piet van Oostrum <piet@cs.ruu.nl> +Subject: Re: error in CM fonts + +>>>>> Yannis Haralambous <Yannis.Haralambous@univ-lille1.fr> (YH) writes: + +YH> IMHO the following error has to be corrected: + +YH> In file italp.mf, character "Sterling sign", line -7, replace +YH> rt x9r=hround(w-u); +YH> by +YH> rt x9l=hround(w-u); +YH> Otherwise the results are bad in typewriter style and catastrophic in +YH> sans-serif. The funny thing is that I could _swear_ that on the image +YH> of the character the code is correct [probably a typo by Addison-Wesley]. + +It can't be a typo by Addison Wesley, because it is in Knuth's original +sources (AW didn't type, they got -- of course -- the source from Knuth). + +If you look at the image you can really see that it is generated by the x9r +code, because the character sticks out a little bit to the right of the +x=11 line. Notice that the x9r point is to the LEFT of the x9l point!! + +And yes, with your correction it looks much better in sans serif. In the +[ dek -- ^^^^^^^^^^ + what sans serif?? This char does not have a sans serif style + in the present design ... sans serif has no ``bulbs'' +] +italic font, which is the only cm font where it is used, the difference +[ dek -- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +] +isn't very great because the x9r and x9l point are quite close top each +other, whereas in the sans-serif case they are 1 u apart. + -- +Piet van Oostrum <piet@cs.ruu.nl> +------- + +<<< end CM fonts + +************************************************************************ + +>>> Fontware + + +++ testfont.tex + +X-ListName: TeX-Related Network Discussion List <INFO-TeX@SHSU.edu> +Date: 05 Feb 1993 20:44 +0000 (GMT) +From: J%org Knappen <KNAPPEN@VKPMZD.KPH.Uni-Mainz.de> +Subject: Bug in testfont.tex + +By chance I came across to notice a feature of testfont.tex, which I regard +as a bug: + +In the \lowers and \uppers test, the kerning and ligature information is +not used. Therefore it is not possible to adjust the spacing of a font +using this tool. Since I know that some experts in macro expansion are +aroung here, i think one of them will take the challenge to rewrite +the routines of testfont.tex in order to be completely expandable and use +the kerning. + +Yours, J"org Knappen. +------- + +[ dek -- Font designers traditionally test without kerning (at least + they did when I worked with them in 80-85), but I suppose + such macros would be easy to write. +] + + ---------------------------------------------------------------------- + + +++ VPtoVF + +Date: 23 Aug 1993 10:08:20 +0200 +From: Armin.Koellner@RUBA.RZ.ruhr-uni-bochum.de +Subject: VPtoVF bug report and some comments on the AMS fonts + +Dear Barbara Beeton, + +since you stated in one of your letters that you are the right person +to get in contact with D.E.Knuth, I am sending to you a report of a +bug in the web file VPtoVF (Version 1.2, 90/9/5) which I found when +experimenting with ligature tables generated by a program written by +myself: + +If a ligature table erroneously starts with a STOP command, VPtoVF +will often destroy other data. This abnormal behaviour appears +because the variable lk_step_ended is not initialized by program code +to be FALSE, so that the conduct of the program depends on the random +contents of the memory cell the variable inherits. I suggest to +change the web file in order to correct this bug. + +Additionally, I would like to suggest some improvements on the AMS +symbol fonts, and, as you are working for the AMS (I suppose), could +you please give it to the font developer of your organisation? Thank +you very much. + +When I experimented with a program which handles fonts by detecting +their font coding scheme, I got stuck with the AMS symbol font series +msam and msbm. At first I detected that in my version of these fonts +(version="2.1a", date="15-OCT-1991") the series msbm* had no font +coding scheme string at all! This happened because the file xbbold.mf +ends with the token "end" instead of giving the control back to the +file amsyb.mf which ends correctly with "bye". I think, this bug +should be corrected. +[ this bug was fixed shortly after receiving this report ] + +Secondly, the AMS symbol fonts have the same font coding scheme +string as the cmsy* series, namely "TeX math symbols". This makes +them indistinguishable when considering only this string. As far as +[ dek -- not really needed for msam -- only for fonts used in + family 2, 3 ... +] +I understand, this special name is necessary for programs like TFtoPL +and VFtoVP to handle the character coding and math symbol font +parameters correctly. However, by reading the corresponding web files +for these programs, I learned that they only consider the first 11 +characters of the font coding scheme string. Therefore, I suggest for +the next version of your font series to name the font coding scheme +"TeX math symbols by AMS, Part A" and "TeX math symbols by AMS, +Part B", resp. +[ dek -- good suggestion +] + +Yours sincerely, +Armin K\"ollner +------- +Date: 26 Aug 1993 12:54:58 -0300 (BST) +From: Chris Thompson <CET1@phx.cam.ac.uk> +Subject: Re: [[Armin.Keollner: VPtoVF bug report and some comments]] + +Barbara, + +Armin Kollner writes: +> If a ligature table erroneously starts with a STOP command, VPtoVF + (or a SKIP command) +> will often destroy other data. This abnormal behaviour appears +> because the variable lk_step_ended is not initialized by program code +> to be FALSE, so that the conduct of the program depends on the random +> contents of the memory cell the variable inherits. I suggest to +> change the web file in order to correct this bug. + +This is indeed a bug in the current versions of VPtoVF and PLtoTF. +I found it rather difficult to demonstrate, as the uninitialised +variable ends up as binary zero (typically = Pascal "false") on +most systems. I did manage it eventually, though. + +[...] + +> Secondly, the AMS symbol fonts have the same font coding scheme +> string as the cmsy* series, namely "TeX math symbols". This makes +> them indistinguishable when considering only this string. As far as +> I understand, this special name is necessary for programs like TFtoPL +> and VFtoVP to handle the character coding and math symbol font +> parameters correctly. However, by reading the corresponding web files +> for these programs, I learned that they only consider the first 11 +> characters of the font coding scheme string. Therefore, I suggest for +> the next version of your font series to name the font coding scheme +> "TeX math symbols by AMS, Part A" and "TeX math symbols by AMS, +> Part B", resp. + +It is true that PLtoTF and VPtoTF (currently!) test only the initial +section of the coding scheme ("TEX MATH SY" or "TEX MATH EX", after +upper casing) when setting |font_type|. The result is used to control +the format used in the (V)PL output for various things (whether to +use names or numbers for the higher-numbered FONTDIMENs, and whether +to use D or C format for certain character numbers). This only affects +human-readability, though: the semantic content is not affected. + +Quite how the "font coding scheme" should be used is far from obvious, +but it is certainly arguable that the msam*/msbm* fonts do not have +the same "coding scheme" as the cmsy* fonts, in the sense that +characters at corresponding code positions are not, in any plausible +sense the "same" meta-character. I don't know whether a change could +really be said to make "use of these files ... more reliable" (to +quote you), though. + +[...] + +Chris Thompson +Cambridge University Computing Service +------- + +<<< end Fontware + +************************************************************************ |