On 25/09/2004 15:16, Christopher Fynn wrote:
Peter Kirk wrote:
I should point out in return that I am not advocating glyph composition for CJK-type scripts, but for scripts like Hebrew in which fairly simple positioning rules can be used, rules which have already been successfully implemented in OpenType fonts like SBL Hebrew.
For scripts where the composition rules are particularly complex and where you need to apply a lot of contextual positioning rules in order to build up ligatures, there is often a considerable performance disadvantage when compared with a font that has pre-composed ligatures instead.
Chris, you seem to have missed the point that in Hebrew there is no predefined list of possible combinations, but an open-ended set. Well, in principle the set is not totally open, but there are tens of thousands of possible combinations, many of which are not in fact attested in any known texts - but may be found quite legally in a text which someone decides to write next week. (Well, in fact almost no one writes new texts with accents, but they do discover and transcribe textual variants of old ones with accents.)
A font with pre composed ligatures is also not necessarily that much larger since you can often implement many of the glyphs as composite glyphs made from a library of component glyphs. (In other words pre-positioning & combining the parts.) Since the component glyphs are effectively subroutines and composite glyphs have pointers to their components file size is reduced.
Well, surely in practice this comes to very much the same thing as composing glyphs on the fly from components, using attachment points to specify the positioning - which is what OpenType currently does. Or would the difference be something like the following set of mappings?
<e, acute> => <e, low wide acute> <E, acute> => <E, high wide acute> <i, acute> => <dotless i, low narrow acute> <I, acute> => <I, high narrow acute>
Including a lot of positioning rules for rarely if ever used combinations may not be a good idea. If you add a feature to an OpenType font then it seems a call is made to the layout engine for that feature for each cluster of text - even if it turns out that the feature does not apply or is not used for that cluster of text. The more features you have, the more calls are made. So there is a trade off between features and performance.
Well, if this is really how OpenType engines are designed it is very poor design. A special function for a rare combination of characters should be called only when that combination is encountered, i.e. rarely, and so the performance hit should be small. But not implementing positioning rules for rare combinations is unacceptable, because such combinations actually do occur and so need to be supported in a comprehensive solution for a script.
What you are proposing sounds rather like a solution for rendering English which selects the so many thousand commonest words and renders them as complex glyphs, and decides that all other words are "rarely if ever used combinations" which don't need to be supported at all. I don't think that would ever be acceptable for rendering of a script and language in which words are built up from clearly distinct graphical units - even though in practice this kind of approach might be necessary with Chinese.
In current layout engines, substation lookups seem to run *much* faster than positioning rules - and it is usually easier to group many substitution rules into a single feature, than it is to group positioning rules - so less features are required resulting in fewer separate calls to the layout engine.
I can see that it might make sense, for performance reasons, to include in a font substitution rules for certain common (at least in some languages) combinations, e.g. <e, acute> (assuming this is being rendered from NFD). But that does not imply a necessity to delete from the font generalised positioning rules to cover combinations for which there is no specific substitution rule.
-- Peter Kirk [EMAIL PROTECTED] (personal) [EMAIL PROTECTED] (work) http://www.qaya.org/
