As alluded to at the end of the May 9, 2012 CJK Type Blog article, I had plans to build additional CFR objects for testing purposes. That particular article supplied two 64K-glyph OpenType/CFF fonts, which provided BMP and Plane 1 coverage, and served as component fonts for the supplied CFR object, UnicodeGetaCFR.cfr. In today’s article, I will supply a CFR object that encompasses all of Unicode, meaning the BMP and the 16 Supplementary Planes, along with the component fonts that it references. In other words, coverage for 1,112,030 code points, each of which has a unique glyph. These represent valuable testing resources for developers who plan to support CFR objects in their products as a way to break the 64K glyph barrier.
The 17 component fonts supplied as part of this article, in addition to including 64K glyphs each, meaning CIDs 0 through 65534, also include 256 FDArray elements. (I like to push limits whenever I can.) All of the glyphs in each of the respective component fonts are the same, and are composed of glyphs for three Latin characters that represent an abbreviation for the portion of Unicode for which they provide coverage. The component font for the BMP, for example, includes 65,534 instances of the “BMP” glyphs (though 2,048 of them are not technically necessary due to the Surrogates), and those for the 16 Supplementary Planes include “P01″ through “P16″ glyphs, as appropriate. The combined screenshot below shows the last glyph, CID+65534, in three of the 17 component fonts:
The 17 component fonts are UnicodeBMP.otf, UnicodeP01.otf, UnicodeP02.otf, UnicodeP03.otf, UnicodeP04.otf, UnicodeP05.otf, UnicodeP06.otf, UnicodeP07.otf, UnicodeP08.otf, UnicodeP09.otf, UnicodeP10.otf, UnicodeP11.otf, UnicodeP12.otf, UnicodeP13.otf, UnicodeP14.otf, UnicodeP15.otf, and UnicodeP16.otf. The CFR object that references all 17 of these component fonts is UnicodeCFR.cfr.
Although the 17 individual OpenType/CFF fonts, which serve as component fonts for the CFR object, can be used independently, a CFR-savvy OS, text engine, or application should be able to handle all of the component fonts together via the CFR object. This means that one can create a text file with all 1,112,030 code points of Unicode, and as long as the environment is CFR-savvy, all code points should be rendered.
Stay tuned to this blog for additional example CFR objects.