Re: Precomposed Glyphs

From: Peter Kirk (
Date: Sat Sep 25 2004 - 11:23:00 CDT

  • Next message: Peter Kirk: "Re: Unicode & Shorthand?"

    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 (personal) (work)

    This archive was generated by hypermail 2.1.5 : Sat Sep 25 2004 - 14:32:21 CDT