On 15 March 2016 at 09:31, Hans Hagen <[email protected]> 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
