In the April 20, 2012 CJK Type Blog article, I wrote about the publishing of ISO/IEC 14496-28:2012 (Composite Font Representation), which provides a venue for breaking the 64K glyph barrier that is inherent in all sfnt-based font formats, including name- and CID-keyed PostScript fonts. If the number of glyphs of the combined component fonts that are referenced by a CFR object exceed 64K, would constitute breaking the 64K glyph barrier.
For developers who are interested in adding support for CFR objects in their OS, application, or text engine, I created a simple CFR object, UnicodeGetaCFR.cfr, that references two (CID-keyed OpenType/CFF) component fonts, UnicodeGetaBMP.otf and UnicodeGetaP01.otf, both of which include 64K glyphs (65,535 glyphs, meaning CIDs 0 through 65534).
The UnicodeGetaBMP.otf component font includes 65,534 instances of the same glyph, specifically that of the geta symbol (U+3013 〓 GETA MARK; written 下駄 in Japanese), and maps all 63,486 BMP code points (U+0000 through U+D7FF and U+E000 through U+FFFD) to a unique CID. Below is a screenshot of the glyph for CID+65534:
The UnicodeGetaP01.otf component font also includes 65,534 instances of the same glyph, though to distinguish them from those in the UnicodeGetaBMP.otf component font, they have been rotated 90 degrees. This component font maps all 65,534 Plane 1 code points (U+10000 through U+1FFFD) to a unique CID. Below is a screenshot of the glyph for CID+65534:
The CFR object, UnicodeGetaCFR.cfr, registers itself as a font named UnicodeGetaCFR, and specifies UnicodeGetaBMP.otf and UnicodeGetaP01.otf as its component fonts. Although not necessary for this particular example, the CFR object explicitly uses the <UnicodeCharSet> element to specify the Unicode ranges of each component font.
I plan to develop additional CFR objects that exercise other aspects of ISO/IEC 14496-28:2012, which will be made available in future CJK Type Blog articles.
Comments