What I'd prefer is to have the "ot" engine to do purely OpenType Layout-based layout. No fallback at all. But then, there could be a "otfallback" engine which would use the OTL layout if OTL tables are present, but would resort to some fallback mechanisms if the tables are not present.
Alternatively, there could be a separate "fallback" engine that, in future, could be extended by, for example, doing some auto-placement of marks etc. Each engine could report back a boolean as to whether it "applies to" a given font, i.e. if it can be meaningfully used to shape a given font. The graphite2 engine could check for the presence of Graphite tables, and would then report True if found, otherwise False. The ot engine would do the same, same for the aat engine if it gets implemented. Passthru engines like coretext or uniscribe would always report True, I guess, as they're "black holes" in terms of such data -- unless they do in fact have some API that allows this type of query. The fallback engine would also report True. Then, optionally, we could have some way to specify a descending priorities list of engines to use as in "graphite2,aat,ot,fallback". HB would go through the list and use the engine that first reports that it "applies to" a given font. If the engine or list of engines is not provided, then HB should use a default priorities list, which incidentally happens to be, IMO, "graphite2,aat,ot,fallback". If a font has Graphite, AAT and OTL tables, most reasonable assumption is that the Graphite tables should be preferred. If a font has AAT and OTL tables, most likely AAT should be preferred. Both Graphite and AAT are more "specialized" engines, while OTL is more general. But the most important thing is that users should have the ability to just use the engine they specify, without fallback "creeping in" if they don't want it. Best, Adam Sent from my mobile phone. On 13.03.2013, at 02:08, Behdad Esfahbod <[email protected]> wrote: > On 13-03-12 03:10 PM, Khaled Hosny wrote: >> Hi Behdad, >> >> While comparing the fallback shaping ICU-based XeTeX with the >> HarfBuzz-based one, I noticed that ICU uses the Arabic Presentation >> Forms-A ligatures if the font have them unlike HarfBuzz. It is not a big >> issue (I don’t even have such font, I striped OT tables from fonts to >> test), but it would be nice to have. > > I'm not a huge fan of those, mostly because in Persian Naskh style they are > typically not desired. That said, changing the code to do it is trivial. I > already have it for all two-character ligatures. Extending it to > three-character ones takes another twenty minutes. > > But I'm not sure whether we want this. The size increment in the binary is > about 5k, which is not a big deal, but then I wonder whether I should start > adding build options to disable fallbacks. Or perhaps we build the best > engine first and wait till someone complains about size before we figure out > how to build smaller subsets. > > I'll go ahead and fix this. > > b > >> Here are the two fonts I tested: >> http://khaledhosny.org/files/tmp/kacstone-noot.ttf (no forms-A) >> http://khaledhosny.org/files/tmp/amiri-regular-noot.ttf (has forms-A) >> >> Regards, >> Khaled >> _______________________________________________ >> HarfBuzz mailing list >> [email protected] >> http://lists.freedesktop.org/mailman/listinfo/harfbuzz > > -- > behdad > http://behdad.org/ > _______________________________________________ > HarfBuzz mailing list > [email protected] > http://lists.freedesktop.org/mailman/listinfo/harfbuzz _______________________________________________ HarfBuzz mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/harfbuzz
