[mpeg-OTspec] Re: AHG conference call reminder

[John Hudson]

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


-- 

Tiro Typeworks        www.tiro.com
Gulf Islands, BC      tiro at tiro.com

I'm like that Umberto Eco guy, but without
the writing.   -- anonymous caller