[mpeg-OTspec] Re: Proposed mandatory and optional features of the Composite Font format

[Levantovsky, Vladimir]

I think it is always a possibility for producer to either introduce a custom element or an attribute. It may be intended to be used and understood only by a particular consumer, but there is no way other spec-compliant consumers would be able to act on this information. Indicating that this unknown custom property is "mandatory" doesn't help to interpret it - its meaning is still unknown.

Vladimir


> -----Original Message-----
> From: mpeg-OTspec at yahoogroups.com [mailto:mpeg-OTspec at yahoogroups.com]
> On Behalf Of Mikhail Leonov
> Sent: Wednesday, August 05, 2009 11:59 PM
> To: Ken Lunde; mpeg-OTspec at yahoogroups.com
> Subject: RE: [mpeg-OTspec] Re: Proposed mandatory and optional features
> of the Composite Font format
> 
> Hi Ken,
> 
> > In other words, consumers will know what the
> > properties mean, and if they choose to ignore them, it is because
> they
> > chose to do so.
> 
> Not necessarily. I believe we've always wanted to provide room for
> unknown properties that may be introduced for custom purposes. Is this
> no longer something you feel necessary?
> 
> Best regards,
> Mikhail
> 
> ________________________________________
> From: mpeg-OTspec at yahoogroups.com [mpeg-OTspec at yahoogroups.com] on
> behalf of Ken Lunde [lunde at adobe.com]
> Sent: Wednesday, August 05, 2009 8:02 PM
> To: mpeg-OTspec at yahoogroups.com
> Subject: Re: [mpeg-OTspec] Re: Proposed mandatory and optional features
> of the Composite Font format
> 
> Mikhail,
> 
> If we were effecting a change to an existing specification, that is
> one thing, but as I stated a day or two ago, *any* client that
> supports this new Composite Font format will necessarily do real work,
> meaning that their engineers will be required to read its
> specification.
> 
> The format will be documented, and compared to existing Composite Font
> solutions, the specification and resulting documentation will be
> arguably better. In other words, consumers will know what the
> properties mean, and if they choose to ignore them, it is because they
> chose to do so.
> 
> Regards...
> 
> -- Ken
> 
> On 2009/08/05, at 19:52, Mikhail Leonov wrote:
> 
> >
> > Daan,
> > through "mandatory unknown" properties creator provides consumers
> > with additional information they may not otherwise have.
> >
> > If a consumer sees property Y it does not understand, how can it
> > decide whether it represents something that is reasonably safe to
> > ignore or something sensitive and important?
> > In other words, how does the rational consumer make decisions you
> > mention in your individual replies? Remember, the consumer doesn't
> > even know what these properties mean.
> >
> > Best regards,
> > Mikhail
> >
> > From: Daniel Strebe [dstrebe at adobe.com]
> > Sent: Wednesday, August 05, 2009 5:01 PM
> > To: Mikhail Leonov; mpeg-OTspec at yahoogroups.com
> > Subject: Re: [mpeg-OTspec] Re: Proposed mandatory and optional
> > features of the Composite Font format
> >
> >
> > Mikhail and colleagues:
> >
> > 1.      A font contains a glyph with the digital signature of an
> > approval manager. The composite font author intent is to create a
> > recipe that will only use this font if the digital signature
> > matches. If the recipe reader is unable to verify the digital
> > signature, the recipe author wants to indicate to all such readers
> > to skip this particular font entry.
> >
> > I do not see this as any different than (3). Why is the creator
> > responsible for the consumer's decision about whether or not to use
> > a font whose digital signature does not match? The presence of the
> > signature already states the creator's intent. Marking the signature
> > as a mandatory attribute for reconstructing the composite font is
> > redundant and prone to being ignored by those who do not see any
> > reason to be bound by the creator's fiat, particularly since the
> > consumer has no way to discern the reason for the fiat. All such a
> > flag does is say, "Trust me on this: You don't want to use this
> > font unless you can follow all my rules exactly." To which the
> > consumer replies, "Maybe. Maybe not."
> >
> > 2.      A font vendor released multiple versions of the same font,
> > and some of the versions contained politically sensitive characters.
> > The composite font author intent is to direct all readers of this
> > particular font version to map specific characters differently if
> > certain font versions are encountered. For consumers that are unable
> > to interpret font versions altogether, the author wants to indicate
> > that particular font entries must be skipped.
> >
> > The creator has expressed its intent in the recipe; that is where
> > its responsibility ends. Whether the politically sensitive glyphs
> > are any concern of the consumer is something only the consumer
> > knows. Consumers within a jurisdiction that has politicized glyphs
> > already know the issues and ultimately are responsible for what they
> > render. Consumers outside those jurisdictions do not care. A
> > jurisdiction is not going to hold a creator responsible for a
> > consumer's failure.
> >
> > 3.      A font family with the same name was released by multiple
> > manufacturers. The composite font author intent is to create a
> > recipe that will only use the font released from a particular
> > vendor, otherwise the font should not be used. For composite font
> > readers that are unable to extract the manufacturer name, the intent
> > is to err on the side of caution and not to use the font entry.
> >
> > Then the consumer is left with no font. How is that better than a
> > font that may not exactly express the intent of the creator? While
> > the creator may know there are extant fonts of the same name from
> > multiple vendors (or maybe there aren't, but the creator just wants
> > to mark everything mandatory anyway), how does the creator in any
> > position to know that the differences are relevant to the consumer?
> > Is not erring on the side of caution the prerogative of the consumer?
> >
> > The issue of the minimum valid composite font is also interesting.
> > Given that component fonts may not be present on the target system,
> > it looks like the consumer already has to deal with the situation
> > when a composite font doesn't cover even a single character. In this
> > case, the mandatory rule 4 doesn't provide much value, and perhaps
> > we should consider empty composite fonts valid as well.
> >
> > A composite font with no components does not express any useful
> > intent. Does it? The question of whether an element in a composite
> > font recipe should be mandatory has nothing to do with a consumer's
> > capabilities. It has only to do with expressing the semantics of the
> > intent.
> >
> > Regards,
> >
> > ― daan Strebe
> > Senior Computer Scientist
> > Adobe Systems Incorporated
> >
> >
> > On 09/08/05 16:23, "Mikhail Leonov" <mleonov at microsoft.com> wrote:
> >
> > Daan, Ken, and others,
> > Thanks for your feedback so far!
> >
> > I would like to clarify the purpose of "mandatory unknown"
> > attributes.
> >
> > Unlike "optional unknown" attributes, they are meant to be used by
> > the creator to clarify their intent in specific and sensitive cases.
> > Consider these examples:
> > 1.      A font contains a glyph with the digital signature of an
> > approval manager. The composite font author intent is to create a
> > recipe that will only use this font if the digital signature
> > matches. If the recipe reader is unable to verify the digital
> > signature, the recipe author wants to indicate to all such readers
> > to skip this particular font entry.
> >
> > 2.      A font vendor released multiple versions of the same font,
> > and some of the versions contained politically sensitive characters.
> > The composite font author intent is to direct all readers of this
> > particular font version to map specific characters differently if
> > certain font versions are encountered. For consumers that are unable
> > to interpret font versions altogether, the author wants to indicate
> > that particular font entries must be skipped.
> >
> > 3.      A font family with the same name was released by multiple
> > manufacturers. The composite font author intent is to create a
> > recipe that will only use the font released from a particular
> > vendor, otherwise the font should not be used. For composite font
> > readers that are unable to extract the manufacturer name, the intent
> > is to err on the side of caution and not to use the font entry.
> >
> >
> > In other words, "mandatory unknown" attributes are meant to be more
> > of an exception that a rule. I believe they are a necessary tool for
> > composite font author to indicate very sensitive parts of the
> > recipe. Without ability to flag such attributes, it would be
> > impossible to express all intents carefully.
> >
> > I understand Daan's concern about overly broad use of "mandatory
> > unknown" attributes, however I don't believe possible misuse of a
> > capability should lead to the removal of such capability altogether.
> >
> > The issue of the minimum valid composite font is also interesting.
> > Given that component fonts may not be present on the target system,
> > it looks like the consumer already has to deal with the situation
> > when a composite font doesn't cover even a single character. In this
> > case, the mandatory rule 4 doesn't provide much value, and perhaps
> > we should consider empty composite fonts valid as well.
> >
> > Please let me know your thoughts on these issues, and best regards,
> > Mikhail Leonov
> > Microsoft
> >
> >
> >
> > From: mpeg-OTspec at yahoogroups.com [mailto:mpeg-
> > OTspec at yahoogroups.com] On Behalf Of Ken Lunde
> > Sent: Wednesday, August 05, 2009 1:36 PM
> > To: mpeg-OTspec at yahoogroups.com
> > Subject: [mpeg-OTspec] Re: Proposed mandatory and optional features
> > of the Composite Font format
> >
> >
> >
> > daan,
> >
> > I find myself in complete agreement with you.
> >
> > -- Ken
> >
> > On 2009/08/05, at 11:39, Daniel Strebe wrote:
> >
> > >
> > > Vladimir and colleagues:
> > >
> > > I do not object to parts of the specification being mandatory. In
> > > particular if a consumer cannot even properly parse a recipe then
> it
> > > has no business calling itself a composite font consumer. My
> > > objection is to providing for a creator to deem portions of its
> > > recipe to be "mandatory". So far I am unable to invent
> > > scenarios where that is useful or even meaningful.
> > >
> > > With regard to (a) below, I do not see how an incomplete
> > > implementation of a consumer creates incompatibilities. It is the
> > > recipes that must adhere to the specification in order to prevent
> > > incompatibilities. Certainly text laid out by means of
> > > Consumer A's implementation may not precisely match text laid
> > > out by Consumer B's implementation because they differed in
> > > their ability to realize the intent of the recipe. But why is that
> > > the concern of this working group? We are not creating a
> > > specification for a page description language and surely we have no
> > > expectation that two different layout engines will yield identical
> > > results when using this composite font format. We do not even
> expect
> > > that when using OpenType fonts because far too much in layout
> > > depends on considerations external to fonts, let alone that the
> > > OpenType specification itself contains plenty of vagueness.
> > >
> > > I agree with the remainder of Vladimir's comments.
> > >
> > > To summarize: Mandatory elements of the specification and of
> > > recipes created by it are orthogonal to creator-specified mandatory
> > > elements of a recipe. They should not be discussed together or
> > > confused with each other. I understand and accept mandatory
> elements
> > > in the specification (but think should be specified with
> parsimony).
> > > I cannot see any meaning in creator-designated mandatory elements.
> I
> > > don't imagine I've thought of everything, though, so I
> > > am open to convincing arguments.
> > >
> > > Regards,
> > > ― daan Strebe
> > >
> > >
> > > On 09/08/05 8:11, "Levantovsky, Vladimir"
> <vladimir.levantovsky at monotypeimaging.com
> >  <mailto:vladimir.levantovsky%40monotypeimaging.com>
> > > > wrote:
> > >
> > >
> > >
> > >
> > >
> > > Dear Ken, all,
> > >
> > > I suggest that in an attempt to define the mandatory and optional
> > > parts of the Composite Fonts solution we should consider the
> > > following:
> > > a) Given a complete freedom, consumers would likely implement
> > > support for only a limited subset of elements and attributes *they*
> > > consider useful and/or practical, which may cause most of the
> > > composite font implementations be incompatible with each other.
> > > Thus, the definition of mandatory and optional elements of the
> > > Composite Font specification should be viewed as a mean to insure
> > > certain interoperability level(s) between different
> implementations.
> > >
> > > b) Specifying a set of mandatory and optional elements and
> > > attributes defines the "toolset" that is available for
> > > producers of a Composite Font. It gives them a valuable information
> > > about the tools they can rely on (i.e. mandatory elements and
> > > attributes that are guaranteed to be supported by any
> > > implementation) and the tools that producers may consider using,
> but
> > > without an explicit guarantee that all implementations would be
> able
> > > to support them.
> > >
> > > c) It is typical that some levels of granularity may be
> > > necessary to define optional components. The practice that is
> widely
> > > accepted by many standards organization is to signify support for
> > > different elements and attributes using at least three levels where
> > >
> > > - Mandatory parts are defined using terms MUST (MUST NOT) or
> > > SHALL (SHALL NOT), and define the concepts or tools that have to be
> > > supported unconditionally to insure the required level(s) or
> > > interoperability between different implementations;
> > >
> > > - Recommended parts are defined using terms SHOULD (SHOULD
> > > NOT) and define the concepts or tools that are considered very
> > > useful and even necessary for implementations to support, although
> > > it is recognized that supporting these parts of the spec may place
> > > an additional burden on implementations. The implied meaning
> > > of "SHOULD" in the spec language is that support for a
> > > particular item is strongly recommended but implementations may
> > > choose to not implement for good reason.
> > >
> > > - Optional parts are defined using terms MAY (MAY NOT) and
> > > indicate parts that are truly optional.
> > >
> > > For formal definitions of these terms and their meaning please see
> > > RFC 2119 (http://www.ietf.org/rfc/rfc2119.txt).
> > >
> > > I would like to emphasize it once again that the sole purpose of
> > > specifying mandatory, recommended and optional elements and
> > > attributes is to insure certain level of interoperability between
> > > different consumer implementation, and to enable producers employ a
> > > limited toolset that they can rely on to always be supported by
> > > different implementations.
> > >
> > > I agree with Daan that giving the ability for creators to specify
> > > what elements (and/or attributes) of a particular recipe *they*
> feel
> > > are mandatory isn't going to be useful if implementation is
> > > simply incapable of supporting a particular element. However, while
> > > I agree that we as the owners of specification do not have any
> > > practical ability to "enforce" the
> > > "mandatory" parts, it is generally accepted
> > > standardization practice that only those implementations that
> > > support all mandatory parts of the specification may call
> themselves
> > > compliant. Sometimes, additional conformance requirements are
> > > specified (e.g. as is the case with OFF standard) where multiple
> > > conformance levels can be defined that also include recommended or
> > > optional parts. In this case, a compliant implementation must
> > > implement some optional parts of the spec to be conformant.
> > >
> > > Best regards,
> > > Vladimir
> > >
> > >
> > >
> > > From: mpeg-OTspec at yahoogroups.com <mailto:mpeg-
> OTspec%40yahoogroups.com
> > >  [mailto:mpeg-
> > > OTspec at yahoogroups.com <mailto:OTspec%40yahoogroups.com> ] On
> > Behalf Of Ken Lunde
> > > Sent: Tuesday, August 04, 2009 1:19 PM
> > > To: mpeg-OTspec at yahoogroups.com <mailto:mpeg-
> OTspec%40yahoogroups.com
> > >
> > > Subject: Re: [mpeg-OTspec] Proposed mandatory and optional features
> > > of the Composite Font format
> > >
> > >
> > >
> > > daan,
> > >
> > > I will be interested to hear what ideas others have with regard to
> > the
> > > notion of mandatory. In the end, I think that the sole purpose of
> > > mandatory is to describe the conditions under which a Composite
> Font
> > > cannot function. The format itself can describe some aspects of
> > this,
> > > such as the requirement to include at least one <ComponentFont>
> > > instance, but there may be value in giving some of this power to
> the
> > > creator. But, I agree that this can become the proverbial rope that
> > > can be used to hang oneself, meaning that it can be abused if not
> > used
> > > wisely.
> > >
> > > Also, while we are on the topic of the format and syntax, one
> strong
> > > suggestion that I'd like to relay to the AHG is that the XML use a
> > > namespace. This comes from someone else at Adobe, and I second the
> > > recommendation.
> > >
> > > Regards...
> > >
> > > -- Ken
> > >
> > > On 2009/07/30, at 18:39, Daniel Strebe wrote:
> > >
> > > >
> > > >
> > > > Mikhail:
> > > >
> > > > Thank you for the thoughtful proposals. I agree with Ken
> > > > Lunde's responses (so I will not echo them) with the
> > > exception
> > > > of this matter:
> > > >
> > > > Before drilling into exact syntax of such properties, I would
> like
> > > > to discuss one particular issue. I believe some of the optional
> > > > properties can be safely ignored by the composite font consumers
> > > > without breaking the intent of the composite font producer, while
> > > > other optional properties should cause the consumers unable to
> > honor
> > > > their semantics to skip containing elements entirely.
> > > >
> > > > I do not think the specification should give creators authority
> > that
> > > > can be so easily thwarted. Many consumers will choose to
> > > > ignore "mandatory" directives because those directives
> > > > do not suit their purposes. Meanwhile providing a mechanism to
> > > > specify mandatory elements will merely encourage "control-
> > > > freak" creators to mark everything in sight
> > > > "mandatory". Neither we, as the owner of the
> > > > specification, nor the creator, whose intent is expressed by the
> > > > recipe, has any practical ability to "enforce" what is
> > > > called "mandatory". Should we not stick with the
> > > policy
> > > > that anything stated in the recipe expresses the creator's
> > > > intent? And that elements absent in the recipe signal no
> > particular
> > > > intent? A mandatory signal is redundant, and redundancies are to
> > be
> > > > avoided, if for no other reason than that a consumer will digest
> a
> > > > recipe and immediately find itse! lf confused over elements
> > present
> > > > but not marked mandatory. Are the unmarked elements actually
> > > > optional? If so, why are they present?
> > > >
> > > > Instead of a "mandatory" flag, should we not allow the
> > > > producer to rank elements according to how important they are?
> How
> > > > is "mandatory" versus not mandatory anything more than
> > > > a polarized ranking of "not so important" to
> > > > "critical"? And once we ask that question, can we not
> > > > see that the creator cannot assess the needs of the consumer and
> > > > really ought not to be trying? The creator can state its intent
> > > > already without assigning metrics of gravity to the elements. Its
> > > > own intent is all it knows. The consumer knows how well it can
> > honor
> > > > that intent and is obliged to honor it to the extent that it can.
> > > > Surely no one's legitimate interests are served by handing
> > > > creators a mechanism for bullying consumers into rejecting what
> > > > might be a perfectly serviceable interpretation of a recipe just
> > > > because the creator suffers delusions of power.
> > > >
> > > > I think we should analyze explicit scenarios that require the
> > > > "mandatory" mechanism before we inject it into the
> > > > specification. I would be very surprised if we found any
> scenarios
> > > > that really benefit from it.
> > > >
> > > > Regards,
> > > >
> > > > ― daan Strebe
> > > > Senior Computer Scientist
> > > > Adobe Systems Incorporated
> > > >
> > > >
> > > > On 09/07/29 22:42, "Mikhail Leonov"
> <mleonov at microsoft.com<mailto:mleonov%40microsoft.com
> > >  <mailto:mleonov%40microsoft.com
> > > > > wrote:
> > > >
> > > >
> > > > Hi everyone,
> > > > I would like to provide an update on mandatory and optional
> > elements
> > > > in the composite font format.
> > > >
> > > > First, some background. During phone conference meetings that
> > > > preceded the formal creation of this working group, parties
> > involved
> > > > concluded that, due to the diversity of font handling platforms
> > and
> > > > programming interfaces in the industry, it was not practically
> > > > feasible to agree on a single predefined set of composite font
> > > > elements and properties that would express existing font
> selection
> > > > models and approaches. Instead, it was recommended to give
> > composite
> > > > font producers and consumers flexibility to introduce optional
> > > > properties that wouldn't necessarily be used or even understood
> by
> > > > all conformant consumers. At the same time, semantics of such
> > > > properties should be defined as clearly as possible, so that an
> > > > implementation that chooses to suport them can do so in a way
> > > > compatible with other consumers and producers.
> > > >
> > > > In addition to such optional properties, there are core pieces of
> > > > the composite font format that conforming implementations must
> > > > interpret correctly to provide the minimum degree of
> > > interoperability.
> > > >
> > > > The purpose of this email is to start creating a list of
> mandatory
> > > > and optional features in the composite font format.
> > > >
> > > > The format is assumed to be based on the latest composite font
> > > > syntax proposal uploaded to this AHG discussion list by Ken
> Lunde.
> > > > Since I don't recall us discussing the root element mandated by
> > the
> > > > XML specification, I propose introducing a root element called
> > > > CompositeFont.
> > > >
> > > > Here is a complete composite font file that prescribes the
> > consumer
> > > > to use font "Times New Roman" for all Unicode characters and all
> > > > languages:
> > > >
> > > > <?xml version="1.0" encoding="UTF-8"?>
> > > > <CompositeFont>
> > > > <ComponentFont Target="Times New Roman"/>
> > > > </CompositeFont>
> > > >
> > > > I propose that a conforming composite font consumer must:
> > > > 1. Recognize and parse basic XML structure as outlined above,
> > > > including the standard XML header and the root element
> > > CompositeFont.
> > > > 2. Reject composite font files that violate the standard XML
> > > > specification.
> > > > 3. Recognize, parse, and interpret all possible valid values for
> > the
> > > > following elements and attributes (these elements and attributes
> > are
> > > > furthermore called mandatory):
> > > > a) ComponentFont element and its Target attribute. The
> > > > interpretation of the Target attribute value is allowed to vary
> > > > between consumers depending on the target environment font
> > grouping
> > > > model. For example, a consumer may be using OpenType Preferred
> > > > names, Win32 names, Postscript names, WWS names, or some other
> > font
> > > > selection model that may not even be OpenType based. However, the
> > > > consumer must use a font model that supports at least one font
> > > > format and assigns name values to font files that conform to
> > > > supported font formats. In addition, the consumer must parse
> > comma-
> > > > separator characters that can be used to separate multiple font
> > > > names inside one Target attribute value, omit leading and
> trailing
> > > > whitespace characters from font name values, and honor the escape
> > > > sequence that encodes the comma character itself if it appears
> > as a
> > > > part of the font name. I propose double comma ",," as an escape
> > > > mechanism for such cases.
> > > > b) Encoding element and its Target and Original attributes. These
> > > > are described in Ken Lunde's email, and I won't repeat the
> > semantics
> > > > here. Similar to the Target attribute semantics, the
> > interpretation
> > > > of Unicode characters supported by a font may vary depending on
> > the
> > > > target environment font model. For example, a consumer may prefer
> > > > one cmap table format to another. However, the consumer must use
> a
> > > > font model that provides an ability to obtain Unicode coverage
> for
> > > > all supported font formats.
> > > > c) Language element and its Target attribute. I would like to
> > > > change the Target attribute values from the original definition
> > > > provided by Ken, which used ISO 639-2/T language codes, to a
> > > > definition that uses IETF language tags, as specified by RFC
> 4646.
> > > > The key difference is ability to differentiate between multiple
> > > > character sets for the same language, for example Simplified
> > Chinese
> > > > ("zh-Hans") vs. Traditional Chinese ("zh-Hant"). The conforming
> > > > implementation must properly match language tags. There is a
> > couple
> > > > of interesting corner cases here that I would like to discuss in
> > > > more detail - exact rules for matching language tags that are
> > > > related to each other, and handling of empty language tags and
> > cases
> > > > where the language infomation is not available to the font
> > selection
> > > > algorithm.
> > > > 4. Reject composite font files that don't contain at least one
> > > > ComponentFont elements.
> > > > 5. Interpret composite font elements in the order they appear in
> > the
> > > > font file.
> > > >
> > > > In addition to the mandatory elements and attributes described
> > > > above, there is a large group of elements and attributes that are
> > > > considered optional, such as scale, common baseline and height
> > > > metrics, the display name of the composite font itself, font
> style
> > > > coercion, digital signature enforcement, optical size, required
> > font
> > > > version, font checksum validation, and others.
> > > >
> > > > Before drilling into exact syntax of such properties, I would
> like
> > > > to discuss one particular issue. I believe some of the optional
> > > > properties can be safely ignored by the composite font consumers
> > > > without breaking the intent of the composite font producer, while
> > > > other optional properties should cause the consumers unable to
> > honor
> > > > their semantics to skip containing elements entirely. An example
> > of
> > > > the former class is handling of Scale attribute of the
> > ComponentFont
> > > > entry on platforms that don't support font scaling. An example of
> > > > the latter class is required font version range. If the consumer
> > is
> > > > unable to extract a version from the font, then it is unable to
> > > > honor the producer intent, and a font entry should arguably be
> > > > skipped altogether. I propose that the composite font format
> > should
> > > > contain provisions that enable consumers to tell whether
> > > > encountering an unknown attribute should cause the element it
> > > > belongs! to to be ignored or not.
> > > >
> > > > Please note that the proposals above are by no means final, and
> > any
> > > > suggestions, corrections and additions are very welcome.
> > > >
> > > > Thanks in advance, and best regards,
> > > > Mikhail Leonov
> > > > Microsoft
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
> >
> >
> >
> 
> 
> 
> ------------------------------------
> 
> Yahoo! Groups Links
> 
> 
> 
> 
> 
> ------------------------------------
> 
> Yahoo! Groups Links
> 
> 
>