[mpeg-OTspec] Re: AHG conference call reminder

Daniel Strebe dstrebe at adobe.com
Thu May 21 00:29:54 CEST 2009


With regard to names, I think this is another case where we do not need to be in the business of telling people how to say what they want to say. For my own purposes, I'd choose PostScript name under any circumstance I care about. But I don't pretend to know if that would suit everyone all the time, especially since (I think) there are extant formats that have no robust notion of a PostScript name. We should not need to involve ourselves in the Family versus Face/Style matter at all. I confess I did not followed the entire conversation that led us to think we might care explicitly about family names of component fonts.

Instead, perhaps we simply allow a recipe creator to inject whichever name string(s) it cares about into the recipe if it's an sfnt font. That way we don't end up imposing onerous character encoding requirements on the creator or consumer. Anyway, it is the creator who knows which namestrings are present in the font it refers to, not we. If the creator believes some particular language of namestring is the most useful for identification, then presumably the creator believes its audience for the recipe will be able to understand that language and encoding of namestring - at least to the extent of being able to examine the font for its presence and to compare equality. For other font formats we will have to carefully study what information is available and useful, and provide for those. We may end up making recommendations, but since it is hard to imagine a consumer could somehow understand instructions we dictate better than simply looking up whatever names the creator specifies, I have to think our recommendations would be geared much more toward helping ensure a successful fallback if the precise font is not found, rather than toward locating the precise font.

- daan

On 09/05/20 15:01, "Ken Lunde" <lunde at adobe.com> wrote:


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.


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

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

More information about the mpeg-otspec mailing list