Just noticed something...
In the messages from the tex.tex run, I got overfull box messages like the following: Overfull \hbox (12.40152pt too wide) in paragraph at lines 21018--21025 []\tenbf 836. \tenrm It is not nec-es-sary to cre-ate new ac-tive nodes hav-ing [] greater than $[] +| \hbox(6.94444+1.94444)x469.75499, glue set - 1.0, direction TLT .\whatsit ..\localinterlinepenalty=0 ..\localbrokenpenalty=0 ..\localleftbox=null ..\localrightbox=null .\tenbf 8 .\tenbf 3 .\tenbf 6 .\tenbf . .etc. That whatsit has to go. Absolutely. When the user is explicitly assigning values to \local* variables, placing a whatsit at the point of assignment is fine and expected. It is even conceivable to place a whatsit at the start of the current hlist _when_ we assign to \local* in the middle of the list. But we can't go peppering the lists with whatsits when we are not asked for it. It will break far too many existing packages. Unless we find a way to make whatsits transparent. But the combination glue whatsit glue could not preserve a whatsit when doing \skip0=\lastskip \unskip \skip1=\lastskip \unskip \vskip\skip1 \vskip\skip2 So there is -- David Kastrup, Kriemhildstr. 15, 44793 Bochum
David Kastrup wrote:
In the messages from the tex.tex run, I got overfull box messages like the following:
Overfull \hbox (12.40152pt too wide) in paragraph at lines 21018--21025 []\tenbf 836. \tenrm It is not nec-es-sary to cre-ate new ac-tive nodes hav-ing [] greater than $[] +|
\hbox(6.94444+1.94444)x469.75499, glue set - 1.0, direction TLT ..\whatsit ...\localinterlinepenalty=0 ...\localbrokenpenalty=0 ...\localleftbox=null ...\localrightbox=null ..\tenbf 8 ..\tenbf 3 ..\tenbf 6 ..\tenbf . ..etc.
That whatsit has to go. Absolutely. When the user is explicitly assigning values to \local* variables, placing a whatsit at the point of assignment is fine and expected. It is even conceivable to place a whatsit at the start of the current hlist _when_ we assign to \local* in the middle of the list. But we can't go peppering the lists with whatsits when we are not asked for it. It will break far too many existing packages. Unless we find a way to make whatsits transparent. But the combination
one of more whatsits does not really matter, since a macro package writer cannot foresee what users put in their docs and so whatsits can show up all over the place anyway on the todo list for luatex is an additional repertoire of \un* primitives to deal with unrolling boxes, but more powerful is that at some point we can use lua to manipulate such lists the current priority lies with fonts and being able to typeset high quality arab, and given idris (oriental tex) demands i bet that solutions for this whatsit stuff will show up eventually anyhow, package compatibility is not high on our agenda; if a package does not work any more, bad luck ... adapt the package ... or use pdftex 1+; users have to live with the fact that macro packages have to adapt (and i'm rather optimistic about that ... see how packages adapted to xetex); we will try to make luatex as compatible as possible, but not at all costs in a sense this is not related to luatex, because omega also had this; i can even imagine that omega packages will break with this whatsit not being there -) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
participants (3)
-
David Kastrup
-
Hans Hagen
-
Taco Hoekwater