Re: Unicode TTF question

From: Philippe Verdy (
Date: Wed Aug 24 2005 - 17:27:52 CDT

  • Next message: Philippe Verdy: "Re: Multi-lingual corpus?"

    From: "Eric Muller" <>
    > This is considerable work that has to be justified by the result: the
    > ability to create a single font that covers all of Unicode. Even if the
    > sixteen bit barrier was removed, the likelyhood of such a font to ever
    > exist is essentially nil; it is already the case that we do not have a
    > complete coverage of Unicode in any number of fonts. Furthermore, the mere
    > complexity of such a font would be close to intractable; certainly, it
    > would have many bugs for a long time, making it not too useful anyway.
    > Finally, there are other problems which cannot be addressed by a single
    > font, and more or less require some kind of font aggregation mechanism.
    > When you have such a mechanism, the need for a single font decreases
    > significantly.
    > So, yes, the limit can be removed, but the benefit is not worth the cost.

    I fully agree. It's best to have smaller fonts designed separately to give
    the best coverage of a single script (or of related scripts, such as
    Latin+Greek+Cyrillic), and then give to users a range of fonts for each

    There's a difficulty with the fact that most Asian fonts implement at least
    Basic Latin, or Latin-1, without covering the whole Latin script. This comes
    because those fonts contain special forms for halfwidth or fullwidth ASCII,
    which are typically used only in Asian ideographic or Hangul contexts with
    squared boxes.

    But the simple solution would be to map only those special (compatibility)
    forms in those fonts, and then exclude these Asian fonts for other encoded
    Latin text (including general punctations unless they are decently
    implemented in Asian fonts too).

    My opinion is that those Asian fonts should have ALL their Latin and
    punctuation characters removed, so that a renderer will not select those
    fonts for rendering only partial Latin text with them, and the rest of the
    text with another font designed for another script (the result looks

    Instead the renders should only have to select a single font for each
    script, without needing to mix several ones with distinct designs to cover
    the whole needed script range. It's then important that fonts that pretend
    to cover a range cover it fully, at least for a list of language (there may
    be additions later in the script range).

    Having fonts of small size will certainly help reducing the cost associated
    to their necessary upgrade when a script is extended.

    What I'd really like to have today is NOT a "pan-unicode" font, but good
    fonts with excellent typography for each script. I would really prefer to
    have a complete Latin font even if it does not fully support Greek or
    Cyrillic, then have another complete font for Cyrillic, then another
    complete one for Greek, and being able to design a document stylesheet with
    a preference order for fonts based on those script distinctions.

    It would really make the life easier for document authors. I don't need
    another Arial Unicode MS (still not complete and not updated as often and
    easily as we would wish). Instead I want an excellent Arial Latin, plus an
    excellent Arial Cyrillic, plus an excellent Arial Greek, plus an excellent
    Arial Arabic, and an Arial General (for punctuations, symbols, and digits,
    etc.. but not for letters), and so on...

    Then I want a authoring or viewing software that will allow selecting font
    preference effectively by script type, and replacing that font separately
    for a specific script for which I am not satisfied of the result (for
    example because it lacks some features or characters). To make this
    replacement possible at reasonable cost, the font must be small and easy to
    design and manage.

    Unfortunately, browsers are not prepared for that: even MSIE will not allow
    you to select font preferences for new scripts, because it seems to use an
    hardwired list of scripts, instead of consulting a registry of font
    capabilities, and the capabilities of the OTLS shaping engine (if a script
    requires to activate some OT features within some complex sequence before or
    after reordering...)

    And updates to Uniscribe are still very difficult ot have in reasonnable
    time, because it has a single source and cannot be extended by users
    themselves (Uniscribe is not open and remains proprietary). Unfortunately,
    lots of graphic device drivers only work with Windows GDI+ APIs to handle
    accelerated text, and GDI+ only knows Uniscribe.

    So applications have to redevelop all the rendering engine instead of just
    having to extend some system hook to override the shaping engine behavior
    for the graphics rendering they want to produce. The alternative is to use
    completely new shaping engines, and that's a quite large software installed
    twice on the host system.

    There should exist a way, in Uniscribe, to base almost all of its work on
    structured rules (we spoke about reordering, and that's effectively all that
    has to be extended by users, because the rest is described by font
    substitution and positioning tables), which should be accessible to
    applications (using a common "UniscribeProvider" API)

    This archive was generated by hypermail 2.1.5 : Wed Aug 24 2005 - 17:29:45 CDT