Born from the conclusion that OpenType’s 64K glyph barrier cannot be broken in the context of the format itself, ISO/IEC 14496-28:2012 (Composite Font Representation) was developed, and was subsequently published three days ago, on April 17, 2012, as a new ISO standard. As described in the January 26, 2012 CJK Type Blog article, CID-keyed fonts can include a maximum of 65,535 glyphs (CIDs 0 through 65534). Considering that Unicode Version 6.1 includes over 100K characters, with approximately 75K of which being CJK Unified Ideographs, it becomes immediately apparent that a single font resource cannot support all of Unicode, let alone all of the characters for a single script (referring to CJK Unified Ideographs).
ISO/IEC 14496-28:2012 defines an XML format for representing composite fonts and fallback fonts, both of which can be implemented by defining a CFR (Composite Font Representation) object.
Composite fonts are generally used for authoring purpose, either to (virtually) extend a font resource with additional component fonts, or to (virtually) replace existing glyphs with those that are referenced in a different font resource. In the context of Japanese, it is common for legacy composite font implementations to replace the glyphs for kana with those of a different font. This is based on the premise that typical Japanese text includes more kana than kanji, and changing the kana can significantly alter the look and feel of the text.
Fallback fonts are used to display glyphs for a maximum number of code points, by selecting among various font resources, either by simple terms, such as a prioritized list, or more carefully by specifying fonts for particular code point ranges. Web browsers are ideal consumers of fallback fonts. Fallback fonts generally have less fidelity than composite fonts. Then again, the scope of composite fonts is generally more narrow, and composite fonts can serve as one of the component fonts in a fallback font.
Both composite fonts and fallback fonts have the potential to reference more than 64K due to the referencing of multiple font resources, each of which is limited to 64K glyphs.
Of course, publishing the ISO standard represents only the first step. The next steps involve establishing support for CFR in various places, ideally to replace existing composite font and fallback font implementations, almost all of which are proprietary. CFR has great potential in the cloud and for social media, mainly because it represents an interchange format for composite fonts and fallback fonts.
Although the text of this standard cannot be provided here, due to obvious copyright reasons, I can provide its DTD for those who are interested in examining it. For those who use Mac OS X, I would like to point out that CFR is largely based on Apple’s SplicedFont format, whose DTD can be found in /System/Library/DTDs/SplicedFont.dtd on the filesystem of that particular OS.
Comments
Instead of releasing a updated version of the font format spec, they created a new wrapper file format to solve the problem. What’s in their mind? It’s not like the “new” solution can be used to solve the aging problem without updating all the font drivers out there.
We still need to update all the font drivers either with a new version of OTF spec or with this wrapper of font files.
There’d better be a update OTF spec in the future to address the accumulated limitations people uncovered since the 1st version of OTF spec was released.
Are they expecting OTF 1.0 format last forever? What’s the version field in the SFNT header for? FUN? I guess it is year 2012 already, there might not be 2013 as the movie predicted. Who need a new version of a font spec which will only last for less than one year.
Revising the OpenType specification was indeed considered as part of this process, and in the end it was deemed to be far easier to standardize and implement CFR. Also, I should reiterate that CFR brings to the table two things besides the ability to break the 64K glyph barrier, neither of which are supported by OpenType proper: composite fonts and fallback fonts. Currently—at least before CFR—there is no standardization for these formats, with all such implementations being effectively proprietary.