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

[Levantovsky, Vladimir]

Mikhail,

I think that there may be possible misunderstanding regarding the expected consumer behavior with regard to unknown property vs. a component entry containing the unknown property.

First of all, I do agree with you that we should allow recipe creators include an arbitrary property that may only be known to a particular consumer and unknown to all other spec-compliant implementations. I have never suggested that the presence of an unknown property should invalidate the component entry and cause a consumer to reject the whole entry outright; however, a consumer will have no choice but to ignore an unknown property, just because its syntax and semantics is unknown. In my opinion, ignoring an unknown property (again, I do not suggest ignoring a component entry containing an unknown property!) is the only way to achieve a deterministic behavior.

As an analogy (for clarification purposes only) - OpenType fonts may be extended to contain a custom table containing an arbitrary data. A compliant font engine will never be able to know what that table represents and how to process the data, but it doesn't mean that the whole font has to be rejected. E.g. an AAT font can be processed by TTF-compliant rasterizer although some of the AAT tables would be ignored - generic TrueType engine will simply not know what to do with them.

We should adopt the same approach with custom properties - we can not prevent creators from introducing a custom property if they wish, but the only deterministic way for a compliant consumer to deal with them is to ignore what it can not interpret and process.

Regards,
Vlad


> -----Original Message-----
> From: Mikhail Leonov [mailto:mleonov at microsoft.com]
> Sent: Friday, August 07, 2009 3:34 PM
> To: Levantovsky, Vladimir; Ken Lunde; mpeg-OTspec at yahoogroups.com
> Subject: RE: [mpeg-OTspec] Re: Proposed mandatory and optional features
> of the Composite Font format
> 
> Vladimir, Ken, and others,
> Just to be clear, this particular branch of our discussion aims to
> formalize how compliant consumers deal with unknown properties that are
> not present in the standard specification.
> 
> Ken said:
>         ' We have enough people involved in this discussion to come up
> with a complete list of properties for each of the primary tags --
> <ComponentFont>, <Language>, and <Encoding> (in an appropriate
> namespace, of course) -- so I would be surprised if producer has a need
> for an unknown property. '
> 
> The more properties we are able to agree on and standardize, the
> better.
> However, due to the inherent complexity and diversity of font selection
> algorithms used in the industry today, I am reasonably confident that
> we will not be able to create a complete list of properties needed by
> various software platforms and applications. I believe we should help
> the recipe creator express his or her intent more accurately, and
> proactively design for compliant clients who may not be able to
> interpret all properties.
> 
> Vladimir said:
>         '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.'
> 
> I respectfully disagree. The act of accepting or rejecting a component
> entry containing a property is key to the whole font selection process,
> and "mandatory" vs. "optional" semantics of unknown properties directly
> help with that.
> 
> A well-defined way to handle unknown properties will help achieve
> deterministic behavior on all clients, which will be beneficial to the
> successful adoption of the composite font standard in real life
> applications and platforms that may choose to introduce new custom
> properties to fully express their scenarios.
> 
> Thanks for the great discussion so far, and best regards,
> Mikhail Leonov
> Microsoft
> 
> -----Original Message-----
> From: Levantovsky, Vladimir
> [mailto:Vladimir.Levantovsky at MonotypeImaging.com]
> Sent: Thursday, August 06, 2009 8:03 PM
> To: Mikhail Leonov; Ken Lunde; mpeg-OTspec at yahoogroups.com
> Subject: RE: [mpeg-OTspec] Re: Proposed mandatory and optional features
> of the Composite Font format
> 
> 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
> >
> >
> >