---- On Wed, 26 Sep 2018 10:51:57 +0200 Hans Hagen
On 9/26/2018 12:30 AM, Marcel Krüger wrote:
[...] 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
RIght, but it is only comparing to nil so it shouldn't check if the font is frozen, it is just used as a way to check if the font is valid.
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
That would certainly fix the original problem but I still think that it would be nicer to change the engine here. Keeping almost everything in cached font tables except for the parameters table seems counterintuitive.
[...]
- why only parameters and not mathconstants, every character (which can have subtables), and other properties
- 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
This is only about cached font tables. The code handling them is `font_to_lua` is if (font_cache_id(f) > 0) { /*tex Fetch the table from the registry if it was saved there by |font_from_lua|. */ lua_rawgeti(L, LUA_REGISTRYINDEX, font_cache_id(f)); /*tex Font dimenensions can be changed from \TEX\ code. */ write_lua_parameters(L, f); return 1; } So AFAICT the table is not modified (and no entries are lost) except by `write_lua_parameters`. So I only want to change the handling of `parameters` because no values are lost in the other fields.
- why overload set values at the lua end with values at the tex end (they can differe on purpose)
- 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)
I am not sure what you mean here. But I think it makes sense to reflect changes in the TeX font parameters in the Lua table. I would think that everyone who uses the font parameters table expects the values to conform to the font dimensions in TeX.
- better would be to set a metatable but that would add an extra lookup chain every time one does font.each
I think an extra lookup would be a small price to pay if the alternative is that font.each is effectivly useless.
- the example of 'factor' not being in the tex parameters table is an example of where usage can differ from stock tex usage
I think this is more an argument to not change the parameters table at all. Especially *because* the usage of the table can differ from stock TeX usage it makes sense not to drop unknown entries. Best regards Marcel
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 -----------------------------------------------------------------