On Fri, Mar 18, 2011 at 02:58:23PM +0100, Hans Hagen wrote: > On 18-3-2011 2:42, Khaled Hosny wrote: > >On Fri, Mar 18, 2011 at 02:22:49PM +0100, Hans Hagen wrote: > >>Hi, > >> > >>For those with ftp access .. the new beta version there is somewhat > >>experimental as I rewrote some of the (lua) font code > >> > >>- alternative basemode definitions (context only, experimental) > >>- cleaned up node mode initialization > > > >No time for testing, but a suggestion I'd for a while: currently > >features supported in base mode need to be registered explicitly based > >on assumption that certain features tags will be used with lookup types > >supported in base mode. But in practice a feature tag can contain any > >lookup, e.g. I know fonts that use contextual alternates under 'liga' > >tag. My suggestion is to allow any feature tag in base mode and then > >check the actual type of the registered lookups (which might already be > >the case). > > this is somewhat tricky as basemode is a frozen approach: we set up > the ligatures once and no real analysis later on takes place > > indeed checking takes place so in principle any feature that has > ligature, alternate of substitution is dealt with; > > of course it's no problem to enable 'all' features in basemode, as > long as we let complaints about funny side effects go into the void; > i'll have to think about how to provide that variant efficiently
My real use case is that I've stylistic sets that I need to use in base mode (for math) but I need to manually register ss01..ss20 features in base mode first though they all are gsub_single lookups, so if context would simply check if the feature is gsub_single (or gpos_pair etc.) and reject it if not, it would be more efficient than hand picking certain features as the check will be done anyway. Regards, Khaled -- Khaled Hosny Egyptian Arab _______________________________________________ dev-context mailing list dev-context@ntg.nl http://www.ntg.nl/mailman/listinfo/dev-context
