A container to include Composite Font Representation XML and the component fonts

[Ken Lunde]

Suzuki-san,

This sounds like a very attractive option for font developers who specifically use CFR in order to break the 64K glyph barrier -- which is one of the design goals of CFR, and which started the whole thing -- and want to keep the CFR XML and the component fonts that it references in a single place, and to prevent them from becoming separated or distributed (in the sense of becoming separated).

When CFR is employed for the purpose of defining font-fallback behavior, the proposed ZIP-like container would have little or not benefit, at least in my opinion.

I, too, would like to hear others' opinions about this idea. I feel that it has merit, speaking in terms of a container format, and regardless of the format (such as ZIP), for the scenario that I described above.

Regards...

-- Ken

On Feb 24, 2012, at 8:05 PM, suzuki toshiya wrote:

> Dear SC29/WG11 font AHG experts,
> 
> I want to hear the comments about an idea of a ZIP-like container
> to include Composite Font Representation XML and the component fonts.
> Especially, it would be useful or not, it is meaningful to make some
> standards in ISO/IEC 14496 system or not.
> 
> For first, please let me describe a background. My understanding
> of CFR is following:
> 
> * a composite font described by CFR is expected to be looking as a single font.
> In other words, the user may expect that when a CFR XML file is passed to the system,
> a ready-to-use font instance will be returned without any preparation for the component fonts.
> 
> * CFR uses the PostScript name of the face as an identifier of the component font.
> 
> Thus, to provide the expected feature, the processor of CFR should
> have a modern font management system; that knows what kind of fonts are
> installed in the system, that can search and retrieve the data of the
> installed fonts by the PostScript name of the face.
> 
> I think some small systems does not have such modern font manager,
> some of them may identify the font by the pathname (if they have a file system)
> and search a font resource by PostScript name may cause huge works.
> 
> For such systems, using a container including CFR XML and component fonts
> might be a candidate of the option to reduce the cost to construct the
> composite font instance. If such container is useful, I think a ZIP-like
> container would be the candidate. It is now becoming a defacto standard
> around XML related field to pack the XML referrer and the referred data,
> as OOXML, ODF, EPUB. I heard that SC29/WG11 is also interested in the
> standardization of such format.
> 
> # although I prefer more legacy archive formats like AR, PAX, CPIO, TAR,
> # I'm sure that the promotion of them will fail.
> 
> But, there might be some viewpoints against using a container for CFR,
> something like, "Parsing CFR XML is already difficult for small systems,
> so packing the required resources in single container does not help them".
> 
> Please give me your comments about the idea "the container for CFR and its component".
> 
> Regards,
> suzuki toshiya, Hiroshima University, Japan