Proposed mandatory and optional features of the Composite Font format

[Ken Lunde]

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 
> > 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 at yahoogroups.com] On Behalf Of Ken Lunde
> Sent: Tuesday, August 04, 2009 1:19 PM
> To: mpeg-OTspec at yahoogroups.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 
> > > 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
> >
> >
> >
> >
> >
> >
>
>
>
> 
>
>