Re: minimizing size (was Re: allocation of Georgian letters)

From: John H. Jenkins (
Date: Thu Feb 07 2008 - 13:14:31 CST

  • Next message: Otto Stolz: "Re: On a lighter note, xkcd"

    On Feb 7, 2008, at 11:06 AM, Sinnathurai Srivas wrote:

    > There is also this question, when is it feasible to introduce
    > complex rendering and when it is feasible not to introduce complex
    > rendering. Do we have a cut-over point, such as character counts or
    > any such criteria?

    Ultimately, almost all scripts in Unicode require complex rendering
    for typographically correct layout. Even a brain-dead (display-wise)
    language like English needs ligatures. Unicode was designed with
    complex layout in mind.

    Of course, some scripts can't be displayed at *all* in a reasonable
    fashion without complex layout. Typically these are scripts where the
    glyph shapes used for characters regularly change in a contextual
    fashion or where ligation is required in almost every word, let alone
    scripts where the linear display order of glyphs doesn't match the
    pronunciation order of the sounds in the words.

    Character count is irrelevant, since the Han script has by far the
    largest repertoire but is one of the simplest scripts in terms of
    layout (although, to be honest, reproducing some older Chinese texts
    will require the use of ligatures). It's simply a matter of how the
    *visual* form of the text fails to represent the *letters* of the text
    in a non-varying way.

    The waters have been muddied by improvised solutions imposed by older
    character sets. Users of MacRoman, for example, got used to typing an
    explicit fi and fl if they wanted them rather than letting the
    rendering engine decide, and Arabic got a large number of
    compatibility forms added to allow for minimally acceptable Arabic
    display on systems which can't change glyphs contextually. This kind
    of approach simplifies the problem of *drawing* the text, yes, but it
    makes almost every other process (searching, sorting, and so on) much,
    much more complex.

    > When is this complex rendering non-working situation going to
    > change. Particularly in Publishing. I think primarily, the scripts
    > need support for publishing rather than applications or web
    > applications though these are important too. When is the problem
    > inherent to publishing using Unicode-complex rendering going to be
    > resolved. Is it time to think of redesigning the encoding itself or
    > do we wait for a few more years?

    It depends on the software you're using and the platform you're on.
    Word on Windows can handle most of Unicode without problems. Pages on
    Mac OS X can do everything in Unicode. InDesign currently is aimed at
    the rendering requirements for Western and East Asian languages, but
    I'm sure that Adobe has plans to expand this.

    > Finally, when will we be even consider the phenominan of bitmap
    > characters in Unicode? (Hand held or giant machinery!)

    I'm not sure what this question means, since "bitmap" refers to a
    style of glyph (which Unicode doesn't deal with), and not a
    character. Do you mean bitmap fonts that can be used to draw
    Unicode? That problem has been considered and dealt with, at least
    for TrueType/OpenType, since they support the use of bitmap glyphs in
    the font file and have supported it for years.

    John H. Jenkins

    This archive was generated by hypermail 2.1.5 : Thu Feb 07 2008 - 13:17:19 CST