- dev-luatex - Mailing Lists

Support for 8-byte xref offsets in PDF
by Charlotte Curtis 03 Jul '26

03 Jul '26

Hi all, I was advised to contact this list about a problem with LuaTex including PDFs created by Inkscape's new PDF exporter. I posted an issue on the Latex GitHub, where they quickly identified <https://github.com/latex3/latex2e/issues/2131#issuecomment-4792495907> that the problem is that our PDFs have 8-byte offsets in the xref table, while LuaTex only supports up to 4 bytes. Would it be possible for the PDF library in LuaTex to be updated to support more than 4 bytes per x-ref field? In the meantime, I'll look into restricting things on the authoring end (as realistically, 4 bytes should be enough in most cases). Thanks, Charlotte

4 5

wrong shift of rules with left field
by Udi Fogiel 22 Jun '26

22 Jun '26

Hello, if a rule has a left field set the backend adds a shift to it, and this shift should be dependent on the outer direction (but it currently does not). I attached a patch with a fix. thanks, Udi

2 3

italic correction between math letters
by Petr Olsak 16 Jun '26

16 Jun '26

Hello, I noticed a change between the versions LuaHBTeX 1.22.0 (TeX Live 2025) and LuaHBTeX 1.24.0 (TeX Live 2026). When I try to process this file by OpTeX: ----------------- \fontfam[lm] \tracingfonts=1 \setbox0=\hbox{$efff, {\_itletters efff}$} \showbox0 \bye ----------------- then I get following log with version 1.22.0: ----------------- This is LuaHBTeX, Version 1.22.0 (TeX Live 2025) (format=optex 2025.4.3) 16 JUN 2026 16:59 restricted system commands enabled. ... > \box0= \hbox(7.05+2.05)x46.76657, direction TLT .\mathon .\_mF ([latinmodern-math]:mode=base;ssty=0;mathsize=1;script=math;@10.0pt) 𝑒 .\_mF ([latinmodern-math]:mode=base;ssty=0;mathsize=1;script=math;@10.0pt) 𝑓 .\kern0.9 (italic) .\_mF ([latinmodern-math]:mode=base;ssty=0;mathsize=1;script=math;@10.0pt) 𝑓 .\kern0.9 (italic) .\_mF ([latinmodern-math]:mode=base;ssty=0;mathsize=1;script=math;@10.0pt) 𝑓 .\kern0.9 (italic) .\_mF ([latinmodern-math]:mode=base;ssty=0;mathsize=1;script=math;@10.0pt) , .\glue(\thinmuskip) 1.66663 .\hbox(7.05+2.05)x20.25998, direction TLT ..\_mF ([latinmodern-math]:mode=base;ssty=0;mathsize=1;script=latn;@10.0pt) 𝑒 ..\_mF ([latinmodern-math]:mode=base;ssty=0;mathsize=1;script=latn;@10.0pt) 𝑓 ..\_mF ([latinmodern-math]:mode=base;ssty=0;mathsize=1;script=latn;@10.0pt) 𝑓 ..\_mF ([latinmodern-math]:mode=base;ssty=0;mathsize=1;script=latn;@10.0pt) 𝑓 ..\kern0.9 (italic) .\mathoff ------------------- But when I do the same with version 1.24.0, I get: -------------------- This is LuaHBTeX, Version 1.24.0 (TeX Live 2026) (format=optex 2026.6.4) 16 JUN 2026 17:01 restricted system commands enabled. ... > \box0= \hbox(7.05+2.05)x48.56656, direction TLT .\mathon .\_mF ([latinmodern-math]:mode=base;ssty=0;mathsize=1;script=math;@10.0pt) 𝑒 .\_mF ([latinmodern-math]:mode=base;ssty=0;mathsize=1;script=math;@10.0pt) 𝑓 .\kern0.9 (italic) .\_mF ([latinmodern-math]:mode=base;ssty=0;mathsize=1;script=math;@10.0pt) 𝑓 .\kern0.9 (italic) .\_mF ([latinmodern-math]:mode=base;ssty=0;mathsize=1;script=math;@10.0pt) 𝑓 .\kern0.9 (italic) .\_mF ([latinmodern-math]:mode=base;ssty=0;mathsize=1;script=math;@10.0pt) , .\glue(\thinmuskip) 1.66663 .\hbox(7.05+2.05)x22.05997, direction TLT ..\_mF ([latinmodern-math]:mode=base;ssty=0;mathsize=1;script=latn;@10.0pt) 𝑒 ..\_mF ([latinmodern-math]:mode=base;ssty=0;mathsize=1;script=latn;@10.0pt) 𝑓 ..\kern0.9 (italic) ..\_mF ([latinmodern-math]:mode=base;ssty=0;mathsize=1;script=latn;@10.0pt) 𝑓 ..\kern0.9 (italic) ..\_mF ([latinmodern-math]:mode=base;ssty=0;mathsize=1;script=latn;@10.0pt) 𝑓 ..\kern0.9 (italic) .\mathoff -------------------- It means that the font with script=latn behaves equally as the font with sript=math, the italic corrections are inserted after each character if they are defined in the font. The older version 1.22.0 enabled me to switch off the inserting of italic corrections when script=latn. OK, maybe it is desired behavior. If so, then I am finding a solution of my problem: how to suppress italic correction between letters of math font in math mode? Best regards Petr Olšák

2 1

coordinate corruption with spurious enddir node
by Udi Fogiel 12 Jun '26

12 Jun '26

Hello, There is a guard in hlist_out that check if an enddir is actually matching anything, his is done with checking dir_done. But dir_done is only set to 1 when a begindir is encountered, and never reset back. This can lead to a problem with the following: ....\begindir TRT ....\enddir TRT ....\glue(\spaceskip) 3.33 plus 1.665 minus 1.11....\enddir TLT the first couple save a state, then the spurious enddir restore the coordinates to a bogus value. This nodes structure can be achieved with e.g. \textdirection=0 \indent{\textdirection=1} \textdirection=0 abc\bye Note how the text is at the bottom left of the page. I attached a patch where dir_done is incremented in the begindir branch, and decreased if a matched enddir is found. Thanks, Udi

2 4

Failed os.spawn() causes part of file to be read twice
by David Chiang 06 Jun '26

06 Jun '26

Greetings, a bug was reported at https://github.com/gregorio-project/gregorio/issues/1757 which appears to be a bug in LuaTeX. In the following program: main.tex: \documentclass{article} \begin{document} \input{fragment} \end{document} fragment.tex: \directlua{os.spawn('/does/not/exist')} text the word "text" should be printed once, but is actually printed twice. Please see the link above for the explanation of why this happens. I believe the fix is to open all files with O_CLOEXEC set. Thank you!

2 3

\rightmarginkern
by Robert 22 Apr '26

22 Apr '26

Hi, the following gives different results in luatex and pdftex: while the right margin kern will not be reported by pdftex because of the fil in parfillskip, luatex will show it nonetheless. Is this expected? (A real-world example is this: https://github.com/schlcht/microtype/issues/57) \ifx\directlua\undefined \pdfprotrudechars2 \else \protrudechars2 \fi \lpcode\font`(=500 \rpcode\font`)=500 \parindent0pt %\parfillskip0pt \showboxbreadth99 \setbox0\vbox{( )} \setbox0\vbox{\unvbox0 \setbox0\lastbox \showbox0 \message{L: \leftmarginkern0^^JR: \rightmarginkern0^^J}} \bye Bye, -- Robert

2 2

spurious enddir node
by Udi Fogiel 10 Apr '26

10 Apr '26

Hello, with the following I get an orphan enddir node ============================== run \linedirection=1 run \linedirection=0 run run \linedirection=1 run \bye ============================= This can confuse the par builder in some situations, and even worse it can confuse the code in pdflistout.c Another example, where the confusion is visible, is ================================= run \linedirection=1 run \linedirection=0 run run {\linedirection=1 run} run \linedirection=1 run \bye================================= Note how the last "run" (or nur with direction) is at the bottom left corner. In fact, anything in the problematic line that is after the problematic point is being shifted, and after the line break things are restored: ============================ run \linedirection=1 run \linedirection=0 run run {\linedirection=1 run} run \linedirection=1 run \linedirection=0 run Some more\hfill\break text \bye ============================ I think this is because when hlist_out() encounters the orphan enddir node the coordinate system gets corrupted because the orphan enddir causing it the be restored to bogus saved values. The enddir node is inserted in https://gitlab.lisn.upsaclay.fr/texlive/luatex/-/blob/master/source/texk/we… or (with \textdirection) in https://gitlab.lisn.upsaclay.fr/texlive/luatex/-/blob/master/source/texk/we… Udi

2 6

Re: Purchase Order PO39012345
by Sales 25 Mar '26

25 Mar '26

1 0

Purchase Order_NO43902
by TVXBS EXPORTS 25 Mar '26

25 Mar '26

1 0

Re: Follow-up to deterministic heap corruption in LuaTeX math font loading
by luigi scarso 23 Mar '26

23 Mar '26

On Mon, 23 Mar 2026 at 21:53, Marco Coppola <marco.n.coppola(a)gmail.com> wrote: > Dear LuaTeX developers, Dear Max, > > Following up on the font loading issues discussed recently, I have > performed a clean build of the *2026 branch* from the repository with *no > optimizations and full debug symbols* (-O0 -g3). > > Using Valgrind on this build, I have isolated a deterministic heap > corruption. The crash is caused by a buffer overflow in math font parameter > handling that triggers systematically once a sufficient number of fonts are > loaded. > In fact, I was starting to suspect something like that instead of lpeg. I will check it tomorrow. -- luigi >

1 0