- dev-luatex - Mailing Lists

misleading warning about pagedir differs from bodydir
by Udi Fogiel 18 Feb '26

18 Feb '26

The shipped box direction can be set explicitly, so we can get the warning even if bodydir and pagedir are the same: \showthe\pagedir\showthe\bodydir \shipout\vbox bdir 1 {Test}\bye This is LuaTeX, Version 1.22.0 (TeX Live 2025) restricted system commands enabled. (./test.tex > TLT. l.1 \showthe\pagedir \showthe\bodydir ? > TLT. l.1 \showthe\pagedir\showthe\bodydir ? [1 warning (backend): pagedir differs from bodydir, the output may be placed wrongly on the page I attached a diff withe a possible improvement. Udi

3 5

spurious enddir node
by Udi Fogiel 18 Feb '26

18 Feb '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

1 0

Re: Off-by-one error in node.protect_glyph?
by David Chiang 18 Feb '26

18 Feb '26

I see that part of my problem was creating glyph nodes with subtype 0 and I should use subtype 1 instead. But to be clear, these are the cases I found surprising: local a = node.new('glyph', 0) node.protect_glyph(a) node.protect_glyph(a) print(a.subtype) -- expected 256, actual 512 node.unprotect_glyph(a) node.unprotect_glyph(a) print(a.subtype) -- expected 0, actual 256 local b = node.new('disc') local c = node.new('glyph', 'character') b.replace = c node.unprotect_glyph(b) print(c.subtype) -- expected 1, actual 65281 The second case (expected 0, actual 256) is explained by what you wrote: we make an exception for 256 which can be used when > no subtype is set which makes it possible to disable unprotection. > But the first case still seems surprising to me, and the third case really looks like a bug to me. Thank you!

2 2

Why LuaHBTeX 1.24 is slower than 1.22?
by Petr Olsak 15 Feb '26

15 Feb '26

Hello I installed TL pretest 2026 a tried to run LuaHBTeX 2.24 with OpTeX macros. I noticed, that LuaHBTeX 2.24 (TeX live 2026) is significantly slower than LuaHBTeX 2.22 (TeX live 2025). Why? For example time optex optex-doc does: This is LuaHBTeX, Version 1.24.0 (TeX Live 2026) restricted system commands enabled. (/home/olsak/texmf/tex/optex/doc/optex-doc.tex ... real 0m17.367s user 0m16.836s sys 0m0.429s but time optex optex-doc with TL 2025 does: This is LuaHBTeX, Version 1.22.0 (TeX Live 2025) restricted system commands enabled. (/home/olsak/texmf/tex/optex/doc/optex-doc.tex ... real 0m9.676s user 0m9.205s sys 0m0.361s Regards Petr Olsak

5 7

Off-by-one error in node.protect_glyph?
by David Chiang 15 Feb '26

15 Feb '26

Greetings, it looks like node.protect_glyph changes a subtype of 256 to 512, and node.unprotect_glyph does not change a subtype of 256 to 0. Are the following changes correct: --- a/source/texk/web2c/luatexdir/lua/lnodelib.c +++ b/source/texk/web2c/luatexdir/lua/lnodelib.c @@ -6151,7 +6151,7 @@ static int lang_tex_direct_hyphenating(lua_State * L) #define protect_one_indeed(n) \ if (n != null) { \ int s = subtype(n); \ - if (s <= 256) { \ + if (s < 256) { \ subtype(n) = (quarterword) (s == 1 ? 256 : 256 + s); \ } \ } @@ -6162,7 +6162,7 @@ static int lang_tex_direct_hyphenating(lua_State * L) while (h != null) { \ if (type(h) == glyph_node) { \ int s = subtype(h); \ - if (s <= 256) { \ + if (s < 256) { \ subtype(h) = (quarterword) (s == 1 ? 256 : 256 + s); \ } \ } \ @@ -6182,7 +6182,7 @@ static int lang_tex_direct_hyphenating(lua_State * L) #define unprotect_one_indeed(n) \ if (n != null) { \ int s = subtype(n); \ - if (s > 256) { \ + if (s >= 256) { \ subtype(n) = (quarterword) (s - 256); \ } \ } @@ -6193,7 +6193,7 @@ static int lang_tex_direct_hyphenating(lua_State * L) while (h != null) { \ if (type(h) == glyph_node) { \ int s = subtype(h); \ - if (s <= 256) { \ + if (s >= 256) { \ subtype(h) = (quarterword) (s - 256); \ } \ } \

3 2

direction of an equation box
by Udi Fogiel 07 Feb '26

07 Feb '26

In texmath.c we have in various places eq_box = hpack(..., ..., ..., -1); the -1 means no explicit direction is passed to the box construction, so hpack is using the current value of \textdirection. Shouldn't \mathdirection (math_direction_par) be used here? This is also inconsistent with inline math, where \textdirection does not influence the visual result. Example: -------------------------- test $$ a+b=c\textdirection=1 $$ $\textdirection=1 a+b=c$ \bye-------------------------- This is similar to the recent discussion about \vcenter, which also does not use an explicit direction in its construction (there vpack use \bodydirection and not \mathdirection). Udi

1 0

question about \vcenter
by Udi Fogiel 06 Feb '26

06 Feb '26

Hello, Here is what happens when \vcenter is encountered: static void run_vcenter ( void ) { scan_spec (vcenter_group) ; normal_paragraph () ; push_nest () ; mode = -vmode; prev_depth_par = ignore_depth; if (every_vbox_par != null) begin_token_list (every_vbox_par, every_vbox_text) ; } So unlike other boxes is uses scan_spec and not scan_full_spec, which means it cannot accept the attr and (b)dir keywords, and the directions registers are not set to its direction inside of it. Then when it finishes we have: void finish_vcenter ( void ) { halfword p; unsave () ; save_ptr--; p = vpack (vlink (cur_list.head_field) , saved_value ( 0 ) , saved_level ( 0 ) , -1 ) ; pop_nest () ; p = math_vcenter_group (p) ; tail_append (p) ; } And because of the -1 in the last argument, its direction is determined by \bodydirection, unlike other boxes which in math context use \mathdirection if a (b)dir keyword was not specified. Why is that? It feels a bit inconsistent, and makes it a bit hard to follow directions. Thanks, Udi

3 5

different handling of dangling stream object if no page is output
by Ulrike Fischer 22 Jan '26

22 Jan '26

If I embed a stream object into a PDF but then no page is output then luatex gives a fatal error while pdftex gives only a warning about the dangling object: \ifcsname directlua\endcsname \immediate\pdfextension obj stream attr {} {blub} \else \immediate\pdfobj stream attr {} {blub} \fi \bye luatex: This is LuaTeX, Version 1.22.0 (TeX Live 2025) restricted system commands enabled. (./test-utf8.tex) warning (pdf backend): no pages of output. ! error: (pdf backend): already written content discarded, no output file produced. ! ==> Fatal error occurred, no output PDF file produced! pdftex: No pages of output. pdfTeX warning: pdftex.exe: dangling objects discarded, no output file produced. Is there a reason for the difference and the fatal error here? -- Ulrike Fischer http://www.troubleshooting-tex.de/

2 1

Too many tex.runtoks() calls overflows input stack
by David Chiang 23 Dec '25

23 Dec '25

Greetings, the following code for i = 1, 10000 do tex.runtoks(function () end) end causes the following error for me: ! TeX capacity exceeded, sorry [input stack size=10000]. <inserted text> BAD <inserted text> BAD <inserted text> BAD <inserted text> BAD <inserted text> BAD <inserted text> BAD ... Is this the intended behavior, and is there a way to pop from the stack to avoid the overflow? Thank you very much! David

4 5

luaharfbuzz, subsetting code
by Patrick Gundlach 12 Dec '25

12 Dec '25

Hello all, I have a patch for LuaTeX that includes the current luaharfbuzz at https://github.com/speedata/luatex/commits/feature/harfbuzzsubset/ I have added support for harfbzz-subset to the luaharfbuzz library (Khaled Hosny has merged it into the official repository). There is now an additional library that can be loaded with require('luaharfbuzzsubset') which contains subsetting code from the harfbuzz-subset library (which is also a separate library). The documentation is available at https://harfbuzz.github.io/luaharfbuzz/ The code compiles fine on latest macOS (both jit and non-jit) The last commit at https://github.com/speedata/luatex/commit/33b96a1fa4bd5ef840c28496a7992f48f… is a bit obscure to me, since I don't use luajittex. I cannot check the correctness of these patches, they are from the current luaharfbuzz integration in LuaTeX. I'd be happy if this could be merged into LuaTeX. Patrick

2 2