[luatex] math display box structure

David Carlisle d.p.carlisle at gmail.com
Tue Mar 15 10:50:52 CET 2016


On 15 March 2016 at 09:31, Hans Hagen <pragma at wxs.nl> wrote:
> On 3/14/2016 9:59 PM, David Carlisle wrote:
>>
>> Hi,
>>
>> luatex constructs boxes for display math differently to classic tex,
>> typically adding kerns rather than shifting.
>>
>> In simple cases it makes the same visual output but it is easy to find
>> cases where the typeset output is different
>>
>>
>> \setbox0\vbox{$$ x \eqno (1)$$
>> \par
>> \unskip
>> \unpenalty
>> \global\setbox1\lastbox}
>>
>> \the\wd1
>>
>> \box1
>>
>> \bye
>>
>>
>> However even when the typeset output looks the same the fact that the
>> box log is so different makes regression testing quite hard. The
>> recent bug reports about \choose
>> and \thinmuskip only came to light after manually filtering out
>> hundreds of lines of box differences due to the different box
>> constructs.
>>
>> Accepted that luatex logging is never exactly the same as pdftex's, is
>> there a particular new functionality that is gained by these changes,
>> or failing that is there any documentation (other than the luatex
>> source code) of the expected places where the box structure for
>> mathematics will be different, so that we can try to automate
>> filtering out these differences for regression testing?
>
>
> the code paths for traditional tex and opentype math tex are different


Of course but there are no opentype fonts being used here.

> because the models are slightly different (things like italic correction and
> such are completely different which demands different code paths; also we
> have some extensions that demand a bit different approach)

Yes but not relevant to this question.

>
> as a consequence there are also possible differences between the rendered
> math and we don't aim at them being compatible (8 bit font based vs wide
> fonts)
>
> in fact, probably after 1.0 i will experiment a hit with even less shift
> based in the opentype code path simply because it is a bit messy when in a
> viewer one selects (e.g for cut/paste) and so because there is much lying
> about dimensions that way
>
> (in a similar fashion one cannot expect 8 bit font handling e.g. with
> ligatures to be compatible with opentype solutions)
>
> so the answer is: no, they will not be made the same and might even divert
> more (and don't expect 8 bit font output to be the same as their opentype
> successors)

The output here is using 8bit cm fonts so I'm not sure how opentype is relevant.

>
> Hans

David


More information about the luatex mailing list