<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=us-ascii">
<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:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@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:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
{font-family:Verdana;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","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:"Times New Roman","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:10.0pt;
font-family:"Courier New";}
tt
{mso-style-priority:99;
font-family:"Courier New";}
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:"Times New Roman","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:"Times New Roman","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:"Times New Roman","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:"Times New Roman","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:"Times New Roman","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:"Times New Roman","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:"Times New Roman","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:"Times New Roman","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:1181092092;
mso-list-template-ids:-929497848;}
@list l0: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'>Mikhail,<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'>Thank you for taking the initiative to draft the proposed
features and split them into mandatory and optional lists. This would be very
useful first step in creating a future Composite Font spec and your efforts are
very much appreciated.<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'>At the last MPEG meeting the AHG mandate has been extended. The
goals of the group have not changed – we are expected to produce a working
draft specification of the Composite Font solution. This working draft would
evolve as we go along in the development process and would become the
foundation for a future amendment to ISO/IEC 14496-22.<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 encourage you and all AHG members to consider the
opportunity to introduce the working draft specification at the next MPEG
meeting (Oct. 26-30). The deadline for submitting the spec would be October 20,
2009.<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'>Thank you and 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>Mikhail Leonov<br>
<b>Sent:</b> Tuesday, July 14, 2009 3:24 PM<br>
<b>To:</b> mpeg-OTspec@yahoogroups.com<br>
<b>Subject:</b> RE: [mpeg-OTspec] Composite Font syntax<o:p></o:p></span></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<div id=ygrp-mlmsg>
<div id=ygrp-msg>
<div id=ygrp-text>
<p class=MsoNormal><br>
<br>
<br>
<o:p></o:p></p>
<p style='margin-bottom:12.0pt'>Hi Ken,<br>
I think we are in agreement on the basic structure of file format and design
principles.<br>
<br>
At this point, I believe it would be useful to split proposed features of the
format in two broad classes:<br>
1. Mandatory, such as interpreting entries in the correct order, parsing code
point ranges and specifying language tags.<br>
2. Optional, such as digital signature verification, selection based on the
optical size, suppression of font style attributes, etc.<br>
<br>
The idea is to establish enough common ground for the format to be meaningfully
used by the producers, and at the same time provide enough flexibility to serve
existing end to end scenarios.<br>
<br>
I can drive creating a list of the optional features for the first revision of
the format if that is OK with everyone.<br>
<br>
Best regards,<br>
Mikhail Leonov<br>
Microsoft<br>
<br>
-----Original Message-----<br>
From: Ken Lunde [mailto:<a href="mailto:lunde%40adobe.com">lunde@adobe.com</a>]<br>
Sent: Wednesday, July 08, 2009 9:30 AM<br>
To: Mikhail Leonov<br>
Cc: <a href="mailto:mpeg-OTspec%40yahoogroups.com">mpeg-OTspec@yahoogroups.com</a><br>
Subject: Re: [mpeg-OTspec] Composite Font syntax<br>
<br>
Mikhail (and others),<br>
<br>
There has been no further discussion on this important issue, and I have also
not seen any comments about daan Strebe's "Policy proposal"<br>
that was sent to the AHG mailing list on June 1st. I am assuming that no one
has any objections to his policy proposal, which was well- written, and covers
all of the bases extraordinarily well.<br>
<br>
Although I will be on vacation for the next days, mainly in South Dakota for
the 2009 Prairie Dog Safari, and to compete with in Cooper Arms' 2009 One-Shot
Competition in Montana, I will have email access.<br>
<br>
In any case, I'd like to see some more discussion about what led up to the
topics below.<br>
<br>
Thanks...<br>
<br>
-- Ken<br>
<br>
On 2009/06/25, at 10:39, Ken Lunde wrote:<br>
<br>
><br>
><br>
> Karsten,<br>
><br>
> With regard to there being no fixed hierarchy for the three possible<br>
> elements, that is very intentional. The moment we impose a fixed<br>
> hierarchy, we will immediately discover that a Creator will be unable<br>
> to express their Composite Font. Some Composite Font instances will be<br>
> driven by Encoding, others by Language, and perhaps even some by<br>
> Component Fonts. Where each of these elements are in the hierarchy<br>
> depends on the Creator.<br>
><br>
> And, other than at least one instance of a Component Font, the other<br>
> two elements are optional. If they are needed, they are specified. If<br>
> not, they are left undefined, and the Consumer is then free to set<br>
> these as best they can, using attributes from the specified Component<br>
> Fonts.<br>
><br>
> Regards...<br>
><br>
> -- Ken<br>
><br>
> On 2009/06/25, at 10:07, Karsten Luecke wrote:<br>
><br>
> ><br>
> ><br>
> > Hello Mr Lunde,<br>
> ><br>
> > thanks, also for the enhanced example, the second-last for (1). So<br>
> > there is no fixed hierarchy for the Encoding/ComponentFont/Language<br>
> > elements.<br>
> ><br>
> > Indeed my second example was not particularly effective. :D<br>
> ><br>
> > Best wishes,<br>
> > Karsten<br>
> ><br>
> > Ken Lunde wrote:<br>
> > > Karsten,<br>
> > ><br>
> > > Many thanks for the prompt feedback.<br>
> > >> Looks elegant. To be sure I understand:<br>
> > >><br>
> > >> (1)<br>
> > >> How would the re-encoding mechanism fold in? Starting from
your<br>
> > >> example:<br>
> > >><br>
> > >> <!-- Latin --><br>
> > >> <Encoding Target="0000-007F"><br>
> > >> <ComponentFont BaselineShift="12" ScaleFactor="95"<br>
> > >> Target="LatinFont-1"/><br>
> > >> </Encoding><br>
> > >><br>
> > >> Since ComponentFont is inside Encoding, does one need to
define<br>
> > >> ComponentFont again per each such re-encoding entry? E.g.,
with<br>
> > >> nonsense values:<br>
> > >><br>
> > >> <!-- Latin --><br>
> > >> <Encoding Target="0000-007D"><br>
> > >> <ComponentFont BaselineShift="12" ScaleFactor="95"<br>
> > >> Target="LatinFont-1"/><br>
> > >> </Encoding><br>
> > >> <Encoding Target="007E" Original="FE59">
<ComponentFont<br>
> > >> BaselineShift="12" ScaleFactor="95"<br>
> > >> Target="LatinFont-1"/><br>
> > >> </Encoding><br>
> > >> <Encoding Target="007F" Original="FE61">
<ComponentFont<br>
> > >> BaselineShift="12" ScaleFactor="95"<br>
> > >> Target="LatinFont-1"/><br>
> > >> </Encoding><br>
> > >><br>
> > > Yes, that would work, but given that the <ComponentFont>
element<br>
> is<br>
> > > the same within each <Encoding> element, that could
potentially be<br>
> > > placed higher in the hierarchy.<br>
> > ><br>
> > > The re-written example below does this, and also demonstrates
how<br>
> > the<br>
> > > original PUA mappings can be retained, effectively allowing both<br>
> > > character codes to be used in the Composite Font definition
(note<br>
> > that<br>
> > > I corrected the PUA mappings, to make them genuinely PUA code<br>
> > points):<br>
> > ><br>
> > > <!-- Latin --><br>
> > > <ComponentFont BaselineShift="12" ScaleFactor="95"<br>
> > Target="LatinFont-1"><br>
> > > <Encoding Target="0000-007D"/><br>
> > > <Encoding Target="007E" Original="E81E"/>
<Encoding Target="007F"<br>
> > > Original="E826"/> <Encoding Target="E81E"/>
<Encoding<br>
> > > Target="E826"/> </ComponentFont><br>
> > ><br>
> > > This means that U+007E and U+E81E (PUA) will map to the same<br>
> glyph.<br>
> > > Likewise, U+007F and U+E826 (also PUA) will map to the same<br>
> glyphs.<br>
> > ><br>
> > > Also, I should point out that my example did not use PUA code<br>
> > points,<br>
> > > and instead used GB 18030 code points. Here it is in its
corrected<br>
> > form:<br>
> > ><br>
> > > <Encoding Target="9FB4" Original="E81E"/>
<Encoding Target="9FB5"<br>
> > > Original="E826"/> <Encoding Target="9FB6-9FB7"
Original="E82B"/><br>
> > > <Encoding Target="9FB8" Original="E832"/>
<Encoding Target="9FB9"<br>
> > > Original="E843"/> <Encoding
Target="9FBA" Original="E854"/><br>
> > > <Encoding Target="9FBB" Original="E864"/>
<Encoding Target="20087"<br>
> > > Original="E816"/> <Encoding
Target="20089" Original="E817"/><br>
> > > <Encoding Target="200CC" Original="E818"/>
<Encoding<br>
> > > Target="215D7" Original="E831"/>
<Encoding Target="2298F"<br>
> > > Original="E83B"/> <Encoding
Target="241FE" Original="E855"/><br>
> > ><br>
> > > Sorry about that. Maybe it was the brandy. ;-)<br>
> > >> (2)<br>
> > >> Following the description of the fallback mechanism, could
one do<br>
> > >> this?<br>
> > >><br>
> > >> <!-- ENGLISH --><br>
> > >> <Language Target="eng"><br>
> > >> <Encoding Target="0028-0029, 002C, 002E, 0041-005A,
0061-007A,<br>
> > >> 2018-2019, 201C-201D"><!-- POSSIBLY OBSOLETE IN
EXAMPLE --><br>
> > >> <ComponentFont Target="LatinFont-1"/>
<ComponentFont<br>
> > >> Target="LatinFont-2"/> </Encoding>
</Language><br>
> > >><br>
> > >> <!-- OTHER LATIN-SCRIPT LANGUAGES, without Language
--> <Encoding<br>
> > >> Target="0000-[...]"> <ComponentFont
Target="LatinFont-1"/><br>
> > >> <ComponentFont Target="LatinFont-2"/>
</Encoding><br>
> > >><br>
> > > Yes. The earlier declaration is given priority. However, I would<br>
> > think<br>
> > > that you'd want to specify different Component Fonts for the<br>
> second<br>
> > > portion. In your example, without explicitly declaring Language
in<br>
> > the<br>
> > > second portion, you could eliminate the first portion, and get
the<br>
> > > same results.<br>
> > >> (3)<br>
> > >> Even if given as percent, perhaps ScaleFactor better be a
float<br>
> > rather<br>
> > >> than integer, for higher precision?<br>
> > >><br>
> > > I agree. If the Consumer cannot handle a floating point value,
it<br>
> > can<br>
> > > then handle it as its wants, meaning to either truncate or round<br>
> the<br>
> > > value to an integer value. The important thing is that the
format<br>
> > > allows the Creator to specify the value as intended.<br>
> > ><br>
> > > Regards...<br>
> > ><br>
> > > -- Ken<br>
> > ><br>
> > ><br>
> > ><br>
> > > ------------------------------------<br>
> > ><br>
> > > Yahoo! Groups Links<br>
> > ><br>
> > ><br>
> > ><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>