[mpeg-OTspec] Re: AHG conference call reminder

[Mikhail Leonov]

Ken,
On the family vs. face issue, the current Microsoft approach is to use font families for font mapping and fallback purposes (as opposed to font faces).

We believe that the number of font weight, slope and stretch combinations accessible through font selection interfaces makes it impractical to require a separate composite font for each of these faces. In practice, we see users adjust values such as font weight or slope separately from the font selection process, often at the individual word level, and the font family model works well for these usage patterns.

This model does require the platform to have a reasonable behavior for combinations that are not natively supported by the font faces. This behavior can be provided via emulation (synthetic emboldening or italicization algorithms) or approximation (choosing the closest font face in the family). Still, the problem is not intractable, and the implementation has quite a bit of flexibility here in selecting the closest reasonable combination that matches the font selection parameters. For example, the implementation can keep using the non-italicized character forms for scripts that don't have a well-defined concept of italic.

Best regards,
Mikhail

-----Original Message-----
From: Ken Lunde [mailto:lunde at adobe.com]
Sent: Wednesday, May 20, 2009 3:02 PM
To: Daniel Strebe
Cc: Mikhail Leonov; John Hudson; mpeg-OTspec at yahoogroups.com
Subject: Re: [mpeg-OTspec] Re: AHG conference call reminder

daan,

Well, that'll certainly keep things simple. Specifying the component font version then becomes a binary condition. The Composite Font author either doesn't declare this information, meaning that it is not important (to the author), or one or more component font versions are declared, and presumably the instance of the component font that the author is presently using is among the declared versions.

This then brings us to identifying component fonts. There are several things that potentially need to be identified. The most important is the name, and this starts off as being complex, because there are different levels.

One level is the notion of font family and its faces. A font family is usually composed of more than one face. But, there are plenty of single-face families. What makes this especially complex, if we want Composite Fonts to operate at the family level, meaning that it applies to all of its faces, is that there is rarely a one-to-one mapping between the faces of different families. As I already stated, some families have a single face. Some may have several dozen faces.

The two most common axes for faces, at least for Latin or Latin-like font families, are weight and whether the design is oblique or italic.
Not all font families have both axes. This is often script-specific.
For example, you will be hard-pressed to find italic versions of ideographs. To make things even more complex, many Japanese fonts may include italic versions of their Latin glyphs, which are accessible through the use of the 'ital' GSUB feature, typical Latin fonts implement the italic glyphs as a separate face of the font family, meaning as a separate font instance.

So, if we design this to operate at the font family level, things become exponentially complex, and probably pretty darn difficult to effectively encapsulate. The Composite Font implementations that we have developed have operated at the individual face level. This Composite Font format may need to do the same, unless someone can find a trivial way to express how a font family can be handled.

This then brings us to the second level of component font identification, which requires a unique string that is defined in the font. Filenames are not reliable, mainly because they are too easily changed. For sfnt-based fonts, the name clearly needs to come from the 'name' table. For non-sfnt fonts, I would argue that the PostScript name is the most reliable. If we want uniformity, then we should consider the PostScript name for all formats, and for sfnt-based fonts, this means the name.ID=6 string. Note that the PostScript name represents a face, not a family, which brings us back to the first level, which is the family versus face issue.

Regards...

-- Ken

On 2009/05/20, at 13:12, Daniel Strebe wrote:

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