February 2025 - dev-luatex - NTG Mailing Lists

Unicode math: italic correction at the end of the math list
by Petr Olsak 18 Feb '25

18 Feb '25

Hello I suppose that the luatex binary is fixed for TeXlive 2025, so I can open an additional problem and I won't disturb you while finalizing the binaries:). Use this test file: ------------------- \input luaotfload.sty \font\f=[latinmodern-math]:mode=base;script=math; \textfont0=\f \Umathcode `f= 0 0 "1D453 % italic f from Unicode math font $f!$, $f$!, $f\/$! \showboxbreadth=100 \batchmode \showlists \bye --------------------- When luatex processes it, we get italic correction only in the first case: \mathon .\f 𝑓 .\kern0.9 (italic) .\f ! .\mathoff .\tenrm , .\glue(\spaceskip) 3.33333 plus 2.08331 minus 0.88889 .\mathon .\f 𝑓 .\mathoff .\tenrm ! .\tenrm , .\glue(\spaceskip) 3.33333 plus 2.08331 minus 0.88889 .\mathon .\f 𝑓 .\kern0.0 (font) .\mathoff .\tenrm ! Yes, fontforge shows that latinmodern-math italic f has italic correction 90, i.e. 0.9pt for the font at 10pt. And the italic correction is inserted in the first case according to rule 17 of appendix G of TeXbook, where we only need to add: "if the symbol is not a text symbol or if \fontdimen2 is zero **or if script=math fontfeature is used** then insert italic correction". It sounds OK, it is natural extension of the original Knuth's idea: his math scripts were in fonts cmmi10 and cmsy10 where \fontdimen2=0pt. But: A) why the italic correction isn't inserted in case 2? The rule 17 in appendix G of TeXbook says that "if the single-char atom isn't a text symbol (i.e. it isn't followed by a next specific atom) then the italic correction is inserted". The condition is obviously true for the last single-char atom of the math list. But luatex with Unicode math font doesn't respect this rule. Why? B) why there is \kern0.0 in the third case where we want to insert explicit italic correction (which is 0.9pt as fontforge says)? When we comment out the third line in our example (\textfont0=...), i.e. the classical plain TeX setting with 7bit tfm fonts is used, then luatex inserts italic correction in all three cases. It means that explicit \/ works and rule 17 from appendix G is respected. OK, maybe it is a decision of somebody who implemented Unicode math because missing italic corrections at the end of math list looks better, for example at the end of a sentence (ef-dot): $f$. I.e. the rule 17 from TeXbook will be not respected. But if our sentence ends by $f$! or by $f$? then the result looks very bad and user is unable to do local corrections by explicit \/. The problem is not due to simplification of the example here. If you try lualatex with unicode-math macros or OpTeX, you get the same results. Note that xetex puts correctly italic corrections in all three cases even though a Unicode math font is loaded. Can someone explain me this confusing behavior? Thanks Petr Olsak

4 9

Change in log indentation for luatex 1.21 (texlive 2025 pretest)
by David Carlisle 12 Feb '25

12 Feb '25

The new luatex shows differences in the way it indents and abbreviates log error lines. This is "only" logging but breaks several tests in the latex test suite which is essentially a regression test based around diff-ing normalised logs. If the change is intentional we can update the reference results (and maintainers of other packages using l3build tests will have to do similar) but if this change might be reverted we will hold off updating the test suite. Attached is a small test file and the tl2024 and tl2025 log. The diff is $ diff 24.log 25.log 1c1 < This is LuaTeX, Version 1.18.0 (TeX Live 2024) (format=luatex 2025.1.30) 12 FEB 2025 19:16 --- > This is LuaTeX, Version 1.21.0 (TeX Live 2025) (format=luatex 2025.2.12) 12 FEB 2025 19:16 7c7 < x} --- > x} 10c10 < l.5 ...elax\relax\relax\relax\relax\relax\show\relax --- > l.5 ...ax\relax\relax\relax\relax\relax\show\relax

2 2

Miscellaneous feature addition patches
by Max Chernoff 11 Feb '25

11 Feb '25

Hi Luigi, I've attached some small patches that I've been sitting on for a while (and forgot about until just before the TL25 freeze, sorry). These are all technically feature additions, and I'm aware that LuaTeX is frozen-ish, but the changes are mostly trivial, and there's a proven need for all of these features. I'll copy the commit messages below (and add the patches as attachments): # Add `token.fast_put_next` Currently, `token.put_next` gets the metatable for the passed token userdata object and compares it to the authoritative metatable from the registry. However, this is quite slow; in benchmarking some real-world code, this added 15% to the total runtime of the code: https://github.com/latex3/latex3/pull/1557#issuecomment-2241981665 The new function `token.fast_put_next` skips this error checking, and as such is faster. This does mean that if the passed value is a non-token userdatum, the engine will get confused and crash; however, the `node` and `node.direct` libraries already provide plenty of ways to corrupt the engine if you try hard enough, so this shouldn't be a significant issue. --- manual/luatex-tex.tex | 8 +++- .../texk/web2c/luatexdir/lua/lnewtokenlib.c | 41 +++++++++++++++++++ 2 files changed, 48 insertions(+), 1 deletion(-) # Support setting the environment with "os.spawn". It's not currently possible to create a new process with a custom environment, even though this is fairly useful functionality. This was requested by the l3build developers https://chat.stackexchange.com/transcript/message/65794389#65794389 since right now, l3build uses the shell to do this https://github.com/latex3/l3build/blob/f75745/l3build-file-functions.lua#L1… https://github.com/latex3/l3build/blob/f75745/l3build-file-functions.lua#L1… but this is both non-portable and error-prone. --- manual/luatex-lua.tex | 6 ++++++ source/texk/web2c/luatexdir/lua/loslibext.c | 24 +++++++++++++++++++-- 2 files changed, 28 insertions(+), 2 deletions(-) # Permit usage of the `img` module in `texlua` mode. This is needed for a Lua-based reimplementation of `extractbb` to work without the `ffi` library; see https://github.com/gucci-on-fleek/extractbb/blob/v0.0.7/source/extractbb-sc… for further context. This may also be useful for other scripts; see https://github.com/atticus-sullivan/memoize/pull/2#issuecomment-2613860793 for another example. --- source/texk/web2c/luatexdir/lua/luastuff.c | 4 +--- source/texk/web2c/luatexdir/pdf/pdfgen.c | 2 +- 2 files changed, 2 insertions(+), 4 deletions(-) Thanks, -- Max

2 3

wrong spacing around display with \matheqdirmode=1
by Udicoudco 06 Feb '25

06 Feb '25

This is the current test for deciding not to use shortskip ((d + line_s <= pre_display_size_par) || ((! dir_math_save && l) || (dir_math_save && ! l))) It has two problems: * if eqno_box is null then l (the leqno bool) is always false, so for short unnumbered equations the test is reduced to the value of dir_math_save which is based on \textdirection and \mathdirection, but in this case shortskip should always be used. * dir_math_save is correlated to \textdirection, but the shortskip detection should be based on the position of the equation number, and parfillskip, none of which \textdirection controls. I think \pardirection should be tested here. Here is a faulty example, where shortskip should be used but it is not \matheqdirmode=1\pardirection=1\textdirection=1 Test $$ Test $$ Test \bye In fact if I change \textdirection in this example shortskip is used, which kind of demonstrates the second point. For a better example of the second point you can test \matheqdirmode=1\textdirection=1 Test $$ Test\leqno(1) $$ Test \bye Whereas \textdirection and \mathdirection are opposites dir_math_save is true and leqno bool is false, hence short skp is used but the output clearly shows it should not be, as the equation number is right below the text. Note that I also tested with LuaTeX 1.18.0 to make sure this is not the fault of recent changes. I attached a patch. Udi

2 4

Ignore null paragraph before display equation
by Udicoudco 04 Feb '25

04 Feb '25

Currently LuaTeX ignores "null paragraphs" (see the manual at the end of section 3.3.2 "How it works"), but it is actually doing so only for paragraphs created with end_graf. enter_display_math ignores paragraphs if they only contain local_par nodes, but not if they also contain dir nodes. This is somewhat inconsistent, so it would be nice if enter_display_math would discard paragraphs like end_graf. I attached a patch. It is almost identical to the change in https://gitlab.lisn.upsaclay.fr/texlive/luatex/-/commit/908e51adaad4b4048fe… but it is even smaller, since enter_display_math already discard paragraphs containing only local_par nodes. Even though this change is less disruptive, there might be more concerns about backwards compatibility today than three years ago, if this is the case a new value to \matheqdirmode can be added. Udi

3 11

Re: charwidth and fullembed fonts
by luigi scarso 04 Feb '25

04 Feb '25

On Tue, 4 Feb 2025 at 10:49, luca boncompagni <lbonco(a)gmail.com> wrote: > > in attach you can find my use case. This is what I have with evince and mutool bake. -- luigi

1 0

missing displacement when leqno is used in rtl paragraph
by Udicoudco 03 Feb '25

03 Feb '25

Hello, I think that displacement of a the of a math display is missing when \leqno is used in RTL paragraph. I attached a patch. Here is a simple test code (it requires the cmr10 font): \catcode`\{=1\catcode`\}=2\catcode`\$=3 \directlua{tex.enableprimitives("",{"pardirection", "textdirection", "Umathquad"})} \tracingoutput=1\tracingonline=1 \showboxbreadth 16384 \showboxdepth 16384 \font\tenrm=cmr10 \textfont0=\tenrm \hsize=345pt\vsize=550pt\parfillskip=0.0pt plus 1.0fil \parindent=15pt\parskip=0pt plus1pt \Umathquad\textstyle=10pt \pardirection=1\textdirection=1 $$1 \leqno(1)$$ \end Udi

5 15

charwidth and fullembed fonts
by luca boncompagni 03 Feb '25

03 Feb '25

Hi to all. I think that if I do a fullembed of a font, it is not correct to include the only charwidth used in the pdf. Think about a font used in a /Form. I tested the attached patch and it seems ok in my case, but I'm not sure it is fully OK. Thanks, Luca

3 2

beforedisplaypenalty has wrong subtype
by Udicoudco 02 Feb '25

02 Feb '25

This is probably just a typo. Since penalty node subtypes are only informational this is a really minor issue. There's a patch attached. Udi

2 1