[mpeg-OTspec] Proposed mandatory and optional features of the Composite Font format

[Ken Lunde]

Mikhail,

You wrote:
> I would like to provide an update on mandatory and optional elements  
> in the composite font format.
>
> First, some background. During phone conference meetings that  
> preceded the formal creation of this working group, parties involved  
> concluded that, due to the diversity of font handling platforms and  
> programming interfaces in the industry, it was not practically  
> feasible to agree on a single predefined set of composite font  
> elements and properties that would express existing font selection  
> models and approaches. Instead, it was recommended to give composite  
> font producers and consumers flexibility to introduce optional  
> properties that wouldn't necessarily be used or even understood by  
> all conformant consumers. At the same time, semantics of such  
> properties should be defined as clearly as possible, so that an  
> implementation that chooses to suport them can do so in a way  
> compatible with other consumers and producers.
>
> In addition to such optional properties, there are core pieces of  
> the composite font format that conforming implementations must  
> interpret correctly to provide the minimum degree of interoperability.

Agreed on both points.
> The purpose of this email is to start creating a list of mandatory  
> and optional features in the composite font format.
>
> The format is assumed to be based on the latest composite font  
> syntax proposal uploaded to this AHG discussion list by Ken Lunde.  
> Since I don't recall us discussing the root element mandated by the  
> XML specification, I propose introducing a root element called  
> CompositeFont.
>
> Here is a complete composite font file that prescribes the consumer  
> to use font "Times New Roman" for all Unicode characters and all  
> languages:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <CompositeFont>
>     <ComponentFont Target="Times New Roman"/>
> </CompositeFont>
>
> I propose that a conforming composite font consumer must:
> 1. Recognize and parse basic XML structure as outlined above,  
> including the standard XML header and the root element CompositeFont.
>
Agreed.
> 2. Reject composite font files that violate the standard XML  
> specification.
>
Agreed.
> 3. Recognize, parse, and interpret all possible valid values for the  
> following elements and attributes (these elements and attributes are  
> furthermore called mandatory):
>
> a) ComponentFont element and its Target attribute. The  
> interpretation of the Target attribute value is allowed to vary  
> between consumers depending on the target environment font grouping  
> model. For example, a consumer may be using OpenType Preferred  
> names, Win32 names, Postscript names, WWS names, or some other font  
> selection model that may not even be OpenType based. However, the  
> consumer must use a font model that supports at least one font  
> format and assigns name values to font files that conform to  
> supported font formats. In addition, the consumer must parse comma- 
> separator characters that can be used to separate multiple font  
> names inside one Target attribute value, omit leading and trailing  
> whitespace characters from font name values, and honor the escape  
> sequence that encodes the comma character itself if it appears as a  
> part of the font name. I propose double comma ",," as an escape  
> mechanism for such cases.
>
With regard to the escape mechanism for a literal comma, specifically  
one that is not meant to be interpreted as a separator between  
multiple "Target" attributes, wouldn't "\," (backslash + comma) be a  
more standard way to represent this? (I cannot think of any fonts  
whose names include a literal comma, so this may not be an issue in  
practice.)

About the point itself, I would think that it would be prudent to to  
at least specify what names are recommended based on the font format.  
OpenType fonts, for example, must have a 'name' table, and the  
specification states the minimum requirements. For PostScript-based  
font formats, I would recommend the PostScript name, which specifies  
the family and face, meaning a specific instance of a font. Without  
heuristics, which should be avoided for a format such as this, I see  
no way to avoid this. At least, it makes OpenType fonts more  
attractive as Component Fonts. ;-)
> b) Encoding element and its Target and Original attributes. These  
> are described in Ken Lunde's email, and I won't repeat the semantics  
> here. Similar to the Target attribute semantics, the interpretation  
> of Unicode characters supported by a font may vary depending on the  
> target environment font model. For example, a consumer may prefer  
> one cmap table format to another. However, the consumer must use a  
> font model that provides an ability to obtain Unicode coverage for  
> all supported font formats.
>
Agreed. It may be prudent to specify that the 'cmap' subtable with the  
greatest coverage ("Full Repertoire" as opposed to BMP-only is the  
best example, and there are such fonts in the wild) is to be used.  
Again, for clarity.
> c) Language element and its Target attribute. I would like to change  
> the Target attribute values from the original definition provided by  
> Ken, which used ISO 639-2/T language codes, to a definition that  
> uses IETF language tags, as specified by RFC 4646. The key  
> difference is ability to differentiate between multiple character  
> sets for the same language, for example Simplified Chinese ("zh- 
> Hans") vs. Traditional Chinese ("zh-Hant"). The conforming  
> implementation must properly match language tags. There is a couple  
> of interesting corner cases here that I would like to discuss in  
> more detail - exact rules for matching language tags that are  
> related to each other, and handling of empty language tags and cases  
> where the language infomation is not available to the font selection  
> algorithm.
>
Agreed.
> 4. Reject composite font files that don't contain at least one  
> ComponentFont elements.
>
Agreed. This is the absolute minimum that a Composite Font must specify.
> 5. Interpret composite font elements in the order they appear in the  
> font file.
>
Agreed, but I would additionally state that the hierarchy that is  
specified in the Composite Font file be respected. I view order to be  
linear, so hierarchy is worth stating, for the sake of clarity.
> In addition to the mandatory elements and attributes described  
> above, there is a large group of elements and attributes that are  
> considered optional, such as scale, common baseline and height  
> metrics, the display name of the composite font itself, font style  
> coercion, digital signature enforcement, optical size, required font  
> version, font checksum validation, and others.
>
> Before drilling into exact syntax of such properties, I would like  
> to discuss one particular issue. I believe some of the optional  
> properties can be safely ignored by the composite font consumers  
> without breaking the intent of the composite font producer, while  
> other optional properties should cause the consumers unable to honor  
> their semantics to skip containing elements entirely. An example of  
> the former class is handling of Scale attribute of the ComponentFont  
> entry on platforms that don't support font scaling. An example of  
> the latter class is required font version range. If the consumer is  
> unable to extract a version from the font, then it is unable to  
> honor the producer intent, and a font entry should arguably be  
> skipped altogether. I propose that the composite font format should  
> contain provisions that enable consumers to tell whether  
> encountering an unknown attribute should cause the element it  
> belongs to to be ignored or not.
>
If we want to give the producer the ability to make specific  
properties mandatory, meaning that if the consumer is unable to handle  
them for whatever reason, I suggest that properties are to be  
ignorable by default, and that those that are mandatory be flagged as  
such. Thus, the Composite Font would be rejected by the consumer only  
if a property that has been flagged as mandatory could not be handled.  
Depending on the intent of the producer, we cannot predict what  
properties will be mandatory, so I don't think it is possible to  
specify this on a per-property basis. Forcing the producer to flag  
mandatory properties is the best way to make this intent clear.
> Please note that the proposals above are by no means final, and any  
> suggestions, corrections and additions are very welcome.
>

Many thanks for taking the time to send this email, and for keeping  
the discussions alive.

Regards...

-- Ken