---- On Wed, 26 Sep 2018 10:51:57 +0200 Hans Hagen <j.ha...@xs4all.nl> wrote 
---- 
 > 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 
 > ----------------------------------------------------------------- 
 > 


_______________________________________________
dev-luatex mailing list
dev-luatex@ntg.nl
https://mailman.ntg.nl/mailman/listinfo/dev-luatex

Reply via email to