[mpeg-OTspec] Re: AHG conference call reminder

[Daniel Strebe]

If I may weigh in, I think we should carefully consider any actions that require us to arbitrate the conversation between the creator and consumer of the composite font recipe. In this context, I recommend against providing semantics for ranges of version numbers, for several reasons.


 1.  As has been pointed out, there is no such thing as "the" version of the font except as defined by a digital signature or checksum. We can't be in the business of deciding ex post facto what the various version fields mean or don't mean or how to parse them or what ranges might mean when a font comes with several different ways of announcing its version.
 2.  With the notable exception of type foundries themselves, composite font creators simply will not have any clue what versions of fonts might be meaningful to their enterprise. They only know what version they are working with at the time they construct the recipe, and therefore they could only want to embed version information about that one font they know about. Conversely, if it's a foundry involved, then the foundry may simply enumerate EVERY version it knows to adhere to the semantics it cares about. (Obviously any creator could, if they know about it.) That hardly seems onerous, and certainly much easier than our having to regulate the MEANING of versions and ranges and how to parse them in the face of existing inconsistencies.
 3.  Glyph changes are normal from version to version - that's often why there's a new version. It is hardly likely that some range of versions (if we could even decide what that means) would be of much use in most contexts.

Given these considerations, I recommend that were merely provide semantics for the creator to identify acceptable font versions, replicated however many times the creator needs in order to certify each version it knows to conform to its needs. The creator is free to use the version string, the version field, the DSIG, or a checksum, as the creator sees fit. This recommendation keeps us out of any messy business of any kind, allows the creator to state exactly what it intends, does not presuppose any kind of conformance or consistency on the part of the constituent fonts, and maintains our purpose as a conduit of information but not its judge.

Regards,

- daan Strebe
Senior Computer Scientist
Adobe Systems Incorporated


On 09/05/20 12:41, "Mikhail Leonov" <Mikhail.Leonov at microsoft.com> wrote:






John,
I agree that there are discrepancies in how implementations deal with the font version numbers.

However, I believe we can deal with this situation in the same way we dealt with the cmap table format situation - while mismatches are possible, there is only one intended version value to be extracted from the font, and successful font format implementations will do their best to obtain it even in the presence of redundant or conflicting data. In practice, many implementations end up preferring a parsed version value from the OpenType 'name' table, but the composite font spec should not get in the business of resolving practical conflicts in the font formats. If the composite font creator is really sensitive to the version matching across different platforms, they can specify both 'head' and 'name' versions as entries. The same approach of creating extra entries for alternate versions could work for the second issue you brought up - font family names.

There is another interesting issue here of conflicting version numbers in the font faces that comprise the family. We can perhaps come up with the recommendation on this, as the choice seems independent of the particular font format. I can see the maximum font face version number or the dominant version number as reasonable choices, although I personally lean toward the maximum value approach as it enables font vendors to revise a font family by updating only one font file instead of all of them.

Mikhail

-----Original Message-----
From: mpeg-OTspec at yahoogroups.com <mailto:mpeg-OTspec%40yahoogroups.com>  [mailto:mpeg-OTspec at yahoogroups.com <mailto:mpeg-OTspec%40yahoogroups.com> ] On Behalf Of John Hudson
Sent: Wednesday, May 20, 2009 12:18 PM
To: mpeg-OTspec at yahoogroups.com <mailto:mpeg-OTspec%40yahoogroups.com>
Subject: Re: [mpeg-OTspec] Re: AHG conference call reminder

Mikhail Leonov wrote:

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

That would be entirely reasonable, but it does raise the issue of where in a component font the version number comes from.*

In a TTF or OTF, there is a version string in the name table and a font revision number in the head table. In well-made fonts these will both be well-formed and will match each other. In practice, the font revision number is often not updated when changes are made in a font, since the changes may involve tools that do not update this head table data, so the head font revision number falls out of sync with the version string.
The version string itself often does not conform to the recommended format, and may contain additional information in an order that obscures the version number. Further, Microsoft's recommendations for version string formatting differ considerably from the version string format generated by Adobe's FDK.

Regards, John

* As part of a higher-level discussion, this relates to the question of where in a component font the name comes from.

> 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%40yahoogroups.com>  [mailto:mpeg-OTspec at yahoogroups.com <mailto:mpeg-OTspec%40yahoogroups.com> ]
> *On Behalf Of *Ken Lunde
> *Sent:* Tuesday, May 19, 2009 12:12 PM
> *To:* Karsten Luecke
> *Cc:* mpeg-OTspec at yahoogroups.com <mailto:mpeg-OTspec%40yahoogroups.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 o ff" 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 o pinion 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 repres ents 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/f7ee9bdf/attachment.html>