On 3/15/2016 10:50 AM, David Carlisle wrote:
The output here is using 8bit cm fonts so I'm not sure how opentype is relevant.
Well, I assume that when you talk about comparable output you mean all
kinds of math output and then fonts come into play. So, they are
relevant in the sense that in order to support both, we have some places
in the code where there code paths meet (unless we completely split math
engines: old untouched vs new, adapted). So, if we can share bit of code
(i didn't check the details) by replacing a shift by a kern (or
whatever) so be it. Basically what happened was that the new code
(already from years ago) was kind of guessing what solution was needed
for what font, and that in the end became too fragile which then was
changed into different code paths but not going back to old code, also
because we have more parameters to deal with). So, even for 8 bit fonts
and the old approach code path there can be differences. So ... maybe
more wrapping (extra boxes) or different spacing models (kerns vs shifts).
I assume that when you talk about classical tex output you refer to e.g.
pdftex but maybe i misunderstand. Luatex will not be compatible at that
level, also because for instance in the eqno case you mention related
code has to deal with right to left math / numbers / placement and mixed
cases and that gets reflected in how boxes come out. So again we don't
aim at (or even care about) compatible output at the box level.
Hans
-----------------------------------------------------------------
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | www.pragma-ade.com | www.pragma-pod.nl
-----------------------------------------------------------------
