[luatex] luaharfbuzz breaks tostring
Simon Dales
simon at getthingsfixed.co.uk
Tue Mar 10 08:23:12 CET 2020
Luigi Scarso,
When building/testing the new TeX Live 2020 (for Raspberry Pi) I spotted
an apparent fault with luaharfbuzz.
I did a recursive listing of _G and it broke. Turned out that some of
the classes' tostrings are broken.
The lua reference says that tostring() should return a sensible string
for __all__ values.
////////////////
for k,v in pairs(luaharfbuzz) do
print(k,v)
end
////////////////
The errant entries: Direction, Feature, Language, Script, Tag
// investigation
I checked the classes' metatables for __tostring, and the errant ones
all had an entry, and those without worked fine.
Checked the c sources and the classes with a simple register_class()
worked fine. Those that set their own explicit __tostring() caused the
problems.
// test 1
In my lua test script I iterated over luaharfbuzz looking for
metatable.__tostring nd set to nil. Then re-listed, and all happy.
// test 2
I checked the sources, commented out their __tostring entries and
rebuilt. The TeX Live ./Build self-tests work OK.
So now the luaharfbuzz table has no __tostrings and now passes.
Now they all return strings of the form: "harfbuzz.wibble: 0x12eac68",
like one would expect.
//////////////
* How did this get through?
* Is it safe to run luaharfbuzz with their __tostrings suppressed?
* Other/better solution?
/////////////////
Simon
More information about the luatex
mailing list.