diff options
author | Norbert Preining <norbert@preining.info> | 2021-05-27 03:01:40 +0000 |
---|---|---|
committer | Norbert Preining <norbert@preining.info> | 2021-05-27 03:01:40 +0000 |
commit | 5f1cfa686748068fedb95d8dafda3dc7f999c948 (patch) | |
tree | 874fa8430be12fe4633924f3b707428170316a46 /info/digests/tex-implementors/message.34 | |
parent | 8982c52e00ffb3fb5a913fc60913ebd9070f091a (diff) |
CTAN sync 202105270301
Diffstat (limited to 'info/digests/tex-implementors/message.34')
-rw-r--r-- | info/digests/tex-implementors/message.34 | 508 |
1 files changed, 508 insertions, 0 deletions
diff --git a/info/digests/tex-implementors/message.34 b/info/digests/tex-implementors/message.34 new file mode 100644 index 0000000000..72f510eb97 --- /dev/null +++ b/info/digests/tex-implementors/message.34 @@ -0,0 +1,508 @@ +Date: 5 November 91 Message No: 034 + +To: TeX implementors and distributors + +From: Barbara Beeton + +Subject: Messages from DEK, part 3 + + +The third installment of DEK's September comments. + + +######################################################################## + +TeX -- size of \smash'ed boxes + +Date: 24 Jun 91 18:56:42 +From: jeffrey%se.chalmers.cs@se.sunet.sunic +Authorised-User: Alan Jeffrey <jeffrey@se.chalmers.cs> +To: cet1@uk.ac.cam.phx +Subject: Odd TeX behaviour + +Dear Chris, + +Here's something I asked texhax a few days ago---barbara wrote back, +and suggested I ask you about it. Since you were so helpful in +finding that MF bug last year I thought you'd be a good person to ask. + +The problem is what happens if you put a smashed box in a script for a +displaystyle mathop, for example: + + $$ \sum^{\smash{\vrule height 1in depth 1in}} $$ + +produces the same as if the \smash weren't there. In general, if you +take a box, change its size, and put it in a displaystyle mathop +script, the size-changing info is lost. So: + + \setbox0\hbox{...} + \ht0=... + \dp0=... + $$ \sum^{\box0} $$ + +is the same as + + \setbox0\hbox{...} + $$ \sum^{\box0} $$ + +This isn't a bug, since in Appendix G, para. 13a, DEK says + + Set box $x$ to the superscript field... + set box $y$ to the nucleus field... + set box $z$ to the subscript field... + Rebox all three of these boxes to width $\max(w(x),w(y),w(z))$. + +As far as I can tell, in doing this reboxing, the outermost level of +box information is thrown away, and in particular the \ht and \dp +information goes with it. + +So it's not a bug, but it's certainly not what you'd expect! + +Alan. + +Alan Jeffrey Tel: +46 31 72 10 98 jeffrey@cs.chalmers.se +Department of Computer Sciences, Chalmers University, Gothenburg, Sweden + ------- +Date: Thu, 27 Jun 91 16:14:31 BST +From: Chris Thompson <CET1@phoenix.cambridge.ac.uk> +To: Alan Jeffrey <jeffrey@cs.chalmers.se> +Subject: Re: [Odd TeX behaviour] + +Dear Alan, + + Thank you for your description of the odd effects with \smash in +the limits of a \mathop. I *think* that Don Knuth has covered himself +against the possibility of these effects being bugs, but the situation +is in fact even odder than your examples illustrate. + + As you point out, in + + $$ \sum^{\smash{\vrule height 1in depth 1in}} $$ + +the superscript gets unsmashed by the reboxing described in step 13a +of Appendix A: in terms of code, the call of |rebox| (section 715) +from |make_op| (section 750). One can prevent the recalculation of +the height and depth by + + $$ \sum^{\hbox{$\smash{\vrule height 1in depth 1in}$}} $$ + +or the like. + + However, in + + $$ \sum^{\smash{\vrule width 20pt height 1in depth 1in}} $$ + +the smashing remains in effect! This is because |rebox| does not +unpack and repack the box contents if the width is already what +is required. I suppose that this is implied by the description of +the `subroutine that ``reboxes'' a given box to a given width' on +page 442 of the TeXbook, but it certain isn't explicitly stated. + + |rebox| also doesn't rebox if the box contents are the empty list; +it simply changes the width to that required. This means that any +explictly set \ht and \dp will survive in this case. (This would +happen in the case of a \(h|v)phantom, I think.) I can't find any +mention at all of this in Appendix G. + + Altogether, The situation seems extremely messy, even if it is +according to spec. I think (Barbara?) that it should be brought to +Don's attention, at least. A cleaner spec would be that |rebox| +always preserves the height and depth, but I suppose that might be +an incompatible change. + +Chris Thompson + ------- +Date: Fri, 28 Jun 91 09:44:11 +0200 +From: Alan Jeffrey <jeffrey@cs.chalmers.se> +Subject: Note about reboxing. + +{\obeylines +{\bf Reboxing math operator scripts in display style} +Alan Jeffrey and Chris Thompson +27 June 1991} + +\hsize 31pc + +{\obeyspaces\global\let =\ } +\catcode`\[=\active \catcode`\]=\active +\def[{\bgroup\par\medskip\tt\obeylines\catcode`\$11\catcode`\\11 + \catcode`\{11\catcode`\}11\catcode`\^11\obeylines\obeyspaces} +\def]{\egroup\par\medskip\noindent\ignorespaces} + +\def\com#1{{\tt\string#1}} + +\medskip\noindent +It turns out that \TeX's algorithm for setting subscripts and +superscripts of limited operators has a rather odd feature. If you +say: +[ +$$ \sum^{\vrule height 2ex depth 2ex} + \sum^{\smash{\vrule height 2ex depth 2ex}} + \sum^{\hbox{\smash{\vrule height 2ex depth 2ex}}} $$ +] +then you get: +$$ \sum^{\vrule height 2ex depth 2ex} + \sum^{\smash{\vrule height 2ex depth 2ex}} + \sum^{\hbox{\smash{\vrule height 2ex depth 2ex}}} $$ +That is, the \com\smash\ has no effect unless it is contained inside +another \com\hbox. In Appendix~G, para 13a of {\it The \TeX book}, the +specification for reboxing a limited script is given as: + +{\medskip\narrower\noindent + Set box $x$ to the superscript field in style $C{\uparrow}$; set box + $y$ to the nucleus field in style $C$; and set box $z$ to the + subscript field in style $C{\downarrow}$. Rebox all three of these + boxes to width $\max(w(x), w(y), w(z))$.\par} + +\medskip\noindent +It appears that this reboxing (performed by {\bf rebox} \S715) loses +the outermost level of box information. This is confirmed by: +[ +$$ \sum^{\vrule width 20pt height 2ex depth 2ex} + \sum^{\smash{\vrule width 20pt height 2ex depth 2ex}} + \sum^{\hbox{\smash{\vrule width 20pt height 2ex depth 2ex}}} $$ +] +which produces: +$$ \sum^{\vrule width 20pt height 2ex depth 2ex} + \sum^{\smash{\vrule width 20pt height 2ex depth 2ex}} + \sum^{\hbox{\smash{\vrule width 20pt height 2ex depth 2ex}}} $$ +So when the script does not require reboxing, its height and depth are +not lost. + +The situation seems rather messy, albeit according to spec. A cleaner +8specification would be that {\bf rebox} should preserve height and +depth, but this may be an incompatible change. + + [ dek: _Correct_ _analysis_ ] + +\medskip + +\line{\hfil\it Alan Jeffrey} +\line{\hfil\it Chris Thompson} + +\bye + ------- + +[ Here's another view of the same problem. ] + +Date: Tue, 6 Aug 91 18:55:35 EDT +From: barr@triples.math.mcgill.ca +To: info-tex@SHSU.edu +Subject: problem with Tex + +Can anyone explain the discontinuity in the following, or how to make +the dots go into an intermediate position? + +Michael Barr + +\def\rdiv{\mathrel{\mathop + {\hbox{\vrule height.55ex width0pt depth-.54ex + \smash{\hbox{\mathsurround=0pt$-$}}}}% + \limits^{\hbox to .75em{\hss$\textstyle.$}}% + _{\hbox to .75em{\smash{\raise1.20ex\hbox{$\textstyle.$}}\hss}}}} + +\def\ldiv{\mathrel{\mathop + {\hbox{\vrule height.55ex width0pt depth-.54ex + \smash{\hbox{\mathsurround=0pt$-$}}}}% + \limits^{\hbox to .75em{$\textstyle.\hss$}}% + _{\hbox to .75em{\hss\smash{\raise1.20ex\hbox{$\textstyle.$}}}}}} + +$A\ldiv B\rdiv C$ + + +\def\rdiv{\mathrel{\mathop + {\hbox{\vrule height.55ex width0pt depth-.54ex + \smash{\hbox{\mathsurround=0pt$-$}}}}% + \limits^{\hbox to .76em{\hss$\textstyle.$}}% + _{\hbox to .76em{\smash{\raise1.20ex\hbox{$\textstyle.$}}\hss}}}} + +\def\ldiv{\mathrel{\mathop + {\hbox{\vrule height.55ex width0pt depth-.54ex + \smash{\hbox{\mathsurround=0pt$-$}}}}% + \limits^{\hbox to .76em{$\textstyle.\hss$}}% + _{\hbox to .76em{\hss\smash{\raise1.20ex\hbox{$\textstyle.$}}}}}} + +$A\ldiv B\rdiv C$ + + +\def\rdiv{\mathrel{\mathop + {\hbox{\vrule height.55ex width0pt depth-.54ex + \smash{\hbox{\mathsurround=0pt$-$}}}}% + \limits^{\hbox to .77em{\hss$\textstyle.$}}% + _{\hbox to .77em{\smash{\raise1.20ex\hbox{$\textstyle.$}}\hss}}}} + +\def\ldiv{\mathrel{\mathop + {\hbox{\vrule height.55ex width0pt depth-.54ex + \smash{\hbox{\mathsurround=0pt$-$}}}}% + \limits^{\hbox to .77em{$\textstyle.\hss$}}% + _{\hbox to .77em{\hss\smash{\raise1.20ex\hbox{$\textstyle.$}}}}}} + +$A\ldiv B\rdiv C$ + + +\def\rdiv{\mathrel{\mathop + {\hbox{\vrule height.55ex width0pt depth-.54ex + \smash{\hbox{\mathsurround=0pt$-$}}}}% + \limits^{\hbox to .78em{\hss$\textstyle.$}}% + _{\hbox to .78em{\smash{\raise1.20ex\hbox{$\textstyle.$}}\hss}}}} + +\def\ldiv{\mathrel{\mathop + {\hbox{\vrule height.55ex width0pt depth-.54ex + \smash{\hbox{\mathsurround=0pt$-$}}}}% + \limits^{\hbox to .78em{$\textstyle.\hss$}}% + _{\hbox to .78em{\hss\smash{\raise1.20ex\hbox{$\textstyle.$}}}}}} + +$A\ldiv B\rdiv C$ + + +\def\rdiv{\mathrel{\mathop + {\hbox{\vrule height.55ex width0pt depth-.54ex + \smash{\hbox{\mathsurround=0pt$-$}}}}% + \limits^{\hbox to .79em{\hss$\textstyle.$}}% + _{\hbox to .79em{\smash{\raise1.20ex\hbox{$\textstyle.$}}\hss}}}} + +\def\ldiv{\mathrel{\mathop + {\hbox{\vrule height.55ex width0pt depth-.54ex + \smash{\hbox{\mathsurround=0pt$-$}}}}% + \limits^{\hbox to .79em{$\textstyle.\hss$}}% + _{\hbox to .79em{\hss\smash{\raise1.20ex\hbox{$\textstyle.$}}}}}} + +$A\ldiv B\rdiv C$ + + +\def\rdiv{\mathrel{\mathop + {\hbox{\vrule height.55ex width0pt depth-.54ex + \smash{\hbox{\mathsurround=0pt$-$}}}}% + \limits^{\hbox to .80em{\hss$\textstyle.$}}% + _{\hbox to .80em{\smash{\raise1.20ex\hbox{$\textstyle.$}}\hss}}}} + +\def\ldiv{\mathrel{\mathop + {\hbox{\vrule height.55ex width0pt depth-.54ex + \smash{\hbox{\mathsurround=0pt$-$}}}}% + \limits^{\hbox to .80em{$\textstyle.\hss$}}% + _{\hbox to .80em{\hss\smash{\raise1.20ex\hbox{$\textstyle.$}}}}}} + +$A\ldiv B\rdiv C$ + +\bye + ------- +Date: Tue, 6 Aug 91 21:54 PDT +From: Donald Arseneau <ASND%TRIUMFRG.BITNET@SHSU.edu> +To: info-tex@SHSU.edu +Subject: Re: problem with positioning of mathop limits + +Michael Barr (barr%triples.math.mcgill.ca) had a problem with jumps +in the placement of the limits on an operator. + +> Can anyone explain the discontinuity in the following, or how to make +> the dots go into an intermediate position? +> +> \def\rdiv{\mathrel{\mathop +> {\hbox{\vrule height.55ex width0pt depth-.54ex +> \smash{\hbox{\mathsurround=0pt$-$}}}}% +> \limits^{\kern0pt\hbox to .77em{\hss$\textstyle.$}}% +> _{\kern0pt\hbox to .77em{\smash{\raise1.20ex\hbox{$\textstyle.$}}\hss}}}} +> + +I've seen that problem before (with someone else's problem) and I stick +by my explanation: an error in TeX. What I think is happening is a +misapplication of the unboxing explained on the first page of Appendix G: +"In case (c), the glue is set with no stretching or shrinking, and additional +level of hboxing is omitted if it turns out to be redundant." But when that +hbox has had its size (\ht, \wd, \dp) changed, or it is not set to its natural +width (to, spread) it is *NOT* redundant but gets omitted anyway! + +The immediate solution to Michael Barr's problem is to put something +outside the measured box so it cannot be omitted. Change all + \hbox to +to + \kern0pt \hbox to +and it will work. + +The discontinuity with the size of the measured hbox was very interesting. +In all cases the boxes for the limits were set to the width of "-", 7.777pt. +But TeX obviously did some measurement before discarding the important +level of boxing. For \hbox to Xpt, X < 7.7777, the limits were unboxed +and surrounded by \hss...\hss, giving in effect "\hss \hss . \hss", which +placed the dot 1/3 of the way across the minus sign. When X > 7.7777, +TeX thought the nucleus "-" was norrower than the limits and did not pad +the limits with \hss, leaving them as "\hss .". After unboxing and reboxing, +the limits could stretch only on one side leaving the dot at one edge of +the minus sign. + +Donald Arseneau asnd@triumfcl (.bitnet) + asnd@reg.triumf.ca + ------- +Date: Wed, 7 Aug 91 11:11:56 EDT +From: barr@triples.math.mcgill.ca (Michael Barr) +To: bnb@math.ams.com +Subject: more problems with boxes + +If you don't subscribe to texinfo, you may have missed my query and +Donald Arsenault's reply. Briefly, I was having trouble with the +series: + +... \def\rdiv{...} [ series as in message to info-tex ] + +shose output changes discontinuously as the parameter changes from .77 +to .78 (not coincidentally, the width of $-$ is .77777...em). This is +clearly more troubles with 13a on page 444, but I still couldn't see why +I wasn't getting growth before that. (In fact, the parameter could have +been 0 with no effect on the output, which I wasn't quite aware of, +although I knew that down to .3em it made no difference.) It turns out +that what is likely happening is explained by line -4 on page 441, which +Donald says he had run into before. Apparently, TeX' rules for deciding +what ``turns out to be redundant'' are not the same as you and I might +decide on. He suggested that what was happening is that TeX was +unboxing the \hbox and then implementing 13a (which he wasn't aware of, +or at least didn't mention) by reboxing it with an \hss on either side +so that the effect of my code was as if it said \hss\hss.\hss on one +side and vice versa on the other, which resulted in the dots exactly 1/3 +of the way (or 2/3). At this point, I have come up with + +\def\rdiv{\mathrel{\mathop + {\hbox{\vrule height.55ex width0pt depth-.54ex + \smash{\hbox{\mathsurround=0pt$-$}}}}% + \limits^{\hskip0pt plus3fil\textstyle.}% + _{\smash{\raise1.20ex\hbox{$\textstyle.$}}\hskip0pt plus3fil}}} + +\def\ldiv{\mathrel{\mathop + {\hbox{\vrule height.55ex width0pt depth-.54ex + \smash{\hbox{\mathsurround=0pt$-$}}}}% + \limits^{\textstyle.\hskip0pt plus3fil}% + _{\hskip0pt plus3fil\smash{\raise1.20ex\hbox{$\textstyle.$}}}}} + +which is simpler and allows fine control over the spacing. + +If you have not yet asked DEK about the 13a problem, you might include +these observations. In any case, a little more explanation is clearly +wanting here. By the way, DA suggested (correctly) that a \kern0pt +would prevent the unboxing. + +Allow me to second strongly Nelson Beebe's plea in the last three +paragraphs of his editorial in the most recent tugboat. I have now +spent most of a day getting through the texarcana in building one simple +little sign. The number of permutations of \smash and \raise I had to +try to get the vertical placement right (and only by eye, with no +guarantee it will be right at another point size), the amount of time +wasted on getting the horizontal placement right, they both seemed +infinite. It simply shouldn't be so hard to do something so simple. +The fact that adding a kern of 0pt changes everything is +incomprehensible. The facts that \smash requires, while \raise forbids +a brace following it are incomprehensible. The entire chapter on dirty +tricks is an indictment of the program. Almost everything in that +chapter is entirely reasonable and should have straightforward ways of +doing them, not be the subject of dirty tricks. The lack of a simple +reliable loop is unforgivable. A while ago, someone posed a question on +texhax about leaving a 2"x2" box in the lower right corner of each page. +So far as I know, this question got no answer, perhaps has NO reasonable +answer in tex as currently constituted. Certainly, I could think of +none. Nor could I think of any way of having one page narrower than +another. This sort of thing is not good if we expect TeX to grow. + +Michael Barr + ------- +Date: Wed, 07 Aug 91 15:32:12 BST +From: Chris Thompson <CET1@phoenix.cambridge.ac.uk> +To: Barbara Beeton <BNB@MATH.AMS.com> +Cc: Donald Arseneau <ASND@TRIUMFRG.bitnet>, + Michael Barr <barr@triples.math.mcgill.ca> +Subject: Re: [[barr@triples.math.mcgill.ca: problem with Tex]] + +This one is similar to the height&depth-losing problem you sent me +before, but I think this one *is* unambiguously covered by Appendix G, +unexpected though the effects may be. + +The relevant section is 13a, where the reboxing of \mathop's with +limits is being described. (Code is in TeX module 750.) Reboxing is +decsribed in the middle of p.442 ("There's also a subroutine..."). +The nucleus is this case is 7.7778pt wide; in the first few cases +the super- and sub-scripts are narrower, have \hss glue added on each +side, and are reboxed (losing the old specification). In the last few +cases, the nucleus is narrower and is reboxed, the super- and sub- +scripts being left alone. Because there is already \hss glue in the +boxes, adding more of the same fundamentally alters their appearence. +(Page 442 does warn about this when it says "it centers ... unless +infinite glue is present in addition to the newly added \hss".) + +Donald Arseneau is, I suppose, right to quote (c) from p.441: +the problem is the (false?) optimizations that TeX performs in +math-to-hosizontal conversion when it removes the "outermost" level +of boxing on math node components. His suggested \kern0pt will indeed +prevent this, of course. + +Donald is wrong, however, in saying +> In all cases the boxes for the limits were set to the width of "-", 7.777pt. + +They are, in fact, so set only in the cases when the explicit widths +of the super- and sub-script boxes are smaller than this; in the last +three cases the boxes all end up as 7.8, 7.9 and 8.0pt wide (+/- +rounding errors from the conversions from "em" to "pt"). Easily verified +by using \showlists. + +Chris Thompson + ------- +(reply, 7 Aug 91, to all) +chris, +thanks for your analysis. +the effects here are so unexpected that i think the problem is +worth a good strong warning in tugboat. could you help me to +prepare such a warning, with a very simple example showing what +happens under the relevant circumstances, and what can be done +to avoid it? if i come up with the example, can you prepare the +prose, citing chapter and verse? + -- bb + ------- +Date: Thu, 08 Aug 1991 02:25:27 PDT +From: Donald Arseneau <asnd@erich.triumf.ca> +To: uk%\"CET1@PHOENIX.CAMBRIDGE.AC.UK\"@erich.triumf.ca +Subject: Re: [[barr@triples.math.mcgill.ca: problem with Tex]] + +Arrrggghh! +I could have sworn I saw those little boxes staying at 7.77777pt. + +I guess the description of reboxing on p442 is more complete, and it +doesn't require the box to be "redundant", just a hbox. + +This behaviour of TeX certainly violates the principle that round-off +errors shouldn't produce gross differences in the output. + +Donald + ------- + +[ As suggested above, I intend to follow up with Chris to get a + statement of the problem for publication as a warning in TUGboat. ] + + [ dek: ^^^^^^^^^^^^^^^ right. + If these things had been brought up years ago, TeX might have + changed [e.g. rebox preserving height/depth, \smash always + adding another level of boxing <-- but that might overflow + memory] + The unboxing etc. turns out to be extremely important for + posting of superscripts on accented variables ... + Anyway, no changes now, on grounds of compatibility etc. + ] + + +######################################################################## + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +% 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 034 ] +------- + |