RE: [unicode] CJK variation modifier

From: Philippe Verdy (
Date: Mon May 21 2007 - 18:48:17 CDT

  • Next message: Richard Wordingham: "Re: Order of Infrequent Combining Marks in Thai" wrote:
    > "Philippe Verdy" <> wrote:
    > > Is the OTC extension for Opentype able to handle such case, by creating
    > > in a single font file multiple fonts packed together, and crosslinked
    > > with an explicit fallback from one font to the other in the same pack?
    > Excuse me, OTC is the OpenType/TrueType Collection
    > described in OpenType specification v1.4? If so,
    > I remember, it doesn't mention anything about the
    > relationship among the faces included in same package
    > (if I'm wrong, please correct). In fact, Microsoft
    > had ever used TTC to pack independent faces (think
    > about Courier & Helvetica) into single file, for
    > Japanese and Korean markets. There might be requirement
    > to use OTC for 32bit glyph collection, but I don't
    > know if there's any movement for standardization.

    I spoke about OTC (or TTC) because it is backward compatible and would allow
    referring to a single font for drawing the legacy subset, while still having
    the possibilitily to refer to the other subet using the alternate font name.
    But with an extra (very small) table within each fontpacked into the
    collection, there would be the possibility to insert explicit font linking
    for ranges not covered in the current font in that collection; This small
    table could be inserted in each font part of the OTC/TTC pack.

    This way, the OTC/TTC fonts remain compatible, but there's a clean way to
    cover very large ranges, by splitting them into smaller sets, each one
    having the possibility of storing multiple variations (for example Japanese,
    or Korean or Traditional Chinese variants, enabled through the existing
    language feature).

    Font linking, performed this way within the fonts themselves would be much
    better than solutions implemented in code only in the system-specific

    Also, it allows sharing common designs for alternate styles without
    duplicating most of the collection (look for example at symbols: most of
    them can't be mapped safely to italic, or sometimes even to bold).

    Font linking instructions within font files is certainly something that will
    ease their installation and use. If this is not done, may be Opentype should
    create a new virtual font format that does not contain any glyph, but just a
    set of tables containing such font linking for some ranges (so the
    64K-limited fonts will remain to be installed separately).

    I am horrified about the way font linking currently works in common
    renderers, with hardwired code, and no place for extension for new scripts.
    This slows down the development and deployment of new scripts, based only on
    the way a few scripts are implemented in each OS version. I am convinced
    that all those hardwired rules implemented in renderers can be described in
    external tables, and so could be stored in font tables. If this is not
    possible, because that requires horrible tweaks in the way the Unicode code
    point stream must be prepared, then something is missing in the Unicode
    standard, namely: character properties.

    No renderer should have a prior knowledge about specific fonts for the
    system on which it was initially designed, given that even these systems
    will need to evolve and support larger subsets sooner or later, and still
    need to find some way to work for several years on other supported versions
    of these systems. If this is still true, I think this is bogous by design,
    due to lack of modelling and abstraction.

    And at least, it is very frustrating for font designers that can't sell
    their fonts (or need to create multiple masters, and experiment other
    problems like describing which font is appropriate for which user, and
    having to manage things like multiple licencing for the same font design in
    multiple master formats), and for users that can't buy and use them with the
    applications of their choice. In other words, this is a severe
    interoperability problem, something that industry standards like Unicode and
    OpenType are supposed to clean up.

    This archive was generated by hypermail 2.1.5 : Mon May 21 2007 - 18:50:34 CDT