[mpeg-OTspec] Re: AHG conference call reminder

[Mikhail Leonov]

> 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.

Ken,
This sounds great - during the phone conference I wanted to make sure the intent of specifying the version is well defined, in the sense that Version="1.0" should specifically mean either == match or >= match, but not "it is up to the implementer whether to do the == or >= version match".

In other words, while the spec should not mandate how the font file versions are obtained from the component font files (since we are leaning toward being a font format agnostic format), it should say exactly how it should be matched against the version from the composite font for implementations that choose to interpret the version value from the component font files.

In practice, I believe allowing version ranges should be sufficient for all practical scenarios.
My suggestion is to have two optional floating point properties MinVersion and MaxVersion - one defining the minimum acceptable version of the component font, and another defining the maximum one. With these two properties, one can define open and close ranges in a flexible way:

All font versions: no version properties
Precise version match against 1.0: FontFamily = "MyFontFamily" MinVersion = "1.0" MaxVersion = "1.0"
Version 2.0 and newer: FontFamily = "MyFontFamily" MinVersion = "2.0"
Version 1.4 and earlier: FontFamily = "MyFontFamily" MaxVersion = "1.4"

Precise version match against 1.0 and 1.1: two entries:
<...
FontFamily = "MyFontFamily" MinVersion = "1.0" MaxVersion = "1.0"
.../>
<...
FontFamily = "MyFontFamily" MinVersion = "1.1" MaxVersion = "1.1"
.../>

Etc.

Does this sound flexible enough?

Another option is to allow for ranges inside the Version property, but then we need to come up with syntax for open ranges, which may increase implementation complexity.

On a related topic, WPF format allows for multiple comma separated fonts to be specified for the same Unicode range + language pair, but so far we've only discussed examples of FontFamily specifying a single font family only, and the introduction of the versioning and other font identification properties appears to make it more difficult to have more than one font family per Unicode range + language pair. Is there sufficient interest in allowing multiple font families per range + language entry, or are people comfortable with the simplicity of the 'one family per entry' rule?

Thanks,
Mikhail

From: mpeg-OTspec at yahoogroups.com [mailto:mpeg-OTspec at yahoogroups.com] On Behalf Of Ken Lunde
Sent: Tuesday, May 19, 2009 12:12 PM
To: Karsten Luecke
Cc: mpeg-OTspec at yahoogroups.com
Subject: Re: [mpeg-OTspec] Re: AHG conference call reminder





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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20090520/8c486ea3/attachment.html>