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

From: Sinnathurai Srivas (
Date: Fri Feb 08 2008 - 04:52:29 CST

  • Next message: ijdl linguistics: "Re: Character proposal: SUBSCRIPT TEN"

    My question was what is the criteria used to class a language as
    That requires complex rendering
    That requires no complex rendering.

    For example Tamil could easily be implemented without the need for any
    complex rendering
    However, Tamil is currently implemented using complex rendering.
    This was one of the main discussions and I have not seen a viable answer
    that catergorically states for such and such TECHNICAL reasons Tamil was
    made one that requires Complex rendering.

    My question was, mostly all proper publishing softwares do not yet support
    complex rendering. How many years since Unicode come into being?
    When is this going to be resolved, or do we plan on choosing an alternative
    encoding as Unicode is not working.

    As for bitmap, I meant the "Rigidly-fixed-width-character" requirements.
    At present, the complex rendering (which is not working yet in these
    systems) will produce extremly large width glyphs which will not be
    accomodated by "rigidly-fixedwidth- requirements. What is the plan to
    resolve this?

    Storage size was one issue, I also do not think, given the available
    technologies to deal with large size, this can not be the only reason why
    an encoding should change, but can be changed if there are other compelling
    reasons for change.


    ----- Original Message -----
    From: "John H. Jenkins" <>
    To: "Unicode Discussion" <>
    Sent: 07 February 2008 19:14
    Subject: Re: minimizing size (was Re: allocation of Georgian letters)

    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 : Fri Feb 08 2008 - 04:56:09 CST