March 2026 - dev-luatex - Mailing Lists

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

Vendor Registration Invitation - OQ Refineries 2026 Projects,
by OQ Refineries 23 Mar '26

23 Mar '26

1 0

***SPAM*** Investment
by Alan James 23 Mar '26

23 Mar '26

Dear, I am reaching out to inform you of a private investor who has allocated substantial capital, between US$5 million and US$500 million, for investment in viable projects. The investor is offering financial support through loans featuring attractive interest rates and a clear repayment structure. Their investment interests span a diverse range of sectors, including real estate, business development and expansion, agriculture, manufacturing, and government contracts. Should you have any projects currently requiring funding that align with these criteria, I would welcome the opportunity to discuss them in more detail. Regards ALAN JAMES.

1 0

Purchase Order# 920526
by Muratcan Orcan 23 Mar '26

23 Mar '26

1 0

Segfault in LuaHBTeX 1.18.0 (TeX Live 2024) - Invalid read in lpeg.c:correctkeys
by Marco Coppola 20 Mar '26

20 Mar '26

Hi everyone, I am reporting a reproducible segfault in LuaHBTeX 1.18.0 occurring during intensive font loading (compiling a large font specimen). *Environment:* - OS: Gentoo Linux (Kernel 6.12) - Compiler: GCC 15.2.1 - LuaTeX compiled with: CFLAGS="-g -O1" FEATURES="nostrip splitdebug" *The Issue:* The crash does not happen on a single font, but rather after processing hundreds of fonts via fontspec/luaotfload. It seems to be a memory corruption or uninitialized value accumulation in the embedded LPeg library. *Valgrind Trace (Relevant snippet):* ==339700== Conditional jump or move depends on uninitialised value(s) ==339700== at 0x420AD41: correctkeys (lpeg.c:2403) ==339700== by 0x420BDCD: joinktables (lpeg.c:2447) ==339700== by 0x420E5B8: newroot2sib (lpeg.c:2693) ==339700== by 0x420E974: lp_choice (lpeg.c:2743) It appears that correctkeys is accessing uninitialized memory during a table join operation in LPeg. I have the full 15MB Valgrind log and a 4GB core dump available. I can provide the source .tex file and the font set upon request. Best regards, Marco -- Marco Coppola marco.n.coppola(a)gmail.com

4 4

\hbox bdir3{\vbox...}
by Petr Olsak 16 Mar '26

16 Mar '26

Hello, I experimented a little with various directions (TRT, RTL, RTT) and I have found illogical behavior in RTT direction. My question: is it desired behavior or it is a bug? I am not sure because I don't know any language where RTT needs to be used. My intend is to keep in a frame a boxes with various directions by OpTeX macros. Suppose: \hbox bdir0{\vrule\vbox{\hbox{ab}\hbox{xy}}} % OK \bigskip \hbox bdir2{\vrule\vbox{\hbox{ab}\hbox{xy}}} % OK \bigskip \hbox bdir3{\vrule\vbox{\hbox{ab}\hbox{xy}}} % problem \showboxbreadth=50 \showlists \bye First two boxes are correct. The boundaries of \vrule (vertical in first case, horizontal in second) are equal with boundary of box content (in visual output) and the baseline of outer \hbox is equal to the baseline of the last element of internal \vbox. But the third case (direction 3) recalculates the vertical baseline of the outer \hbox to be in the center, i.e. depth=height=8.70834pt, but the internal \vbox isn't shifted appropriately. We see that the \vrule is shifted relative to the box content. The \vrule shows the boundaries of the outer \hbox (which is vertical in this case) but the contents of this \hbox is shifted right from its right boundary. More logical behavior in this case is to keep the vertical baseline of outer box equal to the vertical baseline of the \vbox inside it it. Alternatively: if we need recalculation for centering (because we need centering of individual letters: \hbox bdir3{Mix}), then the \vbox inside the outer \hbox should be appropriately shifted. Best regards Petr Olsak

3 2

\rightmarginkern
by Robert 14 Mar '26

14 Mar '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

1 0