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

[Karl Berry]

Ross and all - regarding the rounding vs. truncation question in XeTeX
https://sourceforge.net/p/xetex/bugs/185/.

The answer does not seem so simple to me. The bottom line is that I'd
like to understand specifically why those minutely different values
cause different breaks. I think something is different "downstream" from
the D2Fix computation. But I don't have the time or energy to follow up,
sorry; hope you do, or someone does.

Details ...

Agreed that changing XeTeX's D2Fixed to do truncation fixes this
particular line break difference. I could reproduce that.

However, I don't think the rounding is an error, per se, because the
other engines do rounding. Citing Thanh about pdfTeX:

thanh> pdftex uses ext_xn_over_d (defined as extxnoverd in utils.c) for
thanh> calculations that involve real numbers. It does rounding, not 
thanh> truncating.

LuaTeX also rounds (just) like XeTeX, at least in some places:
scarso> #define lua_roundnumber(a,b)  (int)floor((double)lua_tonumber(a,b)+0.5)

So just forcing truncation does not feel right. It fixes this particular
xetex+10.95pt case, but who knows what other changes will ensue?  We
could add something like a \XeTeXfloatconversion={1,0} switch so that a
document can choose, but ... before we blindly make such a broad change,
I think the underlying question is what happens with the line breaking
after truncation and why the different outcomes are happening in the
first place.

--

Additionally: as Nelson pointed out, there is an error in XeTeX's and
LuaTeX's rounding of simply adding 0.5; with negative numbers, that will
not round to the nearest integer (it's necessary to subtract 0.5, not
add, when the argument is negative). pdfTeX does not have this error;
the pdftex code looks like (essentially):
    if (r > DBL_EPSILON) r += 0.5;
    else r -= 0.5;
    ...
    return (scaled) r;

Unfortunately, when I changed D2Fix to round negative numbers correctly,
it made no difference in the Dest-Addr example. Not surprisingly, since
almost all numbers coming from fonts are positive. So that is not the
answer in practice.

--

Additionally: the engine comparisons are problematic.

1) pdftex is using cmr10.tfm(+pfb) for the font. With traditional TeX
line breaking, floating point is not involved at all.

2) With XeTeX, on the other hand, the test document is reading
lmroman10-regular.otf, a completely different font rendered in a
completely different way. One immediate question is whether the metrics
of lmroman10-regular.otf match *exactly* the metrics of cmr10.tfm.
And whether otf vs. tfm makes a difference wrt hyphenation.

3) With LuaTeX, lmroman10-regular.otf is also being read, so XeTeX and
LuaTeX at least have that basis of comparison. However, there are many
differences in how luatex and xetex operate.  E.g., for one thing,
LuaTeX gets the "bad" Dest-<linebreak>Addr output with many font sizes,
I tried from 10.90 to 10.99 and they all broke after the hyphen, unlike
XeTeX where (as you noted) it has to be 10.95 exactly.

3b) With LuaTeX, in principle there is also the question of whether the
"native" rendering is used (luatex) or harfbuzz (luahbtex). However, I
found no difference in the test document either way.

Another possible difference is that XeTeX might "snap" to the limited
number of heights/depths/widths available in tfm format, even when using
otf? Not sure. LuaTeX does not do this.

Although I can't find it now, I seem to recall that Ulrike(?) wrote a
TUGboat article about differences between LuaTeX and XeTeX, e.g., LuaTeX
computing a lot more in floating point before converting to fixed, and
plenty of computations happen in Lua.


Finally, in case anyone does want to take this further: I tweaked the
test document to run under -ini, since it's much easier to experiment
with engine changes without having to bother building a .fmt. Also added
a conditional so it would run with both xetex and luatex. Appended below
and also posted to the xetex bug report.

Thanks,
Karl


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% https://sourceforge.net/p/xetex/bugs/185/

% ini doesn't work without setting more line breaking params.
\catcode`\{=1 \catcode`\}=2 \catcode`\#=6 
\hsize=6.5in \vsize=9in
\parfillskip=0pt plus1fil
\hyphenpenalty=50
\exhyphenpenalty=50
\doublehyphendemerits=10000
\finalhyphendemerits=5000
\defaulthyphenchar=`\-
\lefthyphenmin=2 \righthyphenmin=3 % disallow x- or -xx breaks

\catcode`@=11
\chardef\@ne=1
\chardef\tw@=2

\def\loggingall{\tracingcommands\tw@\tracingstats\tw@
  \tracingpages\@ne\tracingoutput\@ne\tracinglostchars\@ne
  \tracingmacros\tw@\tracingparagraphs\@ne\tracingrestores\@ne}
% maxdimen errors  \showboxbreadth\maxdimen\showboxdepth\maxdimen}

\def\test#1{%
  \setbox0=\hbox{#1}
  \vbox{\hsize=\wd0 \leftskip0pt plus 1fil  #1} % emulate \raggedleft etc.
  \vskip5pt
  \vbox{\hsize=\wd0 \rightskip0pt plus 1fil #1}
  \vskip5pt
  \vbox{\hsize=\wd0 \leftskip0pt plus 1fil \rightskip\leftskip #1}
}

%\font\1="[lmroman10-regular]" at 10pt \1
%\test{Dest-Addr} % ok

\ifx\directlua\undefined
  \font\1="[lmroman10-regular.otf]"
\else
  \let\dump\relax \input luatex.ini % so we can:
  \input luaotfload.sty
  \font\1="[lmroman10-regular.otf]"
\fi
   at 10.90pt
\loggingall
\1
\test{Dest-Addr} % unwanted line breaks right after hyphen char
% none of 10.94pt nor 10.96pt can reproduce the problem with xetex.

%\font\1="[lmroman10-regular]" at 11pt \1
%\test{Dest-Addr} % ok

\end