summaryrefslogtreecommitdiff
path: root/info/digests/tex-implementors/042
diff options
context:
space:
mode:
Diffstat (limited to 'info/digests/tex-implementors/042')
-rw-r--r--info/digests/tex-implementors/0421971
1 files changed, 1971 insertions, 0 deletions
diff --git a/info/digests/tex-implementors/042 b/info/digests/tex-implementors/042
new file mode 100644
index 0000000000..89cfb879cf
--- /dev/null
+++ b/info/digests/tex-implementors/042
@@ -0,0 +1,1971 @@
+Date: 11 Sep 93 Message No: 042
+
+To: TeX implementors and distributors
+
+From: Barbara Beeton
+
+Subject: TeX 3.1415 and other updates -- file 2 of 2
+
+
+########################################################################
+
+Commentary from Don Knuth
+
+>>> DEK message accompanying shipment
+ [ received 6 Jun 93 ]
+
+Barbara, I don't know when (if ever) you plan to put out another
+supplement to TUGboat containing TeX errata. But I did make some
+changes to errata.tex that you should know about:
+
+ New file errata.eight contains the changes subsequent to
+ errata.seven that are in the "final" publication form of
+ Volumes A-E (and the TeXbook and MFbook paperback variants).
+
+ Henceforth errata.tex contains the changes subsequent to the
+ final versions. The final versions will not be updated in
+ future printings. But I will keep my electronic copies up
+ to date in preparation for future electronic publication.
+
+Plain format 3.1415 includes two inportant changes regarding the \b
+accent in slanted fonts and the \upbracefill \downbracefill macros.
+
+Please encourage everybody to install this version ASAP. It is
+documented in errata.tex; five pages of the TeXbook are slightly
+affected, but (as I say) the hardcopy versions will no longer be
+updated.
+
+Similarly everybody needs plain.mf version 2.71 (it has two important
+corrections to the cutdraw macro).
+
+ don
+
+encl: errata.tex
+ errata.eight
+
+************************************************************************
+
+>>> TeXbook / MFbook bugs
+
+Date: 26 Jan 1993 18:19:09 +0100
+From: Roegel Denis <Denis.Roegel@loria.fr>
+Cc: roegel@pandore.loria.fr
+Subject: bug in TeXbook
+
+Mrs Beaton,
+
+I noticed a few weeks ago that you have the privilege to
+report bugs to the Grand Wizard. Here is a small one that
+appears in my printed edition of volume A (tenth printing)
+as well as in the files dated may 1991:
+
+page 320, answer to exercise 17.12: there is either a parenthesis
+too much or one lacking.
+[ dek: $2.56
+]
+
+Denis (roegel@loria.fr)
+-------
+
+[ the following are in consequence of repagination; a paragraph that
+ was formerly broken between pp.271-272 is now complete on p.271.
+ it is certain that other index items are involved as well.
+]
+[ dek: <chardef token>
+]
+Date: 19 Feb 1993 12:21:42 +0100
+From: Roegel Denis <Denis.Roegel@loria.fr>
+Subject: TeXbook bugs (cont'ed) ?
+
+Mrs Beeton,
+
+Yesterday, when I was reading in the TeXbook the entries related to
+\mathchardef, I found that there are two slightly wrong entries in
+the index, viz.,
+
+ On page 471, \mathchardef points to page 272, but I think 271 was meant.
+
+ The same problem happens for \chardef: 272 instead of 271.
+[ dek: $2.56
+]
+Well, that's all!
+
+Denis (roegel@loria.fr)
+-------
+
+Date: Thu, 09 Apr 92 00:16:21 BST
+From: Chris Thompson <CET1@UK.AC.CAMBRIDGE.PHOENIX>
+To: Barbara Beeton <BNB@COM.AMS.MATH>
+Cc: Robert Hunt <REH10@UK.AC.CAMBRIDGE.PHOENIX>
+Subject: TeXbook (chapter 26) error from Robert Hunt
+
+Barbara,
+
+Here is a TeXbook bug report from Robert Hunt:
+
+> (a) TeXbook error: chapter 26 ("Summary of Math Mode") claims that
+> \unhbox is an invalid command (and so generates an error) in maths
+> mode. In fact, it is allowed so long as the box being unboxed is void!
+> (The \S and \P macros make use of this fact.)
+
+This is right, I think. \unhbox and \unhcopy are not mentioned in
+Chapter 26, explicitly or implicitly, in the current texbook.tex,
+and so would fall into the "none of the above" on page 293. But they
+are in fact allowed in math mode provided the box register is void
+[ dek: $2.56
+]
+(tex.web section 1110, |unpackage|: this case is actually mentioned as
+change 232 in tex82.bug, TeX version 0.999). The fact that \leavevmode
+is allowed in math mode (doing nothing) depends on this. (It is called
+from \S and \P, hence Robert's mention of them above.)
+
+Chris Thompson
+-------
+
+Date: 3 Feb 1993 09:58:52 GMT
+From: schwab@lamothe.informatik.uni-dortmund.de (Andreas Schwab)
+To: tex-news@SHSU.EDU
+Subject: Typesetting bugs in The TeXbook and The METAFONTbook
+
+There are some typesetting bugs in The TeXbook (March 1992) and The
+METAFONTbook (February 1992):
+
+1. In the last line of page 358 in The TeXbook there is too much space
+between `that' and `give'.
+[ dek: (and it talks about "the proper spacing"!) $2.56
+]
+2. In the middle of page 296 in The METAFONTbook there is one comma
+too much after `tension 4..'.
+[ dek: $2.56
+]
+3. Likewise in The METAFONTbook, on page 299, second text line, the
+name `Bernshte\u\in' is misspelled. I don't know the correct
+spelling, but `Bernshtein' occurs three times and `Bernstein' only two
+times. On the other hand, one of the occurences of the latter form is
+in the index...
+[ dek: His name usually transliterated with just ...stein but when
+ I'm transliterating an original Russian mane I aim to be
+ consistently sh for {\cyr sh}. The recent printings have
+ this corrected.
+]
+
+--- texbook.tex~ Wed Mar 25 20:40:20 1992
++++ texbook.tex Fri Jan 1 20:07:40 1993
+@@ -20089,5 +20089,5 @@
+ After defining characters ^|\ldotp| and ^|\cdotp| that act as math
+ punctuation, it is easy to define ^|\ldots| and ^|\cdots| macros that
+-\vadjust{\penalty-50} % fairly good breakpoint (on July 27, 1983)
++\vadjust{\penalty-50}% fairly good breakpoint (on July 27, 1983)
+ give the proper spacing in most circumstances. Vertical and diagonal
+ dots (^|\vdots| and ^|\ddots|) are also provided here:
+--- mfbook.tex~ Wed Mar 25 20:17:08 1992
++++ mfbook.tex Fri Jan 1 18:00:58 1993
+@@ -15944,5 +15944,5 @@
+ With slight changes to this code, you can get weird effects.
+ For example, if the definition of |rp| is changed to `|]..tension 4..|',
+-^^{tension}, and if `|scaled|~|5pt|' is inserted before `|withweight|',
++^^{tension} and if `|scaled|~|5pt|' is inserted before `|withweight|',
+ the image will be an ``^{almost digitized}'' character:
+ \displayfig Daa (18.5mm)
+@@ -16099,5 +16099,5 @@
+ (1-t)^{n-k}t^{k-1}u_k,$
+ \enddisplay
+-a Bernste{\u\i}n polynomial of order $n-1$.)
++a Bernshte{\u\i}n polynomial of order $n-1$.)
+
+ Our problem is to change the meaning of \MF's ^{brackets} so that
+--
+Andreas Schwab
+schwab@ls5.informatik.uni-dortmund.de
+-------
+
+[ these may already have been sent, but i can't find them quickly. ]
+Date: 23 Feb 1993 20:17:58 +0100 (MEZ)
+From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
+Subject: errors in TeXbook
+
+Hi barbara,
+
+isn't this the time DEK works on TeX again? Have you forwarded him
+the following errors/problems, which I mentioned to you a year ago?
+(All apply to the Oct 89 edition, 9th hardcover printing.)
+
+ ----------------------------------------------------------------------
+
+On p.368 it is specified: ``After ^^ TeX simply adds or subtracts '100
+from the character immediately following.'' The example is given with
+^^j. Aren't lowercase letters in the range a-f and digits forbidden
+due to the new hex input of chars >"7f ?
+[ dek: Page 368 is correct (but not complete). Page 370 likewise.
+ Also you can et p with ^^0 if no hex digit follows (but the
+ full rules are on p47)
+]
+
+ ----------------------------------------------------------------------
+
+On p.226 it is mentioned that two whatsit-nodes are realized as
+extensions to TeX. \language is the third.
+[ dek: Again, page 226 does not claim "two and only two". Page 455
+ mentions the other case. (I've changed the index entry for
+ whatsit, so you win $2.56 for that) p481
+]
+
+ ----------------------------------------------------------------------
+
+Exercise 8.7 is printed twice.
+[ dek: (Known)
+]
+
+This should be mentioned against AW, not against DEK. It's obviously a
+printer's error.
+[ dek: Well, I didn't communicate successfully enough or check it
+ well enough
+]
+
+ ----------------------------------------------------------------------
+
+Joachim
+
+************************************************************************
+
+>>> The TeX program
+
+ +++ Comments at the top of tex.web / mf.web
+
+Date: Mon, 23 Mar 92 18:04:08 GMT
+From: Chris Thompson <CET1@phx.cam.ac.uk>
+Subject: A small oversight in MF.WEB 2.71
+
+Barbara,
+
+ Line 23 of mf/mf.web at labrea (i.e. the new official MF 2.71) reads
+
+% Version 2.71 fixed bug in draw, allowed unprintable filenames (not yet released).
+
+I imagine Don forgot to update it when making 2.7a into 2.71 (they are
+identical apart from the banner change)! Perhaps someone could draw his
+attention to this.
+
+Chris Thompson
+JANET: cet1@uk.ac.cam.phx
+Internet: cet1@phx.cam.ac.uk
+-------
+(reply, 23 Mar 1992)
+chris,
+i noticed that too. similarly in tex.web, in that the date given
+is september '91.
+-------
+
+ ----------------------------------------------------------------------
+
+ +++ Changes in kerning in 3.141
+
+Date: Thu, 19 Mar 92 15:55:26 GMT
+From: Chris Thompson <CET1@phx.cam.ac.uk>
+To: Barbara Beeton <BNB@MATH.AMS.COM>,
+ Brian {Hamilton Kelly} <TeX@rmcs.cran.ac.uk>
+Subject: Bug (?) report on TeX 3.141 by Wayne Sullivan
+
+I have received the following message from Wayne. I am not in a
+position to do *any* testing for the next few days, but it sounds
+as though he's saying that the bug in TeX 3.14a hasn't been entirely
+stopped up in TeX 3.141 (although it did seem to be in 3.14b). Can
+anyone check?
+
+> Accepted: 15:25:12 19 Mar 92
+> Submitted: 15:04:28 19 Mar 92
+> IPMessageId: -unspecified-
+> From: "Wayne G. Sullivan" <WSULIVAN@IE.UCD.IRLEARN>
+> To: Chris Thompson <CET1@UK.AC.CAMBRIDGE.PHOENIX>
+> Subject: TeX 3.141
+>
+> I got the WEB file for 3.141 and adapted my MS-DOS CHG file: The resulting
+> EXE's give no problem with the TRIP test, but as a extra check, I ran off
+> my test version of TEXMAN. The DVI file produced by my 3.141 that of
+> an '89 version differs at only one point: the index entry for `box memory,'.
+> The new version has a kern between the `y' and ',' as there should be for
+> cmr8. However, Knuth has made the comma active for the index so that the
+> usual inner loop does not insert kerns (there are several instances of
+> `y,'). The new DVI file only inserts one kern. Is there something in the
+> new mechanism that could cause the tokens to be rescanned in this single
+> case so that a kern is inserted? The full entry in the index is
+>
+> box memory, 300, 394.
+>
+> Of course it could be a bug in my new version, but it is hard to see how
+> it could cause something like this to happen.
+> Wayne Sullivan
+
+Chris Thompson
+Cambridge University Computing Service
+JANET: cet1@uk.ac.cam.phx
+Internet: cet1@phx.cam.ac.uk
+-------
+Date: Fri, 20 MAR 92 18:35:49 GMT
+Reply-to: Brian {Hamilton Kelly} <TeX@rmcs.cranfield.ac.uk>
+From: TEX@rmcs.cranfield.ac.uk
+Subject: RE: TeX 3.141
+
+In a message to BHK of Fri, 20 Mar 92 13:03:51 GMT,
+"Wayne G. Sullivan" <WSULIVAN@IE.UCD.IRLEARN> wrote:
+
+> In testing an MS-DOS version of TeX 3.141, I noticed an example where
+> the DVI file produced by 3.141 differs from that produced by 3.14. The
+> test file I used is over 1 Mbyte, but I have been able to produce the
+> same problem in a much smaller file. I thought Knuth always tried to
+> make upgrades of TeX downward compatible, so 3.14 and 3.141 should
+> not yield different DVI files in this case. It is possible that the
+> difference is due to something I have done to my CHG file -- but the
+> CHG files for 3.14 and 3.141 are nearly the same. Could you check to see
+> whether your VAX versions of TeX produce different DVI files for
+> the input file included below?
+>
+> %% 3.141 DVI file includes a kern between `y' and `,' in `memory,'
+> %% but not in `display,' .
+> %% 3.14 DVI file does not have a kern in either case.
+>
+> \let\comma=,%
+> \let\period=.%
+> \raggedright \tolerance=5000 \hbadness=5000 \parfillskip 0pt plus 3em
+> \hsize=17.5pc
+> \catcode`\,=\active \def,{\tenrm\comma}
+> \catcode`\.=\active \def.{\tenrm\period\par\hangindent 2em }
+> \parindent0pt\relax
+> box display, 66, 75, 79, 158--159, 302, 455.
+> box memory, 300, 394.
+> \bye
+
+I can confirm this phenomenon: moreover, the additional kern first
+appears at V3.14a, and is also present in V3.14b. Goodness alone knows
+why just this one manifestation occurs in such a huge test file. The
+point is: should DEK fix it?
+
+Brian
+PS My mailer ain't very clever: this was REPLYed to Wayne, and copied to
+bnb and Chris Thompson
+-------
+Date: Sun, 22 Mar 92 02:23:46 GMT
+From: CET1@phx.cam.ac.uk
+To: tex-implementors@MATH.AMS.COM
+Cc: Wayne Sullivan <WSULIVAN@IRLEARN.UCD.IE>,
+ Brian {Hamilton Kelly} <TeX@rmcs.cran.ac.uk>, Barbara Beeton <BNB@MATH.AMS.COM>
+Subject: A feature(?) of TeX 3.141 discovered by Wayne Sullivan
+
+Wayne Sullivan has discovered a situation in which TeX 3.141 gives
+different character spacing from TeX 3.14. I think it is probably a
+`feature', but maybe it is a `bug': read the following and judge for
+yourselves. The change was in fact already present in the alpha test
+versions 3.14a and 3.14b, but Brian and I failed to discover it.
+
+Here is Wayne's original report to me
+
+> I got the WEB file for 3.141 and adapted my MS-DOS CHG file: The
+> resulting EXE's give no problem with the TRIP test, but as a extra
+> check, I ran off my test version of TEXMAN. The DVI file produced by
+> my 3.141 that of an '89 version differs at only one point: the index
+> entry for `box memory,'. The new version has a kern between the `y'
+> and ',' as there should be for cmr8. However, Knuth has made the comma
+> active for the index so that the usual inner loop does not insert
+> kerns (there are several instances of `y,'). The new DVI file only
+> inserts one kern. Is there something in the new mechanism that could
+> cause the tokens to be rescanned in this single case so that a kern is
+> inserted? The full entry in the index is
+>
+> box memory, 300, 394.
+>
+> Of course it could be a bug in my new version, but it is hard to see
+> how it could cause something like this to happen.
+
+and later he provided the following stripped down test case
+
+> Yet a simpler file displaying the problem. With 3.141 one `y,' has no
+> kern (display,) while the other does (memory,). 3.14 has no kern for
+> both cases.
+>
+> \let\comma=,%
+> \let\period=.%
+> \raggedright \tolerance=5000 \hbadness=5000 \parfillskip 0pt plus 3em
+> \hsize=17.5pc
+> \catcode`\,=\active \def,{\tenrm\comma}
+> \catcode`\.=\active \def.{\tenrm\period\par\hangindent 2em }
+> \parindent0pt\relax
+> box display, 66, 75, 79, 158--159, 302, 455.
+> box memory, 300, 394.
+> \bye
+
+The fact that the comma is active is significant only in that it
+generates a "\tenrm" between the "y" and the ",". This causes TeX
+(in |main_control|) to think they are in separate words and so the
+usual implicit kern doesn't get generated. There is no change here
+in TeX 3.141.
+
+In TeX 3.14 and earlier, if automatic hyphenation was later applied
+to the horizontal list, no change was made here. In TeX 3.141, however,
+automatic hyphenation re-asseses the relationship between the last
+letter of the word and subsequent punctuation, and reinserts the
+implicit kern. (TeX 3.141 has changes in this area to fix bugs
+associated with right boundary characters, discovered by Brian HK.)
+The effect can be demonstrated by a simple test:
+
+ % TeX 3.141 (3.14a,3.14b) test following Wayne Sullivan.
+ \ Display\tenrm,\par
+ \ Display{}.\par
+ \pretolerance=-1 % now force a hyphenation pass
+ \ Display\tenrm,\par
+ \ Display{}.\par
+ \showboxbreadth=255 \showboxdepth=255 \showlists
+ \bye
+
+In TeX 3.14 the kerns never reappear, in TeX 3.141 they reappear just
+in the last two cases.
+
+Note: I am relying on Wayne and Brian in saying that the effect happens
+in TeX 3.141; at the moment I only have 3.14a and 3.14b available. But
+I don't believe there is any significant change between 3.14b and 3.141.
+
+Of course, we are used to the fact that TeX's automatic hyphenation
+recalculates ligatures and implicit kerns within a word. We know that
+it is not sufficient to write `shelf{}ful', but that we must must use
+`shelf\/ful' (say) instead. The change in TeX 3.141 extends this state
+of affairs slightly. So: `feature' or `bug' ?
+[ dek: ^^^^^^^
+ Chris' explanation is lucid and correct, as usual. But nobody
+ has explained why TeX would try hyphenation for `box memory'
+ (the short line) _rather_ than `box display' (the long line)!
+ The reason is that the index is typeset with special parfillskip
+ that tries to avoid short last lines. So `box display' turns
+ out to meet pretolerance but `box memory' doesn't. Even more
+ interesting is the index entry `beauty, 1.' which spectacularly
+ fails to meet pretolerance [badness 2913] yet it does _not_
+ gain a kern. The reason is that TeX finds no hyphenation points
+ in `beauty' so does not bother reconstructing its kerns.
+ [Please communicate this to Chris and the others. By the way,
+ shelf\-ful is better than shelf\/ful on two counts: (1) it
+ hyphenates; (2) it works in italics.]
+]
+
+Chris Thompson
+Cambridge University Computing Service
+JANET: cet1@uk.ac.cam.phx
+Internet: cet1@phx.cam.ac.uk
+-------
+Date: Sun, 22 Mar 1992 22:42 GMT +0100
+From: Frank Mittelbach <MITTELBACH@MZDMZA.ZDV.UNI-MAINZ.DE>
+To: CET1@PHX.CAM.AC.UK, BNB@MATH.AMS.COM, WSULIVAN%IRLEARN.BITNET@vm.gmd.de,
+ TEX@RMCS.CRANFIELD.AC.UK
+Subject: Re: bug or feature in 3.141
+
+> Note: I am relying on Wayne and Brian in saying that the effect happens
+> in TeX 3.141; at the moment I only have 3.14a and 3.14b available. But
+> I don't believe there is any significant change between 3.14b and 3.141.
+
+I checked that the effect doesn't happen with 3.14 as distributed by
+ArborText so it was most certainly introduced with the last changes.
+
+> Of course, we are used to the fact that TeX's automatic hyphenation
+> recalculates ligatures and implicit kerns within a word. We know that
+> it is not sufficient to write `shelf{}ful', but that we must must use
+> `shelf\/ful' (say) instead. The change in TeX 3.141 extends this state
+> of affairs slightly. So: `feature' or `bug' ?
+
+I would vote for feature, not that I like this particular one :-) but
+the new behavior seems in my eyes more consistent then TeX's behavior
+before. The whole area of loosing information when reconstructing the
+horizontal list after hyphenation is something I think is a
+(mis)feature since it depends on side effects of other areas.
+
+When one like to call this a bug then only in the respect that \tenrm
+interrupts the construction of ligatures or kerns and this fact is not
+mentioned in the book (so probably $2.56 :-) or is it?
+[ dek: ^^^^^ it is (page 286)
+]
+
+Frank
+
+ ----------------------------------------------------------------------
+
+ +++ \language and \setlanguage
+
+Date: 16 Jul 1992 15:23:11 -0300 (BST)
+From: Chris Thompson <CET1@phx.cam.ac.uk>
+To: Rainer Schoepf <Schoepf@sc.ZIB-Berlin.de>
+Subject: Re: [\language and \setlanguage -- the story continues]
+
+Rainer,
+
+ I am copying this reply to Barbara, and for her benefit I will
+include your original message here:
+
+> I've just spent some time tracing down a strange behaviour with
+> multiple hyphenation patterns. Have a look a the following simple
+> file:
+>
+> ---
+> \language=1
+>
+> \scrollmode
+>
+> \showhyphens{zwischen}
+>
+> \setbox1=\hbox{B\"ohme Robert,}
+> \setbox0=\hbox{Der Lykomide : Tradition und Wandel
+> zwischen Orpheus und Homer :}
+>
+> \hsize=10.2cm
+> \vsize=7,8cm
+>
+> \vbox{\unhbox1 \space\unhbox 0}
+>
+> \eject
+>
+> \bye
+> ---
+>
+> The hyphenation patterns inside the \vbox are that of \language=0.
+> However, if I put one character at the very beginning of the \vbox, it
+> uses \language=1.
+>
+> The reason is rather simple: the procedure new_graf sets the variable
+> clang to 0, and it is set to the value of language ony later, when a
+> character is contributed to the current list. \unhbox does not change
+> the value clang. Of course, I can get around it using \setlanguage.
+[ dek: and \everybox
+]
+>
+> I think this is a bug, since \setlanguage should only be needed when
+> working with more than one language. I think new_graf should initialize
+> clang to the current value of \language. What do you think?
+
+There is no doubt that the current setup gives favoured treatment to
+the \language=0 case. However it certainly wouldn't be right to simply
+modify |new_graf| as you suggest. There are three places which have to
+be kept consistent:
+
+Module 891: <Initialize for hyphenating a paragraph>
+ The value which |cur_lang| is initialised to.
+Module 1091: |new_graf|
+ The value which |clang| is initialised to.
+Module 1200: |resume_after_display|
+ The value which |clang| is initialised to.
+[ dek: and consistent with TeXbook p455 on which people have been
+ told they can rely. However, I guess the rule makes absolutely
+ no difference in any reasonable application, so i have a chance
+ to change page 455.
+]
+
+Currently all the initialisations are zero, and therefore consistent.
+If modules 1091 and 1200 were to use the value of \language, then this
+value has to be remembered somewhere so that module 891 can use it
+(clearly the value of \language when module 891 comes to execute
+is not what is wanted). Note that the values of \lefthyphenmin and
+\righthyphenmin have to be remembered in the vertical mode |nest| entry
+*below* the |nest| entry for the paragraph itself, as the latter no
+longer exists when module 891 executes.
+
+A possible line to take would be that whenever unrestricted horizontal
+mode is started (modules 1091 and 1200), a \setlanguage whatsit should
+be automatically generated if \language is non-zero. This would make
+these values more like first-class citizens: one could view the special
+arrangements for remembering \lefthyphenmin and \righthyphenmin
+in |nest| as merely an optimisation for the common case when \language
+is zero. But there are potential problems with this: for example, is
+the whatsit to be inserted before or after the \everypar tokens are
+scanned? If before, the \everypar{\setbox0=\lastbox} mechanism will
+no longer work: if after, what if the \everypar does something like
+your \unhbox'ing?
+
+Whatever Don may want to do about the above, I think the following is
+definitely a bug:
+
+> \language=0 % throughout
+> \hsize=1in
+> \tracingparagraphs=\maxdimen
+>
+> \lefthyphenmin=1 \righthyphenmin=1
+> This is the moment in time for all good men,
+> \lefthyphenmin=2 \righthyphenmin=3 \setlanguage\language
+> to come to the assistance of the party.
+> $$ x\sp n+y\sp n \ne z\sp n $$
+> as Pierre Fermat announced to all and sundry, although he
+> couldn't fit the proof into his margin.
+>
+> \bye
+
+The text after the displayed equation reverts to being hyphenated
+with (left,right)hyphenmin=(1,1), even though that immediately before
+the equation has (2,3). This is because |resume_after_display| in
+module 1200 doesn't set |lhmin| & |rhmin| in the way that module 1091
+does, but instead leaves the values set by the original |new_graf|.
+I think this is just wrong, even though changing \{left,right}hyphenmin
+without changing \language is, perhaps, a rather unusual thing to do.
+[ dek: True; I shall have to fix this in 3.415 $20.48
+ And then I have to essentially contradict page 455 because
+ I'm resetting clang to 0 after every displayed equation, not
+ only at beginning of paragraph. So the rules stated in
+ TeXbook are faulty.
+]
+
+Chris Thompson
+Cambridge University Computing Service
+JANET: cet1@uk.ac.cam.phx
+Internet: cet1@phx.cam.ac.uk
+-------
+Date: 16 Jul 1992 17:48:17 +0200
+From: schoepf@sc.ZIB-Berlin.DE (Rainer Schoepf)
+To: Chris Thompson <CET1@PHOENIX.CAMBRIDGE.ac.uk>
+Subject: Re: [\language and \setlanguage -- the story continues]
+
+Chris,
+
+(A copy of this message goes to Barbara.)
+
+ > There is no doubt that the current setup gives favoured treatment to
+ > the \language=0 case. However it certainly wouldn't be right to simply
+ > modify |new_graf| as you suggest. There are three places which have to
+ > be kept consistent:
+ >
+ > Module 891: <Initialize for hyphenating a paragraph>
+ > The value which |cur_lang| is initialised to.
+ > Module 1091: |new_graf|
+ > The value which |clang| is initialised to.
+ > Module 1200: |resume_after_display|
+ > The value which |clang| is initialised to.
+ >
+ > Currently all the initialisations are zero, and therefore consistent.
+
+I agree that they are consistent with each other but, in my opinion,
+not consistent with the setting of language. The conclusion is that
+you cannot globally set language to a value different from 0, since
+TeX will sometimes use the hyphenation patterns for language 0.
+[ dek: The intent was to have language 0 be the user's "global"
+ language [not to have it be English]. But I guess this
+ requires more .fmt files (one for each home language)
+]
+
+ > If modules 1091 and 1200 were to use the value of \language, then this
+ > value has to be remembered somewhere so that module 891 can use it
+ > (clearly the value of \language when module 891 comes to execute
+ > is not what is wanted). Note that the values of \lefthyphenmin and
+ > \righthyphenmin have to be remembered in the vertical mode |nest| entry
+ > *below* the |nest| entry for the paragraph itself, as the latter no
+ > longer exists when module 891 executes.
+
+I'd argue that cur_lang should be set to the value of language that
+was in effect at the beginning of the paragraph. I haven't thought
+this completely through yet, but wouldn't it be just sufficient to set
+cur_lang to clang in module 891? When this code is executed, the
+semantic nest has already been popped, so that clang is the value that
+was in effect just before the call to new_graf. On the other hand, if
+there was a change to \language in between, then a setlanguage whatsit
+will be present, and cur_lang be set appropriately.
+
+ Rainer Schoepf
+ Konrad-Zuse-Zentrum ,,Ich mag es nicht, wenn
+ fuer Informationstechnik Berlin sich die Dinge so frueh
+ Heilbronner Strasse 10 am Morgen schon so
+ W-1000 Berlin 31 dynamisch entwickeln!''
+ Federal Republic of Germany
+ <Schoepf@sc.ZIB-Berlin.de> or <Schoepf@sc.ZIB-Berlin.dbp.de>
+-------
+Date: 17 Jul 1992 14:38:53 -0300 (BST)
+From: Chris Thompson <CET1@phx.cam.ac.uk>
+To: Rainer Schoepf <Schoepf@sc.ZIB-Berlin.de>
+Subject: Re: [\language and \setlanguage -- the story continues]
+
+Rainer (& Barbara),
+
+> I agree that they are consistent with each other but, in my opinion,
+> not consistent with the setting of language. The conclusion is that
+> you cannot globally set language to a value different from 0, since
+[ dek:^^^^^^^^^^^^^^^
+ you can just say \everyhbox{\setlanguage 1}
+ (Agreed that this is not 100% efficient!)
+]
+> TeX will sometimes use the hyphenation patterns for language 0.
+
+I wasn't saying (I think) that they shouldn't be changed, just that
+they need to be changed consistently.
+
+> I'd argue that cur_lang should be set to the value of language that
+> was in effect at the beginning of the paragraph. I haven't thought
+> this completely through yet, but wouldn't it be just sufficient to set
+> cur_lang to clang in module 891? When this code is executed, the
+> semantic nest has already been popped, so that clang is the value that
+> was in effect just before the call to new_graf. On the other hand, if
+> there was a change to \language in between, then a setlanguage whatsit
+> will be present, and cur_lang be set appropriately.
+
+No, this is confused. |clang| is part of the |aux| field in a |nest|
+entry, and is only defined when the mode is horizontal. The current
+mode is vertical when module 891 is executing. Notice how |lhmin| and
+|rhmin| are set *before* the |push_nest| in |new_graf|, while |clang|
+is set *after*.
+
+The |lhmin| and |rhmin| fields exist in every |nest| entry (although
+only used in a few). It would be perfectly possible to add a new field
+to the structure to save the initial \language value, in the same way:
+this would be the cleanest thing to do and I should have mentioned it.
+But it would mean increasing the size of each |list_state_record|.
+
+ --- Pause ---
+
+Ah ha! There is something one could do to achieve this effect *without*
+increasing the size of |list_state_record|, and indeed reclaiming the
+2 quarterwords |lhmin| and |rhmin| that were added to it in TeX 3.0. The
+|prev_graf| field exists in all |nest| entries but contains meaningful
+information only for those with vertical mode. Use a redefinition of
+this field for the unrestricted horizontal mode entry to hold the
+*initial* values of \lefthyphenmin, \righthyphenmin, *and* \language
+in |new_graf| and |resume_after_display|; they would fit easily enough.
+Then break the values out into local variables in |line_break| *before*
+the |pop_nest| (module 816), so that they are available to module 891.
+
+I rather like this scheme.
+
+Chris Thompson
+Cambridge University Computing Service
+JANET: cet1@uk.ac.cam.phx
+Internet: cet1@phx.cam.ac.uk
+-------
+[ dek: OK, it's in.
+ No advantage to the old rule and no reason to assume anybody
+ made use of it in ways that are incompatible with the new one.
+]
+
+ ----------------------------------------------------------------------
+
+ +++ Cramped style inconsistencies
+
+[ i forwarded this to chris thompson, but received no reply. ]
+Date: 17 Sep 1992 14:06:57 -0400 (EDT)
+From: herschor@math.mcgill.ca (Michael Herschorn)
+To: BNB@MATH.AMS.ORG
+Subject: Is it a bug?
+
+On July 21 I sent the appended lengthy submission to Info-Tex, and
+it was automatically posted to comp.text.tex on the net. (Because of
+its length, I do not use the standard quotation indicators.)
+
+I have received no comments; maybe that's because it's much ado
+about not very much. (Since I'm a relative newcomer to TeX, it may also
+be because I'm totally "off-track".) Nevertheless, there's at least one
+part of the submission that you are best placed to give an opinion on. It
+reads:
+
+: (I also haven't come across any discussion of a "feature" which turns
+: cramping off, viz., prefix the material which TeX would normally
+: cramp by an explicit style reminder. Compare, for example,
+: $\sqrt{X^2+Y^2}$ with $\sqrt{\textstyle X^2+Y^2}$. However, I doubt
+: that this is an intended feature since:
+: i) TeX is normally insensitive to redundant style commands, and from
+: the user's point of view, this is the way it should be; and,
+: ii) cramping will be turned off in midstream by an explicit style
+: command (e.g., $\sqrt{X^2+\textstyle Y^2} has X^2 in cramped style
+: and Y^2 in uncramped style).
+: I am completely out of my depth when it comes to understanding the
+: details of The Program, and please, no flames (not even for the
+: mixing of metaphors!), but it seems to me that this "feature"
+: is a result of the cramped_style calculation in section 702 of The
+: Program being ignored while section 703 updates only size-dependent
+: quantities.
+: Although I reserve my rights to priority for the "finder's fee"
+: mentioned in the Preface to The Program, I would like to hear the
+: opinions of gurus on the net.)
+
+I would greatly appreciate your comments on these paragraphs, and if
+you care to, on the rest of the posting.
+
+Michael Herschorn
+
+[ dek: TeX should have had a primitive something like `\cramp' to force
+ a cramped style, but it's too late now. TeX shouldn't preserve
+ crampedness when \textstyle comes along because then there's
+ no way to override it... well I guess one could use \hbox but
+ again it is too late to make changes.
+]
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%%
+%% July 21, 1992 Posting
+%%
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+Newsgroups: comp.text.tex
+Date: Tue, 21 Jul 92 12:25:00 EDT
+Organization: Info-Tex<==>Comp.Text.Tex Gateway
+From: herschor@math.mcgill.ca (Michael Herschorn)
+Subject: CRAMPED STYLES & solution to:fraction spacing default_rule_thickness.
+Lines: 374
+
+ At the end of this submission you will find a solution to the
+ problem relating to the minimum separation between the numerator or
+ denominator of a fraction and the fraction bar, a question raised and
+ discussed in several postings last month. I would like
+ to begin with a more general problem which provides the tool
+ used for that solution.
+
+ PART ONE:
+
+ To measure typeset text from a math list in TeX, the material is
+ placed in an \hbox. One must then specify the style of
+ the text's "free state" inside the box. The horizontal dimension in
+ the free state is affected by "actions at infinity" (glue) and is
+ intrinsically uncertain; the height and depth are determined
+ "quasi-locally", and are fixed once TeX decides on the current style.
+ However, if an item is to be set in a cramped style, absent a TeX
+ command \cramp{}, how does one measure its height and depth?
+
+ I have also felt a need for \cramp for aesthetic reasons when there
+ is a repetition of an expression close by the original in a line of
+ text, once in
+an uncramped style, and once in the corresponding
+ cramped style. As well, there is a not insignificant amount of space
+ that can be saved in a document with multiple occurrences of, e.g.,
+ ${\x}^{{\x}^{{\x}^{\cdot^{\cdot^{\cdot^{\x}}}}}}$, if this could
+ be set in a cramped style.
+[ dek: For such a document I would fiddle with parameter \sigma_14
+]
+
+ I have most of the standard TeX references, but I haven't come across
+ any mention of the possibility of obtaining a cramped style "on
+ demand". Thus there may be some general interest in the preliminary
+ version of my <cramped.sty> macro, and I append it below.
+
+ (I also haven't come across any discussion of a "feature" which turns
+ cramping off, viz., prefix the material which TeX would normally
+ cramp by an explicit style reminder. Compare, for example,
+ $\sqrt{X^2+Y^2}$ with $\sqrt{\textstyle X^2+Y^2}$. However, I doubt
+ that this is an intended feature since:
+[ dek: It is "intended" in the sense that it is rule 3 on page 442
+]
+ i) TeX is normally insensitive to redundant style commands, and from
+ the user's point of view, this is the way it should be; and,
+ ii) cramping will be turned off in midstream by an explicit style
+ command (e.g., $\sqrt{X^2+\textstyle Y^2} has X^2 in cramped style
+ and Y^2 in uncramped style).
+ I am completely out of my depth when it comes to understanding the
+ details of The Program, and please, no flames (not even for the
+ mixing of metaphors!), but it seems to me that this "feature"
+ is a result of the cramped_style calculation in section 702 of The
+ Program being ignored while section 703 updates only size-dependent
+ quantities.
+ Although I reserve my rights to priority for the "finder's fee"
+ mentioned in the Preface to The Program, I would like to hear the
+ opinions of gurus on the net.)
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+% cramped.sty Preliminary version July 21,1992
+%
+% Enables the typesetting of material in the cramped styles
+% D', T', S' and SS'.
+%
+% \cramp{<foo.bar>} will set <foo.bar> in the cramped version C' of
+% the current style C.
+%
+% \Cramp{\...style}{<foo.bar>} (where you specify the current style)
+% has been left accessible.
+%
+%
+% Author: Michael Herschorn
+% Departmentof Mathematics and Statistics
+% McGill University
+% 805 Sherbrooke Street West Phone: 514-398-3825
+% Montreal QC CANADA H3A 2K6 FAX: 514-398-3899
+% email: herschor@gauss.math.mcgill.ca
+%
+% Please email me your comments and suggestions as well as informing
+% me directly of any bugs you may find.
+%
+%
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\catcode`@=11
+\def\cramp{\mathpalette\Cramp}%
+\def\Cramp#1#2{\setbox0=\hbox{$\m@th#1\cr@mp{#2}$}
+% [ dek: As an alternative, you could reset \nulldelimiterspace here
+% ]
+ \Ch@p#1 \dimen2=\the\ht0 \advance\dimen2 -\dimen0
+ \ht0=\the\dimen2 \box0}
+\def\cr@mp{\kern-\the\nulldelimiterspace\radical"380380}%
+% [ dek: ^^^^^^^
+% nonexistent characters; better to say \radical 0
+% ]
+\def\Ch@p#1{\ifx#1\displaystyle
+ \dimen0=\the\fontdimen5\textfont2
+ \advance\dimen0 -.75\dimen0
+% [ dek: why not say \dimen0=.25\fontdimen5\textfont2
+% ]
+ \advance\dimen0\the\fontdimen8\textfont3
+ \else
+%% \ifx#1\textstyle
+ \dimen0=\the\fontdimen8\textfont3
+ \advance\dimen0 .25\dimen0
+ \fi}%%%%%%%%% If you have "variations" in family 3,
+%%%%%% comment out the preceding line and "uncomment"
+%%%%%% the 7 lines beginning with "%%".
+%% \else
+%% \ifx#1\scriptstyle\dimen0=\the\fontdimen8\scriptfont3
+%% \advance\dimen0 .25\dimen0
+%% \else \dimen0=\the\fontdimen8\scriptscriptfont3
+%% \advance\dimen0 .25\dimen0
+%% \fi\fi\fi}
+\catcode`@=12
+\endinput
+%%
+% end of file cramped.sty
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+[ dek: The same idea
+ but using TeX more fluently:
+ \def\Cramp#1#2{\setbox0=\hbox{\nulldelimiterspace=\z@
+ @\m@th#1\radical0{#2}$}%
+ \ifx#1\displaystyle
+ \dimen0=\fontdimen8\textfont3
+ \advance\dimen0 .25\fontdimen5\textfont2
+ \else \dimen0=1.25\fontdimen8
+ \ifx#1\textstyle\textfont
+ \else\ifx#1\scriptstyle\scriptfont\else\scriptscriptfont
+ \fi\fi 3 \fi
+ \advance\dimen0-\ht0 \ht0=-\dimen0 \box0 \relax}
+
+ (He uses \the' unnecessarily and doesn't factor \if...\fi)
+
+ This works. (worth publishing in TUGboat)
+ ----
+ Note that \cramp{x^{\cramp{y^2}}}
+ causes TeX to typeset y^2 16 times!
+ The same is true whenever a \mathpalette is inside a \mathpalette
+]
+
+
+ PART TWO:
+
+ Michael Downes <MJD@MATH.AMS.COM> (22 Jun 1992, Info-TeX@shsu.edu)
+ wrote:
+
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++Dan Luecking wrote (19 Jun 1992, Info-TeX@shsu.edu):
++
++> Michael Barr posted a query a while back about the separation
++> between the numerator/denominator of a fraction and the fraction bar.
++>
++> I have not seen a response, so having tried to understand the
++> TeXbook on this point and made some headway in doing so I thought
++> I might discuss the problem.
++
++> ... I have run into it several times and would like to know if
++> anyone has defined a fraction making command to deal with it. One
++> way is to insert a 0 width rule extending below the numerator and
++> above the denominator, but I do not see a good way to make this
++> automatic. A way I have considered, but rejected, is to increase the
+[ dek: clever thought
+]
++> relevant parameter, (something like \fontdimen8\textfont3=1pt
++> instead of 0.4pt) and then define all \frac's using \above (in which
++> the thickness of the rule is explicitly given). The problem is that
++> default_rule_thickness is used in several internal calculations
+[ dek: \overline is screwed up but could be handled as special kind
+ of \radical (with new font)!
+]
++> including the positioning of sub/superscripts.
+[ dek: rule 18e, not too bad if increased
+]
++>
++> Does anybody have anything to say about this?
++
++ I have observed the same problem in Amer. Math. Soc. publications,
++ although the examples I've happened to notice involved letters with
++ descenders such as p and q, rather than vertical bars. Your analysis
++ of the problem corresponds closely to what I found in some cursory
++ investigations.
++
++ The problem seems to be slightly worse than you suggest---or maybe you
++ just didn't bother to amplify on results of your experiments: The most
++ significant drawback of the rejected solution of setting \fontdimen 8
++ \textfont 3 to a larger value and using \above instead of \over is
++ not the internal calculations you mention but the fact that the fraction
++ bar thickness and the space around it are always dependent, even in
++ \above, so that if we say $1\above.4pt 2$ the space around the
++ fraction bar is calculated from the .4pt, not from \fontdimen 8 of
++ \textfont 3, and we're back where we started from.
+[ dek: Oh, right!
+]
++
++> ... Is it worthwhile suggesting
++> that a major macro package try do something about it? Have any done
++> anything?
++
++ If my understanding of the problem is correct, it's impossible for a
++ macro package to provide any reasonable solution. The only reasonable
++ solution is to change TeX, the program. (And my definition of
++ `reasonable' is pretty extreme when it comes to macro writing; I have
++ done or contemplated doing things at the macro level that any
++ `reasonable' programmer would consider unreasonable.)
++
++> Is there any real problem at higher resolutions (i.e., does
++> everything look OK printed at 1000dpi)?
++
++ In my opinion, there is not enough space around the fraction bar in
++ the problematic combinations (textstyle fractions, vertical bars,
++ letters with descenders), even at high resolution. I'd rather have
++ some control to adjust the space slightly.
+[ dek: For these you are probably best off tuning the \sigma's...
+ although it's probably OK to teach keyboarders what I actually
+ do [see next comment]
+]
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+
+ The Grand Wizard made his design choices a.e. optimally, and I would
+ stick with his implementation of 15d in Appendix G of The TeXbook.
+ Apparent differences between the letter-base levels in the numerators
+ and in the denominators of fractions in the same line spoil the
+ appearance of the line; shifting the numerator up or the denominator
+ down in a fraction with adequate clearance so as to match the letter-
+ base levels of another fraction in the line introduces ugly white
+[ dek: I am occasionally unhappy with fractions, much more often
+ unhappy with \root's, and guilty of overlooking several
+ fontdimens in false belief that I was getting more
+ unity/elegance. So I occasionally use ^{\mathstrut} in
+ denominators (or superscripts therein), often in \root's,
+ _{\mathstrut} in numerators (or subscripts therein).
+]
+ space. The more I understand the problem, the better I like the GW's
+ balancing act.
+
+ Nevertheless, as pointed out by Dan Luecking, Berthold K.P. Horn and
+ Michael Downes, it would have been nice to have a free parameter to
+ adjust in special circumstances. ("Just so you shouldn't need to
+ use it", as the Yiddish expression puts it.)
+
+ Once we have <cramped.sty>, it becomes a simple hack to solve this
+ problem (and other similar ones). I wrote (and attach a copy of)
+ <spreadfraction.sty> as an illustration. (The coding is not elegant,
+ but it works.) It should be used only when absolutely necessary,
+ and even then, it should be used sparingly.
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+% spreadfraction.sty Preliminary version July 21,1992
+%
+% If used in a non-cramped context, \xfrac{#1}{#2}{#3} produces
+% {#1\over #2} exactly as TeX would, except that the minimum clearance
+% that will be tolerated between the numerator or denominator of this
+% fraction and the bar line is #3 times the default rule thickness.
+% (See Rule 15d in Appendix G of The TeXbook. TeX hardwires in
+% #3=3 in \displaystyle and #3=1 in the other styles; spreadfraction.sty
+% allows the use of arbitrary values. In other words, .phi. is replaced
+% by #3 times the default rule thickness, everything else is kept
+% constant.)
+%
+% In a cramped context, i.e., if the entire fraction is a Rad atom
+% (under a root sign), an Over atom (from \overline), in the denominator
+% of another fraction, is a subscript, or is a superscript to an
+% entity in cramped style, \xfracc{#1}{#2}{#3} should be used instead
+% of \xfrac{#1}{#2}{#3}. (I may automate the selection of \xfracc in a
+% future version; since spreadfraction.sty is intended for touch-up use,
+% I don't consider automation a priority (and it may be like putting a
+% tiara on a baglady!)).
+%
+% \Xfrac{\...style}{}{}{} (identical to \xfrac{}{}{}, except
+% that you specify the style) and \Xfracc{\...style}{}{}{} (DITTO),
+% have been left accessible to the user.
+%
+% To obtain a version of spreadfraction in which the minimum clearances
+% are #3 times the hardwired ones, declare \DEKtrue after inputting
+% spreadfraction.sty
+%
+%
+% Author: Michael Herschorn
+% Departmentof Mathematics and Statistics
+% McGill University
+% 805 Sherbrooke Street West Phone: 514-398-3825
+% Montreal QC CANADA H3A 2K6 FAX: 514-398-3899
+% email: herschor@gauss.math.mcgill.ca
+%
+% Please email me your comments and suggestions as well as informing
+% me directly of any bugs you may find.
+%
+%
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\newif\ifDEK
+\input cramped.sty
+\catcode`@=11
+\def\xfrac#1#2#3{\M@thpalette\Xfrac{#1}{#2}{#3}}
+\def\M@thpalette#1#2#3#4{%
+ \mathchoice{#1\displaystyle{#2}{#3}{#4}}%
+ {#1\textstyle{#2}{#3}{#4}}%
+ {#1\scriptstyle{#2}{#3}{#4}}%
+ {#1\scriptscriptstyle{#2}{#3}{#4}}}
+\def\Xfrac#1#2#3#4{\ifx#1\displaystyle
+ \def\C@rr@ntF@nt{\textfont}
+ \let\@djSt@le=\textstyle
+ \L@rgeS@ze#1{#2}{#3}{#4}
+ \else
+ \ifx#1\textstyle \def\C@rr@ntF@nt{\textfont}
+ \let\@djSt@le=\scriptstyle
+ \N@rmalS@ze#1{#2}{#3}{#4}
+ \else
+ \ifx#1\scriptstyle
+ \def\C@rr@ntF@nt{\scriptfont}
+ \let\@djSt@le=\scriptscriptstyle
+ \N@rmalS@ze#1{#2}{#3}{#4}
+ \else
+ \def\C@rr@ntF@nt{\scriptscriptfont}
+ \let\@djSt@le=\scriptscriptstyle
+ \N@rmalS@ze#1{#2}{#3}{#4}
+ \fi
+ \fi
+ \fi}
+\def\L@rgeS@ze#1#2#3#4{\dimen1=\the\fontdimen8\textfont2
+ \dimen2=\the\fontdimen11\textfont2
+ \N@mer@tor#1{#2}{#3}{#4}}
+\def\N@rmalS@ze#1#2#3#4{%
+ \dimen1=\the\fontdimen9\C@rr@ntF@nt2
+ \dimen2=\the\fontdimen12\C@rr@ntF@nt2
+ \N@mer@tor#1{#2}{#3}{#4}}
+\def\N@mer@tor#1#2#3#4{%
+ \dimen3=\the\fontdimen22\C@rr@ntF@nt2
+ \dimen4=\the\fontdimen8\C@rr@ntF@nt3
+ \dimen5=#4\dimen4
+ \ifDEK\ifx#1\displaystyle\advance\dimen5 2\dimen5
+ \else
+ \fi
+ \else
+ \fi
+ \advance\dimen4 -.5\dimen4
+ \setbox1=\hbox{$\m@th\@djSt@le{#2}$}
+ \dimen0=\dimen1 \advance\dimen0 -\the\dp1
+ \advance\dimen0 -\dimen3
+ \advance\dimen0 -\dimen4
+ \ifdim\dimen5>\dimen0 \advance\dimen1 \dimen5
+ \advance\dimen1 -\dimen0
+ \D@nomin@tor#1{#3}
+ \else
+ \D@nomin@tor#1{#3}
+ \fi}
+\def\D@nomin@tor#1#2{%
+ \setbox2=\hbox{$\m@th
+ \@djSt@le\Cramp\@djSt@le{#2}$}
+ \dimen0=\dimen2 \advance\dimen0 \dimen3
+ \advance\dimen0 -\the\ht2
+ \advance\dimen0 -\dimen4
+ \ifdim\dimen5>\dimen0 \advance\dimen2 \dimen5
+ \advance\dimen2 -\dimen0 \Qu@ti@nt#1
+ \else
+ \Qu@ti@nt#1
+ \fi}
+\def\Qu@ti@nt#1{%
+ \ifdim\wd1<\wd2 \dimen9=\the\wd2
+ \setbox3=\hbox to \the\dimen9{%
+ $\m@th\hfil\box1\hfil$}
+ \setbox1=\box3 \dimen8=\dimen9
+ \else \dimen9=\the\wd1
+ \setbox3=\hbox to \the\dimen9{%
+ $\m@th\hfil\box2\hfil$}
+ \setbox2=\box3
+ \fi
+ \advance\dimen1 -\the\dp1
+ \advance\dimen1 -\dimen3
+ \advance\dimen1 -\dimen4
+ \dimen6=\dimen2 \advance\dimen6 -\the\ht2
+ \advance\dimen6 \dimen3
+ \advance\dimen6 -\dimen4
+ \kern\the\nulldelimiterspace
+ \raise-\the\dimen2 \hbox to\the\dimen9{%
+ \vbox{\box1\kern\the\dimen1\hrule
+ \kern\the\dimen6\box2}}
+ \kern\the\nulldelimiterspace}
+\def\Xfracc#1#2#3#4{\ifx#1\displaystyle
+ \let\@djSt@l@=\textstyle
+ \G@toResult{#1}{#2}{#3}{#4}
+ \else
+ \ifx#1\textstyle \let\@djSt@l@=\scriptstyle
+ \G@toResult{#1}{#2}{#3}{#4}
+ \else
+ \let\@djSt@l@=\scriptscriptstyle
+ \G@toResult{#1}{#2}{#3}{#4}
+ \fi
+ \fi}
+\def\G@toResult#1#2#3#4{%
+ \Xfrac#1{\Cramp\@djSt@l@{#2}}{#3}{#4}}
+\def\xfracc#1#2#3{\mathchoice
+ {\Xfrac\displaystyle{\Cramp\textstyle{#1}}{#2}{#3}}%
+ {\Xfrac\textstyle{\Cramp\scriptstyle{#1}}{#2}{#3}}%
+ {\Xfrac\scriptstyle{\Cramp%
+ \scriptscriptstyle{#1}}{#2}{#3}}%
+ {\Xfrac\scriptscriptstyle{\Cramp%
+ \scriptscriptstyle{#1}}{#2}{#3}}}
+\catcode`@=12
+\endinput
+%%
+%% end spreadfraction.sty
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+ I would appreciate comments and feedback by email and shall
+ summarize and post.
+
+ Michael Herschorn
+
+***********************************************************************
+
+ Michael Herschorn email:herschor@gauss.math.mcgill.ca
+ Department of Mathematics and Statistics fax: 514-398-3899
+ McGill University phone: 514-398-3825
+ 805 Sherbrooke Street West
+ Montreal QC CANADA H3A 2K6
+
+***********************************************************************
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%%
+%% End of July 21, 1992 Posting
+%%
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+-------
+Date: 29 Jan 1993 02:29:26 -0500 (EST)
+From: herschor@math.mcgill.ca (Michael Herschorn)
+
+My understanding is that February is the month in which you present
+DEK with a list of possible bugs for his consideration.
+
+Since February is almost upon us, I would like to draw your
+attention to our previous e-mail exchanges [ ... ]
+
+Perhaps the simplest thing would be to typeset
+$${1\over x^2}{1\over\textstyle x^2}$$
+$${1\over X^2}{1\over\textstyle X^2}$$
+and look closely at the positioning of the exponents in the denominators
+(and the denominators themselves).
+
+TIA
+
+Michael Herschorn
+
+************************************************************************
+
+>>> plain.tex (includes one possible TeX bug)
+
+Date: Sun, 10 May 92 15:33:59 EDT
+From: "Walter D. Neumann" <neumann@function.mps.ohio-state.edu>
+Subject: plain.tex bugs
+
+Dear Barbara,
+
+In creating a style file for a proceedings volume, Larry Siebenmann
+and I had collected various plain.tex bugs and written them at various
+times to the net, assuming they would find their way to Knuth and be
+corrected eventually. Checking the most recent plain.tex I see some
+have (missing m@th in some macros) but others havn't. Larry suggested
+that you are a good clearing house for this sort of thing, so I am
+sending our residue to you. The bugs are in Plain's handling of
+inserts. One bug is actually a TeX bug, and I havn't checked if most
+recent TeX fixes it, since we don't have the most recent installed
+yet. That bug is that \lastskip gets lost by an \insert. For details
+[ dek: ^^^ not really a bug in \TeX
+]
+of this, and also the plain.tex problems, see the following file that
+I posted to the net about a year ago.
+
+In my opinion, items 2 (second part), 3, and 5 of the list of
+"problems" deserve the name "bugs" while 2 (first part), 1, and 4 are
+merely poor choices.
+
+It also seems to me that it is not logical that TeX uses \topskip
+instead of \baselineskip at top-of-page if there is a top insertion
+("remaining problem" quoted below). Bug or poor choice? -- take your
+pick.
+
+%% newinsert.tex 3/17/91, 4/2/91 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+% walter neumann (neumann@mps.ohio-state.edu)
+%
+% Include with "\input newinsert.tex" to fix following problems
+% with plain TeX's handling of \midinsert and \topinsert:
+%
+% 1. An insert that falls at the top of the page is too high: it's
+% top is at top-of-page rather than top-of-ink.
+% 2. Plain uses \bigskip for space around inserts and assumes \bigskip
+% is 12pt plus stretch, so \midinsert misbehaves if \bigskipamount
+% is changed. This space should be an independent quantity.
+% 3. Consecutive midinserts that did not float are spaced twice
+% as far apart as consecutive topinserts or floated midinserts.
+% 4. Midinserts can get out of order (see Exercise 15.5 of TeXbook).
+% 5. \removelastskip fails after a floated insert. This is relevant for
+% an insertion before any construction (such as a proclamation in
+% plain TeX) that does an explicit or implicit \removelastskip.
+%
+% Remaining problem: TeX uses \topskip instead of \baselineskip for the
+% first line of a page after any topinserts. With the default values
+% of 10pt and 12pt respectively, this gives 2pt less space between a
+% topinsert or floated midinsert and following text than between a
+% middle insertion and following text. To avoid this use:
+%
+% \topskip=\baselineskip
+% [ dek: the \skip<n> parameter for \insert<n> handles such
+% discrepancies; see pp 122-123 especially Step 1 on page 123
+% ]
+%
+% PARAMETERS:
+% Plain.tex puts \bigskipamount of space before and after inserts.
+% We provide \insertskipamount for this purpose (default \medskipamount).
+% In addition, \inserthardskipamount of glue is added at the top of EVERY
+% insert; it remains even at top of page (default 6pt; it should be at
+% least \topskipamount-(text height)).
+% These defaults give good balance for figure insertions of the form:
+% \midinsert
+% [Commands to include a graphics file]
+% \medskip \centerline{Figure Title}
+% \endinsert.
+%
+\chardef\newinsCatAt\the\catcode `\@
+\catcode `\@=11
+%
+%%%%%%%%%%%% Corrected insert macros for plain.tex %%%%%%%%%%%%%%%%%
+%
+% New skipamounts:
+%
+\newskip\insertskipamount\newskip\inserthardskipamount
+\insertskipamount\medskipamount % Change as desired.
+\inserthardskipamount 6pt % Change as desired (see above)
+\def\insertskip{\vskip\insertskipamount}
+%
+% Save and restore \lastskip:
+%
+\newskip\LastSkip
+\def\SaveLastSkip{\LastSkip\lastskip}
+\def\RestoreLastSkip{\nobreak\vskip-\LastSkip\vskip\LastSkip}
+%
+% Larry Siebenmann's test for split topinserts:
+%
+\newcount\SplitTest% will be set to -1 if a topinsert has split
+\def\SetSplitTest{\SplitTest\insertpenalties
+ \SaveLastSkip\insert\topins{\floatingpenalty1}\RestoreLastSkip
+ \advance\SplitTest-\insertpenalties}
+%
+% From here on we modify definitions in plain.tex.
+%
+% Redefine \midinsert to convert to \topinsert if a topinsert has been
+% split, to prevent midinserts getting out of order (cf. TeXbook Exercise
+% 15.5). As in plain.tex, a \midinsert still converts to a \topinsert
+% (which then splits) if the insert is too big for current page.
+% Was: \def\midinsert{\@midtrue\@ins}
+\def\midinsert{\par\SetSplitTest\ifnum\SplitTest=-1
+% [ dek: would <0 also work?
+% ]
+ \@midfalse\else\@midtrue\fi\@ins}
+% Redefine \@ins to add \inserthardskipamount of glue above.
+% Was: \def\@ins{\par\begingroup\setbox\z@\vbox\bgroup}
+\def\@ins{\par\begingroup\setbox\z@\vbox\bgroup%
+ \vglue\inserthardskipamount}
+% Changes to \endinsert of plain.tex 3.0:
+% - Use \insertskipamount instead of \bigskipamount throughout.
+% - Use larger of previous skip and insertskip before middle insert.
+% - Add \nointerlineskip to avoid unwanted extra 1pt skip.
+% - Save and restore lastskip when an insert floats.
+\def\endinsert{\egroup % finish the \vbox
+ \if@mid \dimen@\ht\z@ \advance\dimen@\dp\z@
+ \advance\dimen@\insertskipamount% was 12pt (wn)
+ \advance\dimen@\pagetotal\advance\dimen@-\pageshrink
+ \ifdim\dimen@>\pagegoal\@midfalse\p@gefalse\fi\fi
+% Next 3 lines replace: \if@mid \bigskip\box\z@\bigbreak (wn)
+ \if@mid%
+ \ifdim\lastskip<\insertskipamount\removelastskip\insertskip\fi
+ \nointerlineskip\box\z@\penalty-200\insertskip
+ \else%
+ \SaveLastSkip% added (wn)
+ \insert\topins{\penalty100 % floating insertion
+ \splittopskip\z@skip
+ \splitmaxdepth\maxdimen \floatingpenalty\z@
+ \ifp@ge \dimen@\dp\z@
+ \vbox to\vsize{\unvbox\z@\kern-\dimen@}% depth is zero
+ \else \box\z@\nobreak\insertskip\fi}% was \bigskip\fi (wn)
+ \RestoreLastSkip% added (wn)
+ \fi\endgroup}
+%%%%%%%%%%%%%%%%%% Done correcting insert macros %%%%%%%%%%%%%%%%%%%
+%
+\catcode `\@=\newinsCatAt
+\endinput
+%% end newinsert.tex
+
+ --
+ Walter Neumann Email: neumann@mps.ohio-state.edu
+ Department of Mathematics neumann@ohstpy.bitnet
+ Ohio State University Tel: 614-292-4886 (office)
+ Columbus, OH 43210 -292-4975(Math. Dept.) -292-1479 (Dept. Fax)
+-------
+[ 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.
+]
+
+************************************************************************
+
+Date: 24 Feb 1993 17:35:03 -0500 (EST)
+From: bbeeton <BNB@MATH.AMS.ORG>
+Subject: message for don -- trip, volume b glitch
+
+[ don --
+ i don't know why i failed to send this one out with the rest; it's
+ not as if it would have taken a long time to edit out extraneous
+ stuff.
+]
+
+>>> Volume B; trip
+
+Date: Fri, 10 Apr 92 13:21:27 GMT
+From: Peter Breitenlohner <PEB%DM0MPI11.BITNET@vm.gmd.de>
+Subject: message to DEK
+
+barbara, can you please forward the following to Knuth. Thanks
+
+1. deficiency in TRIP test.
+ while doing some optimization for PubliC TeX I had introduced
+ a bug in the splittopskip computation in prune_page_top
+ In mod.969 the line
+ ....... width(temp_ptr):=width(temp_ptr)-height....
+ was changed by mistake to something equivalent to
+ ....... width(temp_ptr):=width(temp_ptr)+height....
+[ dek: It would be interesting to check the archives to see why
+ we failed to cover this -- but I haven't time to do so
+ (nor to update trip).
+]
+ When this bug was finally found by Ulrik Vieth we both
+ were much surprised that this error was never detected by
+ the TRIP test!
+
+2. missing mini-index entry
+ On page 483 of Vol.B there ought to be an entry for off_save.
+ In my old book (TeX Version 2.0) there is none. Unfortunately
+ I had no possibility to check one of the newer editions.
+[ dek: the newer books have improved indexing software, so this
+ should no longer be an issue. In 1994, get a new Vol B!
+ It will be the permanent, good one.
+]
+
+Sincerely Peter Breitenlohner
+
+************************************************************************
+
+>>> Report on TeX 3.14b
+
+Date: Wed, 5 FEB 92 21:57:11 GMT
+Reply-to: Brian {Hamilton Kelly} <TeX@rmcs.cranfield.ac.uk>
+From: TEX@rmcs.cranfield.ac.uk
+To: BNB <@nsfnet-relay.ac.uk:BNB@MATH.AMS.com>
+Subject: RE: TeX 3.14b, etc
+
+barbara,
+
+In message <A5343AE79E00E880@UK.AC.CAMBRIDGE.PHOENIX> of Wed, 05 Feb 92
+17:32:30 GMT, Chris Thompson <CET1@UK.AC.CAMBRIDGE.PHOENIX> wrote:
+
+> Some rather hasty and incomplete testing done. I have compiled
+> TeX 3.14b and confirmed that it fixes the doubled kern problem
+> in 3.14a, and also Robert Hunt's \showbox bug. Test documents
+> generate unaltered DVI files.
+
+I can also confirm that it DOES fix my original problem with terminal-
+\sigma ligatures with punctuation. I've also run TRIP and match DEK's
+output (apart from the fact that he's obviously gone the whole hog and
+called his executable 3.141, because that's how his logs read, rather
+than 3.14b.
+
+> MF 2.7a compiled and run through a few tests. Proof mode cmr10
+> shows a diff on character "Q" only: this is presumably the result
+> of the "fixed bug in draw" (as there is no new mf84.bug in /alpha,
+> I don't know what this bug might be). Actually the pixel deltas
+> seem to change the "Q" bitmap back to what it was in some earlier
+> version of MF (or maybe this is an accident due to some nearly half
+> integral coordinate that flips one way of the other on lots of
+> changes).
+
+I haven't looked at MF at all yet, mainly because I didn't know what it
+was supposed to be fixing!
+
+> Weave 4.4 compiled and tested to the extent of that it generates
+> identical output to 4.2 for a few WEB files.
+
+And I can also confirm that it correctly handles wrapped TeX comments;
+great!
+
+> I note the existence of a number of changed .mf files for cm fonts
+> in /alpha, but as there is no cm85.bug either, I wouldn't know what
+> to look for.
+
+Ditto.
+
+Best regards,
+
+Brian
+-------
+Date: Thu, 06 Feb 92 13:59:36 GMT
+From: Chris Thompson <CET1@phoenix.cambridge.ac.uk>
+To: Brian {Hamilton Kelly} <TeX@rmcs.cranfield.ac.uk>,
+ Barbara Beeton <BNB@MATH.AMS.COM>
+Subject: RE: TeX 3.14b, etc
+
+I have also run the new trip and trap tests (snap!) and they pass
+(as Brian points out, in the tr(i|a)p test output the banners appear
+as "3.141" and "2.71" rather than "3.14b" and "2.7a"). MF 2.7a passes
+the 2.7 trap test; TeX 3.14b doesn't quite pass the 3.14 trip test, but
+that is no suprise.
+
+Chris Thompson
+Cambridge University Computing Service
+JANET: cet1@uk.ac.cam.phx
+Internet: cet1@phx.cam.ac.uk
+
+************************************************************************
+
+>>> tangle.web 4.2
+
+Date: Mon, 24 Feb 92 10:42:31 GMT
+From: Peter Breitenlohner <PEB%DM0MPI11.bitnet@CUNYVM.CUNY.EDU>
+To: Barbara Beeton <bnb@MATH.AMS.COM>
+Subject: tangle.web 4.2
+
+barbara,
+I retrieved tangle.web 4.2 from labrea.
+To my surprise I found that the 'extra "}" bug' I reported some
+time ago ist still there, although it was fixed in weave.
+Maybe you can clarify this.
+peter
+%--------------------------------------
+Line numbers refer to TANGLE.WEB 4.2 as of March 26, 1991.
+
+@x [13] m.145 l.2664 get_next - bug fix
+othercases if c>=128 then goto restart {ignore nonstandard characters}
+@y
+"}": begin err_print('! Extra }'); goto restart;
+@.Extra \}@>
+ end;
+othercases if c>=128 then goto restart {ignore nonstandard characters}
+@z
+%---------------------------------------
+-------
+Date: Mon, 24 Feb 92 15:45:56 GMT
+From: Peter Breitenlohner <PEB%DM0MPI11.bitnet@CUNYVM.CUNY.EDU>
+To: Barbara Beeton <bnb@MATH.AMS.COM>
+Subject: tangle.web 4.2
+
+barbara,
+I forgot to mention another longstanding bug? in tangle:
+
+% TANGLE.WEB 4.2 as of March 26, 1991.
+
+@x [4] m.31 l.642 - activate debug_help
+@!debug debug_help;@+gubed
+@y
+@!debug debug_skipped:=debug_cycle;debug_help;@+gubed
+@z
+%---------------------------------------
+[ dek: I don't know why version 4.2 was still on labrea; version 4.3
+ was released September 1991 and fixed the bug in question ...
+ Version 4.4 will fix this other (debug cycle) one.
+]
+
+cheers peter
+-------
+Date: Mon, 24 Feb 1992 10:10:36 -0500 (EST)
+From: Barbara Beeton <BNB@MATH.AMS.COM>
+To: PEB%DM0MPI11.bitnet@CUNYVM.CUNY.EDU
+Subject: Re: tangle.web 4.2
+
+peter,
+i've just checked at labrea.
+there's no new version of tangle in /alpha so it seems that either
+(1) knuth thought that there were no changes, or
+(2) he forgot to install it, or
+(3) the notes he accidentally sent from sweden by sea mail contained
+ some more things to look at and he decided to wait.
+i'll follow it up. thanks.
+i still haven't finished transcribing knuth's last set of comments,
+that i received before going to england for the uktexug and tug board
+meetings. i may find something there. maybe today ...
+ -- bb
+-------
+Date: Mon, 24 Feb 92 16:12:49 GMT
+From: Peter Breitenlohner <PEB%DM0MPI11.bitnet@CUNYVM.CUNY.EDU>
+To: Barbara Beeton <BNB@MATH.AMS.COM>
+Subject: Re: tangle.web 4.2
+
+OK thanks,
+the point is that the 'extra "}" bug' is just a minor nuisence
+in weave but can lead to a rather mysterious nonsense in tangle's output.
+pb
+
+************************************************************************
+
+>>> Reply from Don
+
+Date: 27 Feb 1993 23:48:06 -0800
+Subject: note from Don
+
+Many thanks, Barbara, for the notes you sent.
+
+As usual, Phyllis made hardcopy for me, and I scribbled comments on
+that, and wrote appropriate checks when monetary rewards were due.
+The result will be wending its way to you via snail mail.
+
+TeX version 3.1415 is done and should be available soon by anonymous ftp
+from the semi-secret "alpha" [not pub] directory at labrea. A system
+guru will probably install it sometime this weekend; I don't have
+permission to do that. Look for file ~ftp/alpha/tex3.1415.tar.Z
+at labrea.stanford.edu. Uncompressing and untarring will yield
+only the crucial files that have changed: tex.web, tripin.log,
+trip.log, trip.typ; also new versions of errata.tex and tex82.bug.
+I think it's wise to wait awhile before releasing it officially ---
+I will be updating METAFONT, some day, if that Sun file name stuff ever
+is acted on --- although people are welcome to try it out. Just
+a few changes: one which makes it more efficient to have everything
+in a nonzero \language, another which affects kerns inserted at
+the boundary characters using the smart-ligature mechanism.
+(Previously such kerns were not treated consistently or correctly, so
+people must not have been using them. Now they act like kerns on
+accents, i.e., they do not disappear into line breaks.)
+
+I plan to look at TeX again about 15 months from now. Thanks again for
+your most helpful accumulation of pretty-much-noise-free comments.
+
+************************************************************************
+
+>>> Metafont/MFBook
+
+Date: 21 Dec 1992 01:03:42 +0000 (GMT)
+From: Chris Thompson <CET1@phx.cam.ac.uk>
+To: Barbara Beeton <BNB@MATH.AMS.ORG>
+Cc: Robert Hunt <REH10@phx.cam.ac.uk>
+Subject: plain.mf bug from REH, etc.
+
+Dear Barbara,
+
+I should have known that Robert Hunt had been quiet for too long...
+He has sent me the follo
+wing:
+
+> I have found a bug in Plain METAFONT; line 371 of the format file (in the
+> definition of cutoff) should read
+> (cut_ scaled (1+max(-pen_lft,pen_rt,pen_top,-pen_bot))
+> instead of
+> (cut_ scaled (1+max(pen_lft,pen_rt,pen_top,pen_bot))
+>
+> The METAFONTbook would also need correcting on pages 151 and 272.
+
+[ dek -- $ 2.56
+]
+
+I think he is right that the current code is wrong, but his fix is
+insufficiently drastic. The absolute values of all four pen_?
+quantities needs to be taken, as they can be of any sign (although
+the ones that Robert is assuming are no doubt the most likely).
+One for Don's list.
+
+Chris Thompson
+-------
+Date: 21 Dec 1992 21:25:37 +0000 (GMT)
+From: Chris Thompson <CET1@phx.cam.ac.uk>
+Subject: More on Robert's plain.mf bug
+
+Dear Barbara,
+
+... Robert Hunt has commented on my remarks:
+
+> Interestingly enough, my suggested alteration
+> (cut_ scaled (1+max(-pen_lft,pen_rt,pen_top,-pen_bot))
+> _is_ sufficient, and there is no need for
+> (cut_ scaled (1+max(abs pen_lft,abs pen_rt,abs pen_top,abs pen_bot)).
+> This is because (as far as I am aware) the two inequalities pen_lft \le pen_rt
+> and pen_bot \le pen_top hold. You'll soon see why my solution is good enough
+> if you try coming up with an example where it fails!
+
+and he is quite right---his fix is sufficient.
+
+Chris Thompson
+
+[ dek --
+ there is another bug in cutdraw too, re the spurts of ink discussed
+ on page 112.
+ Both of these bugs are corrected in base_version 2.71
+]
+
+<<< end items send 23 Dec 1982
+
+************************************************************************
+
+>>> items sent 8 Mar 1993
+
+Date: Mon, 13 Apr 92 12:26:16 GMT
+From: Peter Breitenlohner <PEB%DM0MPI11.BITNET@vm.gmd.de>
+To: Barbara Beeton <bnb@MATH.AMS.COM>
+Subject: message for Knuth and a question
+
+barbara,
+Right know I am working on a modified TeX-XeT change file,
+inspired by that by Knuth and MacKay published in TUGboat
+but different in two essential points:
+1. the text direction primitives are treated differently
+ in order not to disturbe TeX's linebreaking algorithms for
+ pure left-to-right text (that is to say the new TeX-XeT
+ passes the TRIP test in a much better way than the old one)
+2. right-to-left text is reversed explicitely and writen to
+ a normal DVI (not DVI-IVD) file.
+All that is still in progress, but will be finished soon.
+Can you propose a good way to make the result widely available
+and known?
+
+In doing all that I stumbled on some dubious code in tex.web.
+Can you please forward the following (or the whole message)
+to Knuth.
+
+Thanks Peter
+%--------------------------------------------------------
+
+Misleading code (or a real bug?) in tex.web V 3.141
+
+In the hlist/vlist_out routines leader boxes are shifted
+by their shift_amount. As far as I can see this shift_amount
+is always zero and that code should be removed.
+[dek -- ^^^^ yes, since 28 Mar 1983!
+]
+
+Even worse if there were a possibility to have leader boxes with
+non-vanishing shift_amount. Then there would be a real bug since
+the value of cur_v/cur_h is not reset to base_line/left_edge after
+the leader boxes have been shipped out.
+
+Here is what I think ought to be changed:
+
+% All line numbers refer to TEX.WEB 3.141 as of March 16, 1992.
+
+@x [32] m.628 l.12462 - remove redundant (and misleading) code
+begin cur_v:=base_line+shift_amount(leader_box); synch_v; save_v:=dvi_v;@/
+@y
+begin synch_v; save_v:=dvi_v;@/
+@z
+[ dek -- $2.56
+]
+%---------------------------------------
+@x [32] m.637 l.12605 - remove redundant (and misleading) code
+begin cur_h:=left_edge+shift_amount(leader_box); synch_h; save_h:=dvi_h;@/
+@y
+begin synch_h; save_h:=dvi_h;@/
+@z
+%---------------------------------------
+[ dek --
+ In TeX change 668 (`Errors of TeX'] I decided that these shift
+ amounts be zero, but I left the redundant code in case of future
+ extensions.* Now I see your point about the potential "real bug"
+ if somebody were to actually _use_ the feature. So I prefer to
+ _leave_ these lines of code but to set
+ cur_v:= base_line
+ cur_h:=left_edge
+ at close of \S628 and \S637
+
+ * not in TeX itself but in private versions, as in \S1340
+]
+
+Peter Breitenlohner
+
+************************************************************************
+
+>>> items sent 11 Jun 1993
+
+Date: 30 Apr 1993 22:32:17 -0300 (BST)
+From: Chris Thompson <CET1@phx.cam.ac.uk>
+Subject: Re: [alpha version, tex 3.1415]
+
+Dear Barbara,
+
+Here is a probably forlorn attempt to get a report in before your
+30 April deadline:
+
+ . No bugs found. It passed the usual paranoia tests. I have been
+ using it myself (not very intensively) for routine (La)TeXing.
+ I have had no adverse reports back from the 2-3 users I tried
+ to subcontract the testing to (George Russell, Robert Hunt).
+
+ . I have done a series of tests in respect of change #405 (Rainer's
+ \setlanguage and associated problems): I felt I really ought to as
+ Don has adopted the scheme I thought up in a particularly inspired
+ moment last July (keeping the initial language/hyphenmin info for
+ a paragraph in the pg_field)! It really does seem to work...
+
+ . But a minor quibble: \showlists output now leaves no space between
+ "language" and "hyphenmin" and the subsequent numbers when displaying
+ this data. It used to show only the latter, but left a single space,
+ which looked better.
+
+[ dek --
+ hmm, there's no accounting for taste
+]
+
+ . I *haven't* tested changes #404/#407, to do with boundary character
+ logic, in any serious way. (I am rather hoping Brian has been doing
+ some tests with his Greek fonts...)
+
+If you want to contact me while while you are in this country, my work
+telephone number is 0223 (Cambridge) - 334715.
+
+Chris Thompson
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+Date: 02 Apr 1993 14:39:21 +0200
+From: Bernd Raichle <Raichle@informatik.uni-stuttgart.de>
+Subject: Small Bug in TeXbook: \downbracefill+\upbracefill
+
+TeXbook, Appendix B. Basic Control Sequences (page 357) states that
+
+ The |\upbracefill| and |\downbracefill| macros have restricted
+ usage: they must appear {\sl all by themselves\/} in an hbox or an
+ alignment entry, except for horizontal spacing.
+
+otherwise the \vrule "makes a heavy black band, which is too horrible
+to demonstrate here" (TeXbook, page 331, answer of exercise 21.6, page
+225).
+
+In the following example \downbracefill and \upbracefill "appear all
+by themselves in [..] an aligment entry":
+
+\halign{#&&\hfil#\hfil\cr
+ &\kern 5cm &\kern 5cm\cr
+ &\upbracefill &\downbracefill\cr
+\strut &\upbracefill &\downbracefill\crcr}
+
+The two \..bracefill in the third line of the \halign with the \strut
+in column one produce the mentioned "heavy black band".
+
+
+To correct the TeXbook, either
+
+1) replace "alignment entry" to "complete alignment line" or something
+ similar
+
+ or
+
+2) change the definition of \downbracefill and \upbracefill,
+ specifying the height and the depth of the \vrule, e.g.
+
+ \def\upbracefill{$\setbox\z@\hbox{$\bracelu$}\m@th
+ \bracelu\leaders\vrule height\ht\z@ depth\dp\z@ \hfill\bracerd
+ \braceld\leaders\vrule height\ht\z@ depth\dp\z@ \hfill\braceru$}
+[ dek -- [delete \dp, on two lines] ^^^
+ page E89: depth _is_ _zero_ ^^^ $2.56
+]
+
+ and correct the statement about the restricted usage.
+
+
+I prefer change 2, because it allows the use of \..bracefill in normal
+text without a \hbox.
+
+[ dek --
+ agreed -- see plain fmtversion 3.1415
+]
+
+Yours,
+ -bernd
+__________________________________________________________________________
+Bernd Raichle, ISR, Universit"at Stuttgart | "Le langage est source
+home: Stettener Str. 73, D-W-7300 Esslingen, FRG | de malentendus"
+email: raichle@informatik.uni-stuttgart.de | (A. de Saint-Exupery)
+ -------
+Date: 05 Apr 1993 09:17:17 +0200
+From: Bernd Raichle <Raichle@informatik.uni-stuttgart.de>
+Subject: Re: Small Bug in TeXbook: \downbracefill+\upbracefill
+
+on 04 Apr 1993 13:42:57 -0400 (EDT), bbeeton <BNB@MATH.AMS.ORG> said:
+you> however, he has already completed his annual examination and
+you> updated of tex and the texbook, and plans to look next at tex
+you> "about 15 months from now" (as of feb 27). (i will forward his
+you> comments on the bug reports and updates as soon as the "alpha"
+you> version of tex 3.1415 has been vetted and pronounced sound by
+you> the testers.) so you should certainly do what is necessary
+you> in the meantime to avoid this problem, if you encounter it
+you> again.
+
+This is ok for me.
+
+Btw, I'll checked the alpha 3.1415 version of TeX on labrea and IMHO
+there are two missing changes w.r.t. the change of \lefthyphenmin and
+\righthyphenmin:
+The fields |lhm_field| and |rhm_field| in |list_state_record| are
+[ dek --
+ ? they're gone ...
+ change 405 in tex82.bug says to undo change 373 ...
+ errata.tex correction to page B89 dated 27 Feb 93 removes them ...
+ so I guess labrea is not up to date
+]
+unnecessary, because 3.1415 uses the |pg_field| for this purpose. The
+same applies for the definitions of the WEB macros |lhmin| and |rhmin|
+in the next section. (tex.web 3.1415 alpha, \S 212 & 213)
+
+
+you> do you think this is a problem that might be encountered by
+you> others? it does remind me of a warning published in tugboat
+you> a while ago (9 #2, p.183) about the depth of a rule that was
+you> incompletely specified, and took on the depth of an element
+you> in another cell of an \halign. in that piece, one recommended
+you> solution was to use \leaders -- but since the \*bracefill
+you> macros already use \leaders, it looks like that isn't a valid
+you> solution.
+
+The TeXbook contains this warning and an explanation of this
+behaviour. (The behaviour of the \..bracefill macros with their
+current definition are correct.) But the restriction statement in
+appendix B, page 357 is not complete (as I have shown with the example
+in my bug report). Additionally the answer of exercise 21.6 (page 331)
+says:
+
+ [..] This usually makes a heavy black band, which is too horrible to
+ demonstrate here. However, it does work in the ^|\downbracefill|
+ ^^^^^^^^^^^^
+[ dek -- $2.56
+]
+ macro of Appendix~B [..]
+
+
+The problem with this (mis)behaviour of \..bracefill: LaTeX's
+tabular/array environments puts automatically a \strut in column one
+of each alignment line making sure that the baseline distances are
+equal. Thus \..bracefill, which may be useful in a LaTeX `array', can
+not be used without modifications.
+
+
+you> i'll have to look over that again, and perhaps a
+you> new warning should be published. if so, i'll give you credit
+you> for the report; would you be willing to review such a piece
+you> before publication?
+
+Yes.
+
+Sincerely,
+ -bernd
+
+
+########################################################################
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+% Character code reference
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%
+% Upper case letters: ABCDEFGHIJKLMNOPQRSTUVWXYZ
+% Lower case letters: abcdefghijklmnopqrstuvwxyz
+% Digits: 0123456789
+% Square, curly, angle braces, parentheses: [] {} <> ()
+% Backslash, slash, vertical bar: \ / |
+% Punctuation: . ? ! , : ;
+% Underscore, hyphen, equals sign: _ - =
+% Quotes--right left double: ' ` "
+%"at", "number" "dollar", "percent", "and": @ # $ % &
+% "hat", "star", "plus", "tilde": ^ * + ~
+%
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+[ end of message 042 ]