October 2026 - dev-luatex

attribute list leak
by Udi Fogiel 15 Oct '26

15 Oct '26

For example \attribute1=1 \directlua{ for i = 1, 1000 do tex.attribute[1] = i local n = node.new('glyph') node.set_attribute(n, 2, 1) node.free(n) end print(status.node_mem_usage) } \bye in 059eb3a40c10c79bd153530ea6fff236e43b2722 there was another commented version that seems to work okay. One small behavior change: node.current_attr() returns the cache list without taking a reference. If Lua code is holding that list when a node using it gets set_attribute, with the patch the held list shows the node's change, where before it stayed as it was. node.current_attr() is documented as a query, and freeing a node already freed this list in the same way, so I don't expect this to matter. I attached a patch. Udi

2 4

links around visually non contiguous bidirictional text
by Udi Fogiel 13 Oct '26

13 Oct '26

Consider the following example: \def\SC{\pdfextension colorstack 0 push {1 0 0 rg 1 0 0 RG}} \def\EC{\pdfextension colorstack 0 pop {}} \pdfvariable linking 1 \def\S{\SC\pdfextension startlink attr{/Border[0 0 0.5]/C[1 0 0]} user{/Subtype/Link/A<</S/URI/URI(X)>>}} \def\E{\pdfextension endlink\EC} abc {\textdir TRT def\S ghi}jkl\E\ mno \bye The way link boxes are currently calculated assume that the result should be one box, but in such cases it is not possible. I attached a patch that adds \pdfvariable linking 2, with new calculation path that takes into account dir nodes. With it visually non contiguous text have more than one link box, similar to multi-line links. Any opinions? Udi

2 3

LuaTeX crashes when a VF packet length extends past EOF
by 정동우 07 Oct '26

07 Oct '26

Hello, LuaTeX 1.24.0 crashes while loading a virtual font whose long character packet declares a length past the end of the file. The VF is generated by vptovf. I changed only the four-byte packet length to 0x7fffffff; the companion TFM is unchanged. The resulting files are 328 bytes and 148 bytes. On TeX Live 2026 for Windows, LuaTeX exits with status 0xC0000005 before printing the LOADED marker. Python reports that status as 3221225477; its signed form is -1073741819. I reran it today and got the same result. Here is a self-contained Python reproducer. It expects vptovf and luatex on PATH: --- begin repro.py --- import pathlib import subprocess import tempfile VPL_HEAD = r"""(VTITLE Minimal long-packet EOF probe) (FAMILY VFEOF) (CODINGSCHEME UNSPECIFIED) (DESIGNSIZE R 10.0) (CHECKSUM O 0) (FONTDIMEN (SLANT R 0.0) (SPACE R 0.3) (STRETCH R 0.15) (SHRINK R 0.1) (XHEIGHT R 0.45) (QUAD R 1.0) (EXTRASPACE R 0.1) ) (MAPFONT D 0 (FONTNAME cmr10) (FONTCHECKSUM O 0) (FONTAT R 1.0) (FONTDSIZE R 10.0) ) (CHARACTER C A (CHARWD R 0.5) (MAP (SELECTFONT D 0) """ with tempfile.TemporaryDirectory() as temp: work = pathlib.Path(temp) vpl = VPL_HEAD + "\n".join([" (SETCHAR C A)"] * 250) + "\n )\n )\n" (work / "minimal.vpl").write_text(vpl, encoding="ascii") built = subprocess.run( ["vptovf", "minimal.vpl", "minimal.vf", "minimal.tfm"], cwd=work, stdout=subprocess.PIPE, stderr=subprocess.STDOUT, ) if built.returncode not in (0, 1) or not (work / "minimal.vf").is_file(): raise RuntimeError(built.stdout.decode(errors="replace")) vf = bytearray((work / "minimal.vf").read_bytes()) offset = 3 + vf[2] + 8 while 243 <= vf[offset] <= 246: n = vf[offset] - 242 checksum = offset + 1 + n area = vf[checksum + 12] name = vf[checksum + 13] offset = checksum + 14 + area + name assert vf[offset] == 242 vf[offset + 1:offset + 5] = (0x7fffffff).to_bytes(4, "big") (work / "long-huge.vf").write_bytes(vf) (work / "long-huge.tfm").write_bytes((work / "minimal.tfm").read_bytes()) (work / "probe.tex").write_text( "\\font\\f=long-huge\\relax\n\\message{<<LOADED>>}\n\\end\n", encoding="ascii", ) p = subprocess.run( ["luatex", "-interaction=nonstopmode", "probe.tex"], cwd=work, stdout=subprocess.PIPE, stderr=subprocess.STDOUT, ) print("VF bytes:", len(vf)) print("TFM bytes:", (work / "long-huge.tfm").stat().st_size) print("LuaTeX exit:", p.returncode) print("LOADED marker:", b"<<LOADED>>" in p.stdout) --- end repro.py --- I also checked the current vfovf.c. The packet loop is still controlled by the declared packet length, and the buffer read follows the EOF check in vf_byte. I did not build the current LuaTeX source, so that is only a source observation; the runtime result above is from 1.24.0. Should a long packet be rejected before decoding when its declared end is beyond the VF buffer? Best, Dongwoo Jeong doogwoo(a)gmail.com https://www.makonea.com

2 3