<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=iso-8859-7">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<style>
<!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"MS Gothic";
panose-1:2 11 6 9 7 2 5 8 2 4;}
@font-face
{font-family:"MS Gothic";
panose-1:2 11 6 9 7 2 5 8 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Verdana;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
{font-family:"MS PGothic";
panose-1:0 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"\@MS Gothic";
panose-1:0 0 0 0 0 0 0 0 0 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"MS PGothic","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"MS PGothic","serif";}
code
{mso-style-priority:99;
font-family:"Courier New";}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"MS Gothic","serif";}
tt
{mso-style-priority:99;
font-family:"MS Gothic","serif";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"MS PGothic","serif";}
span.left
{mso-style-name:left;}
span.bld
{mso-style-name:bld;}
p.ad, li.ad, div.ad
{mso-style-name:ad;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"MS PGothic","serif";}
p.ad1, li.ad1, div.ad1
{mso-style-name:ad1;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"MS PGothic","serif";}
p.ad2, li.ad2, div.ad2
{mso-style-name:ad2;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"MS PGothic","serif";}
p.ad3, li.ad3, div.ad3
{mso-style-name:ad3;
mso-margin-top-alt:auto;
margin-right:0in;
margin-bottom:7.5pt;
margin-left:0in;
font-size:12.0pt;
font-family:"MS PGothic","serif";}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;}
p.replbq, li.replbq, div.replbq
{mso-style-name:replbq;
margin:3.0pt;
font-size:12.0pt;
font-family:"MS PGothic","serif";}
span.yshortcuts
{mso-style-name:yshortcuts;}
p.ad4, li.ad4, div.ad4
{mso-style-name:ad4;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"MS PGothic","serif";}
p.ad5, li.ad5, div.ad5
{mso-style-name:ad5;
mso-margin-top-alt:auto;
margin-right:0in;
margin-bottom:7.5pt;
margin-left:0in;
font-size:12.0pt;
font-family:"MS PGothic","serif";}
p.ad6, li.ad6, div.ad6
{mso-style-name:ad6;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"MS PGothic","serif";}
span.yshortcuts1
{mso-style-name:yshortcuts1;
font-family:"Verdana","sans-serif";
font-weight:bold;}
span.yshortcuts2
{mso-style-name:yshortcuts2;
font-family:"Verdana","sans-serif";
font-weight:normal;}
span.EmailStyle35
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
{page:Section1;}
/* List Definitions */
@list l0
{mso-list-id:467743372;
mso-list-type:hybrid;
mso-list-template-ids:-1749778022 67698711 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-number-format:alpha-lower;
mso-level-text:"%1\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1
{mso-list-id:1252205851;
mso-list-type:hybrid;
mso-list-template-ids:1330652914 -546375276 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l1:level1
{mso-level-number-format:bullet;
mso-level-text:-;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:.75in;
text-indent:-.25in;
font-family:"Calibri","sans-serif";
mso-fareast-font-family:Calibri;
mso-bidi-font-family:"Times New Roman";}
@list l2
{mso-list-id:1967615152;
mso-list-template-ids:-1068869972;}
@list l2:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body bgcolor=white lang=EN-US link=blue vlink=purple>
<div class=Section1>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Dear Ken, all,<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I suggest that in an attempt to define the mandatory and
optional parts of the Composite Fonts solution we should consider the
following:<o:p></o:p></span></p>
<p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo2'><![if !supportLists]><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span
style='mso-list:Ignore'>a)<span style='font:7.0pt "Times New Roman"'>
</span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Given a complete freedom, consumers would likely implement
support for only a limited subset of elements and attributes *<b>they</b>*
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.<o:p></o:p></span></p>
<p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo2'><![if !supportLists]><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span
style='mso-list:Ignore'>b)<span style='font:7.0pt "Times New Roman"'>
</span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>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.<o:p></o:p></span></p>
<p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo2'><![if !supportLists]><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span
style='mso-list:Ignore'>c)<span style='font:7.0pt "Times New Roman"'>
</span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>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<o:p></o:p></span></p>
<p class=MsoListParagraph style='margin-left:.75in;text-indent:-.25in;
mso-list:l1 level1 lfo3'><![if !supportLists]><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'><span style='mso-list:Ignore'>-<span
style='font:7.0pt "Times New Roman"'>
</span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>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;<o:p></o:p></span></p>
<p class=MsoListParagraph style='margin-left:.75in;text-indent:-.25in;
mso-list:l1 level1 lfo3'><![if !supportLists]><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'><span style='mso-list:Ignore'>-<span
style='font:7.0pt "Times New Roman"'>
</span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>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.<o:p></o:p></span></p>
<p class=MsoListParagraph style='margin-left:.75in;text-indent:-.25in;
mso-list:l1 level1 lfo3'><![if !supportLists]><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'><span style='mso-list:Ignore'>-<span
style='font:7.0pt "Times New Roman"'>
</span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Optional parts are defined using terms MAY (MAY NOT) and
indicate parts that are truly optional.<o:p></o:p></span></p>
<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>For formal definitions of
these terms and their meaning please see RFC 2119 (<a
href="http://www.ietf.org/rfc/rfc2119.txt">http://www.ietf.org/rfc/rfc2119.txt</a>).<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>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. <o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I agree with Daan that giving the ability for creators to
specify what elements (and/or attributes) of a particular recipe *<b>they</b>*
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.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Best regards,<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Vladimir<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'>
<div>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>
<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
mpeg-OTspec@yahoogroups.com [mailto:mpeg-OTspec@yahoogroups.com] <b>On Behalf
Of </b>Ken Lunde<br>
<b>Sent:</b> Tuesday, August 04, 2009 1:19 PM<br>
<b>To:</b> mpeg-OTspec@yahoogroups.com<br>
<b>Subject:</b> Re: [mpeg-OTspec] Proposed mandatory and optional features of
the Composite Font format<o:p></o:p></span></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal><span style='font-family:"Times New Roman","serif"'> </span>
<o:p></o:p></p>
<div id=ygrp-mlmsg>
<div id=ygrp-msg>
<div id=ygrp-text>
<p style='margin-bottom:12.0pt'>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<span style='font-family:"Times New Roman","serif"'>’</span>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 <span style='font-family:"Times New Roman","serif"'>“</span>mandatory<span
style='font-family:"Times New Roman","serif"'>”</span> directives because
those directives <br>
> do not suit their purposes. Meanwhile providing a mechanism to <br>
> specify mandatory elements will merely encourage <span style='font-family:
"Times New Roman","serif"'>“</span>control- <br>
> freak<span style='font-family:"Times New Roman","serif"'>”</span>
creators to mark everything in sight <br>
> <span style='font-family:"Times New Roman","serif"'>“</span>mandatory<span
style='font-family:"Times New Roman","serif"'>”</span>. 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 <span style='font-family:"Times New Roman","serif"'>“</span>enforce<span
style='font-family:"Times New Roman","serif"'>”</span> what is <br>
> called <span style='font-family:"Times New Roman","serif"'>“</span>mandatory<span
style='font-family:"Times New Roman","serif"'>”</span>. Should we not
stick with the policy <br>
> that anything stated in the recipe expresses the creator<span
style='font-family:"Times New Roman","serif"'>’</span>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 <span style='font-family:"Times New Roman","serif"'>“</span>mandatory<span
style='font-family:"Times New Roman","serif"'>”</span> flag, should we
not allow the <br>
> producer to rank elements according to how important they are? How <br>
> is <span style='font-family:"Times New Roman","serif"'>“</span>mandatory<span
style='font-family:"Times New Roman","serif"'>”</span> versus not
mandatory anything more than <br>
> a polarized ranking of <span style='font-family:"Times New Roman","serif"'>“</span>not
so important<span style='font-family:"Times New Roman","serif"'>”</span>
to <br>
> <span style='font-family:"Times New Roman","serif"'>“</span>critical<span
style='font-family:"Times New Roman","serif"'>”</span>? 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<span style='font-family:"Times New Roman","serif"'>’</span>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>
> <span style='font-family:"Times New Roman","serif"'>“</span>mandatory<span
style='font-family:"Times New Roman","serif"'>”</span> 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>
> <span style='font-family:"Times New Roman","serif"'>¯</span> daan Strebe<br>
> Senior Computer Scientist<br>
> Adobe Systems Incorporated<br>
><br>
><br>
> On 09/07/29 22:42, "Mikhail Leonov" <<a
href="mailto:mleonov%40microsoft.com">mleonov@microsoft.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>
> <o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><span style='color:white'><o:p></o:p></span></p>
</div>
</div>
</div>
</body>
</html>