diff options
Diffstat (limited to 'info/digests/tex-implementors/042')
-rw-r--r-- | info/digests/tex-implementors/042 | 1971 |
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 ] |