On 2014-03-31 Hans Hagen wrote: > On 3/31/2014 7:42 PM, Jan Tosovsky wrote: > > On 2014-03-31 Hans Hagen wrote: > >> On 3/29/2014 7:51 AM, Jan Tosovsky wrote: > >>> On 2014-03-28 Hans Hagen wrote: > >>>> On 3/28/2014 7:23 PM, Jan Tosovsky wrote: > >>>>> > >>>>> Btw, has anybody any idea where the following 'dotlessi' patch > >>>>> has been lost? > >>>>> > >>>>> http://www.ntg.nl/pipermail/ntg-context/2013/076306.html > >>>>> > >>>> might be that i can cook up a version at the context end (like an > >>>> overload) > >>> > >>>> From my POV the font handling is a very low level part and should > >>>> be kept in luatex... > >> > >> we're talking of heuristics for determining glyphnames when not > >> present and that is a real messy thing ... in fact, better would be > >> to keep all that at the lua end (easier to overload) and eventually > >> that might happen (it's quite hard to fight frozen invalid properties) > >> > > > > My only wish is to automate it and distribute out-of-the-box without > > any additional tweaking and interventions from end users. > > > > I understand that hardcoding it into LuaTeX may be risky, but if done > > properly according to the logic of other font libraries/typesetting > > software, it could be more efficient. As LuaTeX can be theoretically > > used by various macropackages, it means all of them would have to > > implement the same thing separately. > > the problem is that when hardcoding is based on fuzzy logic one looses > information to get back to the original .. a trade of between user > friendliness and perfection > > a specific usage overload (e.g in a context setup) will not harm oither > users with different demands >
It makes sense. You know much better possible consequences. > the only robust solution is not to use glyph names in lookup > definitions but indices (glyph names are only useful for tracing and > tounicode) > > anyway, as said: i'll look into it later this year but the current > binary stays as it is Ok, thanks. Jan
