Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Why does luatex fail/crash when font.each() is used. #3

Closed
u-fischer opened this issue Sep 25, 2018 · 11 comments
Closed

Why does luatex fail/crash when font.each() is used. #3

u-fischer opened this issue Sep 25, 2018 · 11 comments

Comments

@u-fischer
Copy link
Member

See
https://github.com/u-fischer/luaotfload/blob/dev-2.9/bugs/factorbug.tex

(comments and links at the top). This is an extract from a part of the latex test suite.

With luatex 1.7 it gives "only" an lua error, luatex 1.9 crashes.

It should be documented how fonts can be accessed safely.

@zauguin
Copy link
Member

zauguin commented Sep 25, 2018

The problem is that the fontloader stores stuff in custom keys in the parameters table of the font.
This table is recreated whenever LuaTeX passes the cached font table to the user for example with font.each(), so the custom entries like factor are reset to nil.
I just suggested a LuaTeX patch to stop LuaTeX from resetting this stuff.
It would probably be a good idea to wait for responses there before handling this issue.

@u-fischer
Copy link
Member Author

A failing context example is

\starttext
  foo
  \ctxlua{for ii,vv in font.each() do end }
  bar
\stoptext

which gives the error

luatex warning  > node filter: error: ...ext/tex/texmf-context/tex/context/base/mkiv/font-otj.lua:408: attempt to perform arithmetic on a nil value (local 'factor')

@luigiScarso
Copy link

`%%% test.tex
Test:
\directlua{
local function recdump(k,v)
if type(v)=='table' then
print(" >>",k)
for k1, v1 in pairs(v) do recdump(k1,v1) end
else
print(" ",k,v)
end
end

for ii,vv in font.each() do recdump(ii,vv) end}
\bye
`
$> mtxrun --script plain test.tex
looks ok with latest beta.
Iirc, context doesn't use font.each.

@zauguin
Copy link
Member

zauguin commented Sep 26, 2018

This should no longer give an error with the current experimental LuaTeX code so I think we do not have to anything here and instead hope that the change makes it into LuaTeX 1.9.

@zauguin
Copy link
Member

zauguin commented Sep 28, 2018

@u-fischer I've seen you updated dev to add the font.each() overwrite from the fontloader.
Please also add font.originaleach=font.each before that to keep the original version available.
Otherwise we loose a way to enumerate all fonts including the ones not known by the fontloader.

@u-fischer
Copy link
Member Author

@zauguin I only pulled the files from context and would like to avoid to have to change them manually as it would get lost with the next pull. Is there a sensible place in init or main for font.originialeach=font.each ?

@zauguin
Copy link
Member

zauguin commented Sep 28, 2018

@u-fischer Sorry, I got the files mixed up and thought you copied some lines into luaotfload.

@luigiScarso The fontloader overloads font.each in a if context block and then uses the same code to overload the function for other formats. Is there a reason for this duplication? Especially for providing font.originaleach in ConTeXt but not in other formats?

@luigiScarso
Copy link

I only see luatex & context, and font.each was not used in context.

@zauguin
Copy link
Member

zauguin commented Sep 28, 2018

@luigiScarso I think my question was not clear enough:

Why is font.originaleach = font.each declared in font-ini.lua but not in font-mis.lua if both files overwrite font.each? I think in font-mis.lua it might be even more important because this file is used by non-ConTeXt code which might need the original font.each.

@luigiScarso
Copy link

better ask to the ml -- I am currently using an older version, 2018.09.25 14:14, and I cannot update.

@zauguin
Copy link
Member

zauguin commented Aug 26, 2019

Added originaleach in 57b819d.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants