![](https://secure.gravatar.com/avatar/46562c7d27388490d62e8d7a5bc960dd.jpg?s=120&d=mm&r=g)
26 Sep
2018
26 Sep
'18
2:51 a.m.
On 9/26/2018 12:30 AM, Marcel Krüger wrote: > ---- On Tue, 25 Sep 2018 23:26:10 +0200 Hans Hagenwrote ---- > > 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 -----------------------------------------------------------------