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

[Ross Alexander]

 Hello,
I've redone the change, including the BIDI_MIXED case, but not tested that.  If the attached diff doesn't come though it also online at src/texworks/XeTeX_ext.c.diff at main · ross-alexander/src.

| 
| 
| 
|  |  |

 |

 |
| 
|  | 
src/texworks/XeTeX_ext.c.diff at main · ross-alexander/src

Various open source projects. Contribute to ross-alexander/src development by creating an account on GitHub.
 |

 |

 |




    On Wednesday, 17 April 2024 at 21:15:01 BST, Karl Berry <karl at freefriends.org> wrote:  
 
 Hi Ross - thanks for pursuing this further.

            // Use summed advances rather than rounded sum
            node_width(node) = advances_fixed;

(For clarity, in the future it would be good to send the actual diff
instead of just the new code. But yes, I see it in XeTeX_ext.c around
line 2100, as you said.)

The question that comes to my mind is, what does LuaTeX do here? 
Luigi (or anyone), when computing the width of a run of
OpenType/TrueType glyphs, does luatex take the width values (reals) from
the font and round each one individually, then sum them up? Or add the
reals and only round the sum?

Since converting to fixed once gives a more accurate result, it doesn't
seem right to convert the individual values.

Overall, I think the thing to find (somehow) is at what low-level point
LuaTeX and XeTeX compute something differently. --thanks, karl.
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://tug.org/pipermail/tex-live/attachments/20240418/4198539e/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: XeTeX_ext.c.diff
Type: application/octet-stream
Size: 5717 bytes
Desc: not available
URL: <https://tug.org/pipermail/tex-live/attachments/20240418/4198539e/attachment-0001.obj>