# [luatex] math display box structure

Hans Hagen pragma at wxs.nl
Tue Mar 15 10:31:32 CET 2016

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
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)

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

(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)

Hans

-----------------------------------------------------------------