[XeTeX] additional beginL endL nodes in math

[David Carlisle]

On 15 April 2015 at 20:05, Khaled Hosny <khaledhosny at eglug.org> wrote:
> On Wed, Apr 15, 2015 at 04:29:47PM +0100, David Carlisle wrote:
>> Is there no other way that the issues you have could be addressed
>> without introducing TeX-XeT?
>
> I first reported this issue in 2008, 7 years ago, so it seems it is not
> going to go way magically, much to my surprise. Peter Breitenlohner
> became aware of this issue 2 years ago and a fix were promised but
> nothing so far (not that I blame him).
>


That was the question really,  is there a pointer to which issue this is fixing
sorry I don't know my way round the xetex issue control that well:-)

>
> AFAICS, a port from Omega model is unlikely to happen, it is a big
> invasive change and is as untested as the TeX-XeT model and has its own
> share of problems, and, more importantly, no one seems to be stepping up
> to do the required work.

Yes not surprised, really but still, having two incompatible direction systems
causes complications for cross-engine format like latex, and having three
incompatible mechanisms instead isn't exactly an ideal change.


>
>> The extra nodes added here really are a backward step, my first
>> suggestion of only conditionally
>> adding them doesn't really work if boxes containing math are saved and
>> used in different contexts.
>
> I fail to see that catastrophe this is causing.

In general things that are incompatible between engines are extra
maintenance work as we
have extensive regression checks that check that things are the same.
We can "make xetex pass"
by checking in a xetex-specific result file for every test file  that
involves math, but that's a far
from ideal situation.

But that extra work is just for the latex maintainers so not so bad
(for other people) but the main
problem is that non-removable nodes are a major problem when
manipulating TeX boxes, it's
bad enough that \mathon\mathoff nodes are not removable, but that can
be circumvented by
forcing the math list to break, but tex-xet then adds \beginL\endL
around each broken fragment
which basically makes all boxes generated from math totally opaque to
the macro layer.
that is the cause of the 0/700 difference in the tex file I posted and
in general will cause possible
differences in behaviour without warning when documents move between
xetex and pdftex/luatex.



>
>> Especially now in the Texlive 2015 pretest period there is so little
>> time to test any
>> changes.
>>
>> Would it be possible to back it out this change at least until after
>> TL2015 is released
>> That would give time to investigate a more compatible way to address the issues?
>
> This was backed out for 2014 release, if I’m going to back it out for
> each release why bother with it at all?

As I said that's the question really, what is the issue that this is
fixing and is it worth adding this level of incompatibility
between xetex and pdftex?

>
> Regards,
> Khaled
>

Honestly I'm sorry to be sounding so ungrateful, but if I don't
comment about things when I download a pretest and it causes nearly 80
of our test files to fail, I wouldn't be much use as a "tester":-)

David