[mpeg-OTspec] Re: AHG conference call reminder
Ken Lunde
lunde at adobe.com
Tue May 19 21:11:53 CEST 2009
Karsten,
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.
Regards...
-- Ken
More information about the mpeg-otspec
mailing list