<HTML>
<HEAD>
<TITLE>Re: [mpeg-OTspec] Proposed mandatory and optional features of the Composite Font format</TITLE>
</HEAD>
<BODY>
<FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'><BR>
Thanks, Ken. I would be interested to study example of conditions in which a composite font could not function if parts of its recipe were ignored because of limitations on the consuming side.<BR>
<BR>
Regards,<BR>
— daan Strebe<BR>
<BR>
<BR>
On 09/08/04 10:18, "Ken Lunde" <<a href="lunde@adobe.com">lunde@adobe.com</a>> wrote:<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'><BR>
daan,<BR>
<BR>
I will be interested to hear what ideas others have with regard to the <BR>
notion of mandatory. In the end, I think that the sole purpose of <BR>
mandatory is to describe the conditions under which a Composite Font <BR>
cannot function. The format itself can describe some aspects of this, <BR>
such as the requirement to include at least one <ComponentFont> <BR>
instance, but there may be value in giving some of this power to the <BR>
creator. But, I agree that this can become the proverbial rope that <BR>
can be used to hang oneself, meaning that it can be abused if not used <BR>
wisely.<BR>
<BR>
Also, while we are on the topic of the format and syntax, one strong <BR>
suggestion that I'd like to relay to the AHG is that the XML use a <BR>
namespace. This comes from someone else at Adobe, and I second the <BR>
recommendation.<BR>
<BR>
Regards...<BR>
<BR>
-- Ken<BR>
<BR>
On 2009/07/30, at 18:39, Daniel Strebe wrote:<BR>
<BR>
><BR>
><BR>
> Mikhail:<BR>
><BR>
> Thank you for the thoughtful proposals. I agree with Ken <BR>
> Lunde’s responses (so I will not echo them) with the exception <BR>
> of this matter:<BR>
><BR>
> Before drilling into exact syntax of such properties, I would like <BR>
> to discuss one particular issue. I believe some of the optional <BR>
> properties can be safely ignored by the composite font consumers <BR>
> without breaking the intent of the composite font producer, while <BR>
> other optional properties should cause the consumers unable to honor <BR>
> their semantics to skip containing elements entirely.<BR>
><BR>
> I do not think the specification should give creators authority that <BR>
> can be so easily thwarted. Many consumers will choose to <BR>
> ignore “mandatory” directives because those directives <BR>
> do not suit their purposes. Meanwhile providing a mechanism to <BR>
> specify mandatory elements will merely encourage “control- <BR>
> freak” creators to mark everything in sight <BR>
> “mandatory”. Neither we, as the owner of the <BR>
> specification, nor the creator, whose intent is expressed by the <BR>
> recipe, has any practical ability to “enforce” what is <BR>
> called “mandatory”. Should we not stick with the policy <BR>
> that anything stated in the recipe expresses the creator’s <BR>
> intent? And that elements absent in the recipe signal no particular <BR>
> intent? A mandatory signal is redundant, and redundancies are to be <BR>
> avoided, if for no other reason than that a consumer will digest a <BR>
> recipe and immediately find itse! lf confused over elements present <BR>
> but not marked mandatory. Are the unmarked elements actually <BR>
> optional? If so, why are they present?<BR>
><BR>
> Instead of a “mandatory” flag, should we not allow the <BR>
> producer to rank elements according to how important they are? How <BR>
> is “mandatory” versus not mandatory anything more than <BR>
> a polarized ranking of “not so important” to <BR>
> “critical”? And once we ask that question, can we not <BR>
> see that the creator cannot assess the needs of the consumer and <BR>
> really ought not to be trying? The creator can state its intent <BR>
> already without assigning metrics of gravity to the elements. Its <BR>
> own intent is all it knows. The consumer knows how well it can honor <BR>
> that intent and is obliged to honor it to the extent that it can. <BR>
> Surely no one’s legitimate interests are served by handing <BR>
> creators a mechanism for bullying consumers into rejecting what <BR>
> might be a perfectly serviceable interpretation of a recipe just <BR>
> because the creator suffers delusions of power.<BR>
><BR>
> I think we should analyze explicit scenarios that require the <BR>
> “mandatory” mechanism before we inject it into the <BR>
> specification. I would be very surprised if we found any scenarios <BR>
> that really benefit from it.<BR>
><BR>
> Regards,<BR>
><BR>
> — daan Strebe<BR>
> Senior Computer Scientist<BR>
> Adobe Systems Incorporated<BR>
><BR>
><BR>
> On 09/07/29 22:42, "Mikhail Leonov" <<a href="mleonov@microsoft.com">mleonov@microsoft.com</a> <<a href="mailto:mleonov%40microsoft.com">mailto:mleonov%40microsoft.com</a>> > wrote:<BR>
><BR>
><BR>
> Hi everyone,<BR>
> I would like to provide an update on mandatory and optional elements <BR>
> in the composite font format.<BR>
><BR>
> First, some background. During phone conference meetings that <BR>
> preceded the formal creation of this working group, parties involved <BR>
> concluded that, due to the diversity of font handling platforms and <BR>
> programming interfaces in the industry, it was not practically <BR>
> feasible to agree on a single predefined set of composite font <BR>
> elements and properties that would express existing font selection <BR>
> models and approaches. Instead, it was recommended to give composite <BR>
> font producers and consumers flexibility to introduce optional <BR>
> properties that wouldn't necessarily be used or even understood by <BR>
> all conformant consumers. At the same time, semantics of such <BR>
> properties should be defined as clearly as possible, so that an <BR>
> implementation that chooses to suport them can do so in a way <BR>
> compatible with other consumers and producers.<BR>
><BR>
> In addition to such optional properties, there are core pieces of <BR>
> the composite font format that conforming implementations must <BR>
> interpret correctly to provide the minimum degree of interoperability.<BR>
><BR>
> The purpose of this email is to start creating a list of mandatory <BR>
> and optional features in the composite font format.<BR>
><BR>
> The format is assumed to be based on the latest composite font <BR>
> syntax proposal uploaded to this AHG discussion list by Ken Lunde. <BR>
> Since I don't recall us discussing the root element mandated by the <BR>
> XML specification, I propose introducing a root element called <BR>
> CompositeFont.<BR>
><BR>
> Here is a complete composite font file that prescribes the consumer <BR>
> to use font "Times New Roman" for all Unicode characters and all <BR>
> languages:<BR>
><BR>
> <?xml version="1.0" encoding="UTF-8"?><BR>
> <CompositeFont><BR>
> <ComponentFont Target="Times New Roman"/><BR>
> </CompositeFont><BR>
><BR>
> I propose that a conforming composite font consumer must:<BR>
> 1. Recognize and parse basic XML structure as outlined above, <BR>
> including the standard XML header and the root element CompositeFont.<BR>
> 2. Reject composite font files that violate the standard XML <BR>
> specification.<BR>
> 3. Recognize, parse, and interpret all possible valid values for the <BR>
> following elements and attributes (these elements and attributes are <BR>
> furthermore called mandatory):<BR>
> a) ComponentFont element and its Target attribute. The <BR>
> interpretation of the Target attribute value is allowed to vary <BR>
> between consumers depending on the target environment font grouping <BR>
> model. For example, a consumer may be using OpenType Preferred <BR>
> names, Win32 names, Postscript names, WWS names, or some other font <BR>
> selection model that may not even be OpenType based. However, the <BR>
> consumer must use a font model that supports at least one font <BR>
> format and assigns name values to font files that conform to <BR>
> supported font formats. In addition, the consumer must parse comma- <BR>
> separator characters that can be used to separate multiple font <BR>
> names inside one Target attribute value, omit leading and trailing <BR>
> whitespace characters from font name values, and honor the escape <BR>
> sequence that encodes the comma character itself if it appears as a <BR>
> part of the font name. I propose double comma ",," as an escape <BR>
> mechanism for such cases.<BR>
> b) Encoding element and its Target and Original attributes. These <BR>
> are described in Ken Lunde's email, and I won't repeat the semantics <BR>
> here. Similar to the Target attribute semantics, the interpretation <BR>
> of Unicode characters supported by a font may vary depending on the <BR>
> target environment font model. For example, a consumer may prefer <BR>
> one cmap table format to another. However, the consumer must use a <BR>
> font model that provides an ability to obtain Unicode coverage for <BR>
> all supported font formats.<BR>
> c) Language element and its Target attribute. I would like to <BR>
> change the Target attribute values from the original definition <BR>
> provided by Ken, which used ISO 639-2/T language codes, to a <BR>
> definition that uses IETF language tags, as specified by RFC 4646. <BR>
> The key difference is ability to differentiate between multiple <BR>
> character sets for the same language, for example Simplified Chinese <BR>
> ("zh-Hans") vs. Traditional Chinese ("zh-Hant"). The conforming <BR>
> implementation must properly match language tags. There is a couple <BR>
> of interesting corner cases here that I would like to discuss in <BR>
> more detail - exact rules for matching language tags that are <BR>
> related to each other, and handling of empty language tags and cases <BR>
> where the language infomation is not available to the font selection <BR>
> algorithm.<BR>
> 4. Reject composite font files that don't contain at least one <BR>
> ComponentFont elements.<BR>
> 5. Interpret composite font elements in the order they appear in the <BR>
> font file.<BR>
><BR>
> In addition to the mandatory elements and attributes described <BR>
> above, there is a large group of elements and attributes that are <BR>
> considered optional, such as scale, common baseline and height <BR>
> metrics, the display name of the composite font itself, font style <BR>
> coercion, digital signature enforcement, optical size, required font <BR>
> version, font checksum validation, and others.<BR>
><BR>
> Before drilling into exact syntax of such properties, I would like <BR>
> to discuss one particular issue. I believe some of the optional <BR>
> properties can be safely ignored by the composite font consumers <BR>
> without breaking the intent of the composite font producer, while <BR>
> other optional properties should cause the consumers unable to honor <BR>
> their semantics to skip containing elements entirely. An example of <BR>
> the former class is handling of Scale attribute of the ComponentFont <BR>
> entry on platforms that don't support font scaling. An example of <BR>
> the latter class is required font version range. If the consumer is <BR>
> unable to extract a version from the font, then it is unable to <BR>
> honor the producer intent, and a font entry should arguably be <BR>
> skipped altogether. I propose that the composite font format should <BR>
> contain provisions that enable consumers to tell whether <BR>
> encountering an unknown attribute should cause the element it <BR>
> belongs! to to be ignored or not.<BR>
><BR>
> Please note that the proposals above are by no means final, and any <BR>
> suggestions, corrections and additions are very welcome.<BR>
><BR>
> Thanks in advance, and best regards,<BR>
> Mikhail Leonov<BR>
> Microsoft<BR>
><BR>
><BR>
><BR>
><BR>
><BR>
> <BR>
<BR>
<BR>
<BR>
<FONT COLOR="#FFFFFF"><BR>
</FONT><BR>
</FONT></SPAN></BLOCKQUOTE>
</BODY>
</HTML>