On 15 April 2015 at 20:05, Khaled Hosny <khaledho...@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 -------------------------------------------------- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
