[mpeg-OTspec] Re: AHG conference call reminder

Ken Lunde lunde at adobe.com
Tue May 19 21:11:53 CEST 2009


As I indicated earlier today, I am CCing the AHG mailing list to this  
reply, so that the rest of the group can benefit.

> regarding the versioning discussion:
> In his earlier mail of 24.2.2009, "RE: [mpeg-OTspec] AHG on Open Font
> Format kick off" Mr Leonov mentioned,
> (2) Versioning, which as I understand describes the version of the
> composite font format itself (is it?) and

We did not discuss the versioning of the Composite Font itself in  
yesterday's telephone meeting, though this is something that will need  
to be covered at some point. For what it's worth, I feel that  
Composite Font definitions should include a version number. There will  
be times when the author will want to revise the definition, in which  
case the version should be incremented.

> (3) Name of the composite font.

We discussed this very briefly, and agreed that while the Composite  
Font can have a name, it is not required. It is to be used to display  
the Composite Font in application font menus. If the Composite Font is  
not to be used by applications, the lack of a name becomes useful.

I brought up the issue of uniqueness. Enforcing uniqueness is tough,  
and my opinion is that the best policy is that if there is a name  
conflict, between a Composite Font and another font that is accessible  
by the client, the "real" (non-Composite Font) one should win.

> Now Mr Suzuki's and John's remarks suggest that there be
> (3b) the version of this particular (xml) composite font
> which may be a good idea, if only for the producer.

That discussion involved specifying the version number of the  
component fonts, not the Composite Font itself. It was about different  
levels of specifying the component fonts. The basic level is by name.  
Including the version number (or version numbers, expressed as an  
array of numbers, or as a range) is more sophisticated, and specifying  
DSIG information is still more sophisticated. Again, this is not  
required, but should be possible.

> And then, why not also specify (current) versions of associated  
> fonts in
> the composite font definition too? It is duplicate information, yet
> would allow checking if associated fonts' version numbers match the
> respective version numbers as declared in the composite font  
> definition.
> (If an associated fonts' version numer is less than defined in the
> composite font, it may cover fewer characters than indicated in the
> composite font, if it is larger, then it may cover more. Emphasis on
> "may".) So a font manager could quick-check and report that associated
> fonts are older than specified in the composite font and may not match
> the meta-information given in the composite font.

That is precisely what we were discussing during yesterday's telephone  
conference.  The Composite Font author can specify the version number  
of the component fonts. We discussed only specifying single version  
numbers, but there's no reason why there cannot be flags to indicate  
that it represents a minimum value, meaning that greater versions are  
considered valid. There may even be circumstances that require that  
one specifies a maximum version number. In any case, this will need to  
be rather flexible and rich.

> From the phone-call report:
>> Should at least one Unicode based CMAP be mandated
>> No, Unicode mapping should not be a requirement
>> but a font engine should be able to map Unicode code
>> points to internal font character mapping table
> What does this mean in practice, would mandatory use of cmap hurt some
> font formats? Why not mandate a cmap? I wonder if mandating a cmap  
> would
> simplify things a bit because that's a clear statement as to where to
> look for character-glyph mapping info. (Different cmap table formats  
> are
> is enough diversity already.)  :)

There is a big difference between mandating a parameter or other  
information, and whether it is a good idea to include or specify it.

The more information that a Composite Font author includes in its  
definition, the greater the chance that the Composite Font can be used  
by more consumers. Some Composite Fonts will be used in limited or  
closed environments, and it would be wrong to presume that this  
information is necessary. The important thing from the specification  
perspective is that a Unicode mapping can be specified, if the  
Composite Font author desires.


-- Ken

More information about the mpeg-otspec mailing list