Re: [unicode] CJK variation modifier

Date: Mon May 21 2007 - 08:34:49 CDT

  • Next message: Gerrit Sangel: "Re: [unicode] CJK variation modifier"

    On Mon, 21 May 2007 12:56:07 +0200
    "Philippe Verdy" <> wrote:

    > wrote:
    >> Gerrit Sangel <> wrote:
    >> >If there were a way to store the information about
    >> >the variation of the character in the text itself,
    >> >I think, it would be possible to create a font
    >> >to include all CJK characters?
    >> To include all CJK characters including glyphs for each
    >> language, the number of glyph will be greater than 64k
    >> (the size of CJK Unified Ideographs (inc. all Extensions)
    >> is almost about 64k - if we collect non-unified variants
    >> for CJKV, the number must be greater than a few times of
    >> 64k). They cannot be packed into single TrueType/OpenType
    >> font which has limitation of 64k glyphs. You will have
    >> to implement new font format of larger character collection
    >> and rasterizers, text render etc etc. I guess it is not
    >> what you want.
    >Given that the newer extensions for CJK ideographs will be introduced, how
    >can a complete font for CJK be defined as it will need more than 64k
    >characters even when storing a single variation?

    I think so. For example, SURSONG.TTF of OfficeXP
    for PRC market included 65530 glyphs (upto Ext. B),
    it's impossible to insert Ext. C1 glyphs into there.
    However, I'm not sure if the complete coverage of
    CJK Unified Ideographs is seriously required.
    Japan national body had registered the subset coverage
    for Japanese market to ISO 10646, although it's
    arguable whether it's really sufficient for Japanese
    market. I wish if other CJK national body defines
    the subset coverages for their market, to fit 16bit
    glyph collection :-).

    >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.

    >If such extension is used, doesn't it help reduce the impact of the 64K
    >glyph limitation and then allowsstoring multiple variants?

    I'm sure it reduces the impact, but I'm not sure
    if it's the best solution. Repeated switching of
    the faces (from BMP face to SMP face, from SMP
    face to BMP face, from...) can be some impact for
    the system missing intelligent font cache.

    >Or will it require changing the table formats for extendong the internal
    >binary storage size for glyph id's?

    I wish if we had real 32bit font format. But, at present,
    the requirement of 32bit glyph collection in single font
    is too small to invent new 32bit font format, I guess.


    This archive was generated by hypermail 2.1.5 : Mon May 21 2007 - 08:39:19 CDT