[luatex] luaharfbuzz breaks tostring
luigi.scarso at gmail.com
Sun Mar 15 23:22:18 CET 2020
On Tue, Mar 10, 2020 at 1:24 PM Simon Dales <simon at getthingsfixed.co.uk>
> 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
> 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
> // 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?
Yes the message is not nice, but it's not wrong .
Probably we will fix it in luatex 1.13.0 .
I have added a section to the reference manual -- it's the luaharfbuzz docs
plus the example.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the luatex