On 9/26/2018 12:30 AM, Marcel Krüger wrote:
---- On Tue, 25 Sep 2018 23:26:10 +0200 Hans Hagen <j.ha...@xs4all.nl> wrote
----
> On 9/25/2018 9:33 PM, Marcel Krüger wrote:
> > Hi,
> >
> > while looking into a [luaotfload bug][bug] caused by the fontloader
> > being confused when LuaTeX overwrites the `parameters` in a
> > cached font table, I wondered why `write_lua_parameters` always
> > creates a new table instead of altering a potentially preexisting table.
> >
> > Changing this should lead to some small performance improvement
> > because Lua no longer has to create a new table every time a cached
> > font table is queried and more importantly it allows additional string
> > keys in `parameters` to be preserved.
>
> sounds more like an issue of luaotfload ... it should manage the
> parameters well
I do not think luaotfload is responsible especially because Ulrike Fischer
got a similar problem on ConTeXt with
\starttext
foo
\ctxlua{for ii,vv in font.each() do end }
bar
\stoptext
hm, we never use font.each in context
She proposed that the ConTeXt fontloader might benefit from overloading
`font.each()` similar to `font.getfont` if the engine should not be changed.
she hasn't reported an issue on the context list (yet)
In some personal experiments
local function fonteach_next(max, f)
repeat
f = f + 1
if f > max then return end
until font.frozen(f) ~= nil
usage and therefore freezing can happen out of order so you can miss some
return f, font.getfont(f) or font.fonts[f]
end
font.each = function() return fonteach_next, font.max(), 0 end
seemed to fix the problem.
i assume that you just want to run over fonts ... in that case i can
overload font.each in the context font loader (but different) in a more
efficient way than querying tex
> we're not going to change the current behaviour in the engine which is
> creating these tables (same for math constant etc) from mem (changing
> such things might solve your specific issue but introduce issues for
> others)
While I agree that keeping compatibility is important I do not really understand
how this would lead to issues.
Especially the parameters known to LuaTeX are still updated, so the only change
I can see here would be if someone relies on LuaTeX dropping some table
values...
Is there a problem I missed?
- why only parameters and not mathconstants, every character (which can
have subtables), and other properties
- why overload set values at the lua end with values at the tex end
(they can differe on purpose)
- better would be to set a metatable but that would add an extra lookup
chain every time one does font.each
- do you really want to use font.each and overwrite parameters with
maybe values different from what is expected at the other end (can have
fuzzy side effects)
- you probably loose way more than this one variable with font.each
- basically what font.each does is give you back what tex sees (which
can be way less than what lives at the lua end)
- so you solve one of your issues, then later another pops up (because
some other assumed value is not coming from the tex end, and within a
few years we have chaos in intercepts and heuristics
- the example of 'factor' not being in the tex parameters table is an
example of where usage can differ from stock tex usage
etc
Hans
-----------------------------------------------------------------
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-----------------------------------------------------------------
_______________________________________________
dev-luatex mailing list
dev-luatex@ntg.nl
https://mailman.ntg.nl/mailman/listinfo/dev-luatex
