summaryrefslogtreecommitdiff
path: root/info/digests/tex-implementors/034
diff options
context:
space:
mode:
Diffstat (limited to 'info/digests/tex-implementors/034')
-rw-r--r--info/digests/tex-implementors/034508
1 files changed, 508 insertions, 0 deletions
diff --git a/info/digests/tex-implementors/034 b/info/digests/tex-implementors/034
new file mode 100644
index 0000000000..72f510eb97
--- /dev/null
+++ b/info/digests/tex-implementors/034
@@ -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 ]
+-------
+