Re: [Dev-luatex] Preserving unknown keys in cached font table

On 9/26/2018 12:30 AM, Marcel Krüger wrote:
>   ---- On Tue, 25 Sep 2018 23:26:10 +0200 Hans Hagen  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
-----------------------------------------------------------------