Re: Precomposed Glyphs

From: Christopher Fynn (cfynn@gmx.net)
Date: Sat Sep 25 2004 - 09:16:10 CDT

  • Next message: Philippe Verdy: "Re: [OT] Decode Unicode!"

    Mike Ayers wrote:

    > In most sectors, the answer is "not anymore". However, the ability
    > to programatically assemble glyphs instead of using precomposed glyphs,
    > assuming that this requires less resources, would be very desireably in
    > embedded consumer applications (organizers, phones, etc.) where cost savings
    > are at a premium. Some programmatic support already exists, but I think
    > that we are a few generation's worth of research away from, say, the 13
    > glyph Chinese font. For the meantime, following the path of precomposed
    > glyphs makes the most sense.

    Programatically assembling glyphs at run time from a small library of
    components is often not very efficient since it can result in numerous
    calls to the layout engine, instead of a single substitution lookup. If
    you can make glyphs from a small number of components at run time then
    you can also pre-assemble and pre-position those same components in
    *composite* glyphs. With this approach you only have the same number of
    actual outlines in your font file as in a font where the parts are
    assembled, positioned and sized at run time.

    Of course this approach does not give the end user quite the same
    flexibility to productively generate new combinations. But productive
    generation is not possible anyway if the necessary lookups are not there.

    > I should also point out that Peter, like many advocates of glyph
    > composition, seems to believe that this would be an easier path. This would
    > probably be true in the end, but along the way is much, much more work.
    > Ironically, part of that work would probably include assemblage of the very
    > database of precomposed glyphs that he argued against - so that the data for
    > composition of each individual composed glyph (deformation, position,
    > magnification, etc.) can be generated and checked. Yes, it would be a
    > monumental achievement, but a pretty cool one, all said and done.

    You are right about all the work required and the necessity of some kind
    of database.

    Yes the results would be "cool" - but when you do this it turns out that
    viewing and reflowing large documents in a WYSIWYG application slows to
    a crawl - and it can end up that where the correct ligatures not formed
    as fast as the underlying characters are typed typed in which is
    particularly disconcerting for the user. As you infer with a really
    complex script and a large glyph repertoire to be generated, the number
    and complexity of the lookups would takes a huge effort and makes a font
    very complex to test, debug and maintain. In practice this only ends up
    limiting the number of fonts available for a system and increases the
    cost and difficulty of development and ultimately paid for by the end
    users.

    When you try to reduce the number of component parts to a minimum it is
    also very easy to end up making sacrifices in terms of design.

    - Chris



    This archive was generated by hypermail 2.1.5 : Sat Sep 25 2004 - 09:20:38 CDT