Bug in 3.141592653-2.6-0.999995 (TeX Live 2023) with fontspec and tabularray?

[Bruno Voisin]

> On 7 Feb 2024, at 22:36, Karl Berry <karl at freefriends.org> wrote:
> 
> The question in my mind is that D2Fix is used in many places throughout
> XeTeX (see below). Thus changing that fn to truncate instead of round
> seems like an awfully big change to be making at this point, with the
> potential of changing line breaks in any existing document. Will it
> cause more problems than it will solve? Although I can see that fixing
> xetex to have the same breaks as other engines is certainly desirable.

That is impressive debugging indeed! How you (Ross) managed to identify that piece of code as the culprit is beyond me.

It also required a bit of thinking on my part to figure out how the addition of 0.5 before converting a real number to an integer transforms truncation into rounding. Quite simple actually, I get it now, but I hadn't done that sort of things in a very long time.

This magical number 65536 rang a bell but I couldn't remember why. Well, as usual the TeXbook is the clue: that's the value of a printer's point in the integer internal unit, the scaled point sp, used by TeX when manipulating all dimensions. So D2Fix does the conversion to this unit, I can imagine how far-ranging any change would be.

It seems Don Knuth was a bit too optimistic when he wrote

"TEX represents all dimensions internally as an integer multiple of the tiny units called sp. Since the wavelength of visible light is approximately 100 sp, rounding errors of a few sp make no difference to the eye. However, TEX does all of its arithmetic very carefully so that identical results will be obtained on different computers. Different implementations of TEX will produce the same line breaks and the same page breaks when presented with the same document, because the integer arithmetic will be the same."

Of course, such matter arises at the worst possible time, just as the compilation of tl2024 pretest is about to start.

Bruno Voisin