- dev-luatex - Mailing Lists

Increase sup_dest_names_size
by Max Chernoff 01 Jul '25

01 Jul '25

Hi Luigi, Can you please increase sup_dest_names_size (patch attached)? A user reported that the current value is insufficient for some of their documents, and as far as I can tell, increasing its value should be safe (but you'll know better than I do). I randomly guessed that I should increase it by a factor of 4, but maybe a different value would be better? I've verified that I can build the LuaTeX binaries and formats with this change, but I don't have any documents large enough to reach the old limit, so I can't actually confirm that the patch works as intended. --- Subject: [PATCH] Increase sup_dest_names_size by a factor of 4 Some users are receiving a sorry [number of destination names (dest_names_size)=131072] error with real-world documents https://12000.org/my_notes/faq/LATEX/html_and_latexchapter3.htm#x4-70003.1 https://tug.org/pipermail/luatex/2025-June/008101.html https://tug.org/pipermail/luatex/2022-March/007663.html and increasing sup_dest_names_size to 524288 should fix it. Named destinations are stored in a PDF /Dests name tree, and the PDF 2.0 specification §7.9.6 states that name trees can be arbitrarily large, and should not be subject to implementation-defined limits. The PDF 1.7 specification §C states that documents should not contain more than 8 million indirect objects, and even the new sup_dest_names_size is well beneath that. dvipdfmx only supports reading name trees 5 levels deep; with the 31 objects per level that ConTeXt defaults to, this is >30 million named objects, well above this new LuaTeX maximum. --- source/texk/web2c/luatexdir/pdf/pdfdest.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Thanks, -- Max

2 2

slnunicode seems to use data from Unicode 3.1
by Vítek Starý Novotný 24 Jun '25

24 Jun '25

Dear list, LuaTeX contains the library slnunicode for withing with Unicode strings. This library seems abandoned [1] and contains hard-coded data [2] that were extracted from the file `UnicodeData.txt`. By comparing [3] this data to files `UnicodeData.txt` from various versions of the Unicode standard, I concluded that they originate from Unicode 3.1 (released in March 2001). I am not sure if the LuaTeX team applies any patches to slnunicode but if not, then that's quite old! The good news is that updating the hard-coded data to the latest Unicode standard seems trivial and can be done using an automated script [4]. The bad news is that there were many changes to the Unicode standard since version 3.1 and broader changes may be necessary to bring the package up-to-date. [1]: https://github.com/LuaDist/slnunicode [2]: https://github.com/LuaDist/slnunicode/blob/master/slnudata.c [3]: https://github.com/Witiko/markdown/pull/557#issuecomment-2983818188 [4]: https://spacegit.unibe.ch/bela/mb-linux-msli/-/blob/38b8bc2d8ee86a6c4d0d833… Best, Vitek

1 0

Getters and setters for pdf_link_state whatsits
by Marcel Fabian Krüger 17 Jun '25

17 Jun '25

Hi LuaTeX team, I recently tried to interact with pdf_link_state whatsits from Lua and the current situation is a bit odd: If `n` is a pdf_link_state node, then `n.value` can be assigned to set the parmeter of the pdf_link_state node, but reading `n.value` results in nil. When using node.direct, neither getfield nor setfield for on the `value` field. Assuming that this is just an oversight I attach a patch to at all `value` to all the usual getters and setters. Best, Marcel

1 0

Re: \mathflattenmode becoming (hopefully not quite) obsolete
by Marcel Fabian Krüger 17 Jun '25

17 Jun '25

On Tue, Jun 17, 2025 at 12:11:11PM +0200, luigi scarso wrote: > Any news ? Hi, attached is the patch to un-obsolete(?) \mathflattenmode. Best, Marcel

1 0

\mathflattenmode becoming (hopefully not quite) obsolete
by Marcel Fabian Krüger 14 Jun '25

14 Jun '25

Hi, in recent LuaTeX versions \mathflattenmode has been marked as obsolete. We would like to use this functionality in LuaLaTeX, so it would be great if it could stick around. We only need it to disable flattening though, so if you want to avoid keeping the whole thing we would also be happy to just have a boolean "disable mth flattening" option equivalent to \mathflattenmode=0. Best regards, Marcel

2 1

A strange behavior of `\magstep0`
by li lu 08 Jun '25

08 Jun '25

Hi LuaTeX Team, I am writing to report strange behavior of the \magstep0 command , or the original magnification \csname @m\endcsname. The problem is happened in a macro with \afterassignment and then assign \magstep0 to a count register. For the LuaTeX version: luatex --version This is LuaTeX, Version 1.22.0 (TeX Live 2026/dev/Arch Linux) Development id: 7674 Execute 'luatex --credits' for credits and version details. There is NO warranty. Redistribution of this software is covered by the terms of the GNU General Public License, version 2 or (at your option) any later version. For more information about these matters, see the file named COPYING and the LuaTeX source. LuaTeX is Copyright 2025 Taco Hoekwater and the LuaTeX Team. The problem is happened in a macro with \afterassignment and then assign \magstep0 to a count register. A shortest description: ``` \newcount\count \def\problemhere#1\relax#2{\string#1#2} \def\todo{ \afterassignment\problemhere \count= } ``` For the above macro, \todo\magstep1{HERE} just print HERE while \todo\magstep0{HERE} print \or1200HERE. It seems that \magstep0 break the \ifcase structure in the \magstep definition, It seems that this is not a expected behavior. Complete use case steps and more details are on the stackoverflow page * https://tex.stackexchange.com/q/745864/248249 Sincerely, Yours

3 4

Crash when accessing the field 'data' of a whatsit(write) node
by Josef Friedrich 01 Jun '25

01 Jun '25

I’m the maintainer of the nodetree package. I got a bug report: https://github.com/Josef-Friedrich/nodetree/issues/46 I was able to narrow down the problem: debug.tex: \documentclass{article} \begin{document} \directlua{ luatexbase.add_to_callback('vpack_filter', function(head) if node.type(head.id) == 'whatsit' and head.subtype == 1 then local tmp = head.data end return true end, 'debug' ) } \begin{figure} \caption{test} \end{figure} \end{document} lualatex debug.tex: ! Incomplete \iffalse; all text was ignored after line 19. <inserted text> \fi l.19 \end{figure} The line 'local tmp = head.data' causes the error. I tried also 'print(head.data)' or 'local tmp = head['data']'. These access types also caused a crash. Access to fields other than data works without any problems. print(head.stream) print(head.id) print(head.xxx) Is this a bug in LuaTeX? Or how can I access the field 'data' of a whatsit(write) node for debugging purposes?

4 12

Unicode math: italic correction at the end of the math list
by Petr Olsak 28 Apr '25

28 Apr '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

6 11

Document the table variant of character.tounicode
by Max Chernoff 17 Apr '25

17 Apr '25

Hi Luigi, The "tounicode" key in the font character tables also supports passing an array of Unicode codepoints, which is _much_ nicer than trying to reencode characters into UTF-16BE (especially for non-BMP characters). The attached patch adds this to the manual. Thanks, -- Max

2 2

restrict pdfglyphtounicode to a tfm
by Ulrike Fischer 13 Apr '25

13 Apr '25

With pdftex it is possible to restrict a \pdfglyphtounicode declaration to a specific tfm. So in the following example the A from cmr10 is mapped to B, but the A from cmss10 is untouched: \pdfgentounicode=1 \pdfglyphtounicode{tfm:cmr10/A}{0042} A \font\test=cmss10 \test A \bye This is useful, e.g., to setup unicode mappings for older symbol fonts which often (mis)use standard glyph names. With luatex this doesn't work. Only the "general" mapping is honored here: \pdfvariable gentounicode =1 \pdfextension glyphtounicode {C}{0044} \pdfextension glyphtounicode {tfm:cmr10/A}{0042} C A \font\test=cmss10 \test C A \bye Would it be possible to extend luatex to support the tfm: syntax too? Or is there an alternative to change tounicode mappings? -- Ulrike Fischer http://www.troubleshooting-tex.de/

3 4