summaryrefslogtreecommitdiff
path: root/info
diff options
context:
space:
mode:
authorNorbert Preining <norbert@preining.info>2021-05-27 03:01:40 +0000
committerNorbert Preining <norbert@preining.info>2021-05-27 03:01:40 +0000
commit5f1cfa686748068fedb95d8dafda3dc7f999c948 (patch)
tree874fa8430be12fe4633924f3b707428170316a46 /info
parent8982c52e00ffb3fb5a913fc60913ebd9070f091a (diff)
CTAN sync 202105270301
Diffstat (limited to 'info')
-rw-r--r--info/digests/tex-implementors/README18
-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.441290
-rw-r--r--info/digests/tex-implementors/message.451596
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
+
+************************************************************************