Exit code: 0
Wall time: 0.3 seconds
Output:
LuaTeX 1.24.0 accepts a TFM whose char_info word for a nonexistent character
contains an out-of-range index. TeX, pdfTeX, and XeTeX reject the same file
with "Bad metric (TFM) file."
Reproduction
------------
$ cat > gap.pl <<'EOF'
(FAMILY GAPTEST)
(DESIGNSIZE R 10.0)
(CHARACTER C A (CHARWD R 0.5))
(CHARACTER C E (CHARWD R 0.25))
EOF
$ pltotf gap.pl gap.tfm
$ python3 -c "b=bytearray(open('gap.tfm','rb').read()); b[102]=252; \
open('gap-bad.tfm','wb').write(bytes(b))"
This gives bc=65, ec=69, ni=1, and sets italic_index to 63 on character 66.
That character has width_index zero, so it does not exist in the font.
$ cat > t.tex <<'EOF'
\catcode`\{=1 \catcode`\}=2
\font\f=gap-bad \relax
\end
EOF
$ for e in tex pdftex luatex xetex; do
> printf "%-8s " $e
> $e --ini --interaction=nonstopmode t.tex 2>&1 | grep -q "not loadable" \
> && echo reject || echo ACCEPT
> done
tex reject
pdftex reject
luatex ACCEPT
xetex reject
The implementation difference
------------------------------
LuaTeX's "Read character data" loop contains this test:
for (k = bc; k <= ec; k++) {
store_char_info(k);
if (ci._width_index == 0)
continue;
if (ci._width_index >= nw || ci._height_index >= nh ||
ci._depth_index >= nd || ci._italic_index >= ni)
tfm_abort;
TeX's corresponding loop checks every char_info word in bc..ec. The same
width_index gate also skips LuaTeX's lig_tag, ext_tag, and charlist checks.
For the out-of-range index in this example, the skipped fields belong to a
character that will never be looked up. The practical consequence is still
that a damaged font can load under lualatex and fail under pdflatex, with no
clear indication of why the engines disagree.
TFtoPL has the same gate in tftopl.web, so LuaTeX currently agrees with TFtoPL
and disagrees with TeX. I have reported that inconsistency to tex-k separately.
If TFtoPL is changed to match TeX, LuaTeX may want to follow that change; if
the decision goes the other way, tex.web is the outlier instead.
--
jdw64
doogwoo(a)gmail.com
https://www.makonea.com
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
