<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: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;}
/* 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:#1E66AE;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#1E66AE;
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.cat
{mso-style-name:cat;}
span.ct
{mso-style-name:ct;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;}
p.attach, li.attach, div.attach
{mso-style-name:attach;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:7.0pt;
font-family:"Arial","sans-serif";}
p.bold, li.bold, div.bold
{mso-style-name:bold;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:8.0pt;
font-family:"Arial","sans-serif";
font-weight:bold;}
p.green, li.green, div.green
{mso-style-name:green;
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";
color:#628C2A;}
p.replbq, li.replbq, div.replbq
{mso-style-name:replbq;
margin:2.4pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
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.underline, li.underline, div.underline
{mso-style-name:underline;
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.yshortcuts
{mso-style-name:yshortcuts;}
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;
margin-bottom:6.0pt;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
p.underline1, li.underline1, div.underline1
{mso-style-name:underline1;
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";
text-decoration:underline;}
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.EmailStyle36
{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:55594605;
mso-list-template-ids:-1015129968;}
@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 lang=EN-US link="#1E66AE" vlink="#1E66AE" style='word-wrap: break-word;
-webkit-nbsp-mode: space;-webkit-line-break: after-white-space'>
<div class=Section1>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Tony, <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 very much for your response. It is somewhat unusual
situation when a technology developed by one company is proposed by a
representative from another. It is good to hear that Apple doesn’t mind
contributing Spliced Font Format and does not object to making further modification
to create a full-featured common cross-platform format.<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 am looking forward to the formal confirmation by Apple’s
Legal Department, and I also suggest that you should contact David Singer
(copied on this email, who is the primary Apple representative in MPEG) with
any questions you may have about the formalities of making a technical proposal
and responding to the CFP.<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 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"'> Tony Tseung
[mailto:tseung@apple.com] <br>
<b>Sent:</b> Monday, March 01, 2010 6:00 PM<br>
<b>To:</b> Levantovsky, Vladimir<br>
<b>Cc:</b> Ken Lunde; mpeg-OTspec@yahoogroups.com; David Lemon; David Singer<br>
<b>Subject:</b> Re: [mpeg-OTspec] AHG on Font Format Kick-off<o:p></o:p></span></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal>Vladimir,<o:p></o:p></p>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal>I was the originator of the Spliced Font Format, and it does
not require any specific implementation and it is not bound by Apple's
copyright, as far as I can tell. My manager (at Apple) will double check with
Apple Legal Dept. again to formally confirm this but I don think there
should be concerns of IP issues. We welcome the use of the Spliced Font Format
for CFS with the necessary modifications and we are looking forward to a common
cross-platform format to solve the issues of character coverages and font
fallbacks.<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal>Tony<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<div>
<p class=MsoNormal>On Mar 1, 2010, at 10:54 AM, Levantovsky, Vladimir wrote:<o:p></o:p></p>
</div>
<p class=MsoNormal><br>
<br>
<o:p></o:p></p>
<div>
<p class=MsoNormal style='background:white'> <o:p></o:p></p>
<div id=ygrp-mlmsg>
<div id=ygrp-msg>
<div id=ygrp-text>
<p style='margin-bottom:12.0pt;background:white'>Ken, all,<br>
<br>
I appreciate your efforts but I am afraid you misunderstood what I said in my
earlier post. I do not see how any part of it could have been interpreted as a
suggestion to include a modified version of Apple's Spliced Font Format in the
CFP. To the contrary, what I said was that CFP can *not* require a specific
implementation be the only suitable result - this would contradict the purpose
of making public call for proposals to find the best technology for a technical
solution we are trying to develop.<br>
In addition, there may be other issues we need to consider. As I mentioned in
my previous message, I assume that specification for Apple's Spliced Font
Format is copyrighted by Apple, and we have not yet heard from any of Apple
representatives on this list whether they in fact would be willing to
contribute their technology to ISO. I understand the benefits of developing a
standardized solution that would be compatible with already existing
implementations supported by at least one major vendor; but for "Call for
Proposals" to be successful we need to concentrate on defining
requirements and evaluation criteria in a way that would set the bar high
enough to make sure that the best technical proposals would be selected, and
not just the one particular solution we currently see as a strong candidate.<br>
<br>
Regards,<br>
Vladimir<br>
<br>
> -----Original Message-----<br>
> From: Ken Lunde [mailto:<a href="mailto:lunde%40adobe.com">lunde@adobe.com</a>]<br>
> Sent: Monday, March 01, 2010 1:15 PM<br>
> To: Levantovsky, Vladimir<br>
> Cc: <a href="mailto:mpeg-OTspec%40yahoogroups.com">mpeg-OTspec@yahoogroups.com</a>;
David Lemon; David Singer<br>
> Subject: Re: [mpeg-OTspec] AHG on Font Format Kick-off<br>
><br>
> Vladimir and others,<br>
><br>
> It seems that my mailing list posts were not blocked, but were being<br>
> severely delayed.<br>
><br>
> Anyway, I like your suggestion about including a modified version of<br>
> Apple's Spliced Font Format as part of the CFP. To this end, I spent<br>
> some time this morning thinking about where in the Spliced Font Format<br>
> the missing elements could be inserted. As I did late last year, below<br>
> is a more human-readable form of the elements and their relative<br>
> hierarchy in Apple's current Spliced Font Format:<br>
><br>
> PosingFont (Name*, FontMetrics?, Components+)<br>
> -->Name<br>
> -->FontMetrics<br>
> -->Components (ComponentDef | LanguagePreferedList)+<br>
> ----->ComponentDef (Matrix?, UnicodeCharSet*, cmapOverride?)<br>
> -------->Matrix<br>
> -------->UnicodeCharSet<br>
> -------->cmapOverride (map+)<br>
> ----------->map<br>
> ----->LanguagePreferedList (LanguagePreferedComponentDef+)<br>
> -------->LanguagePreferedComponentDef (ComponentDef, language+)<br>
> ----------->ComponentDef (Matrix?, UnicodeCharSet*, cmapOverride?)<br>
> -------------->Matrix<br>
> -------------->UnicodeCharSet<br>
> -------------->cmapOverride (map+)<br>
> ----------------->map<br>
> ----------->language<br>
><br>
> I identified the following elements as ones that should be added, based<br>
> on our discussions:<br>
><br>
> <cfs:ComponentFont> LocationHint<br>
> <cfs:ComponentFont> Tracking<br>
> <cfs:Encoding> Original<br>
><br>
> Below is the same human-readable form of the format, with these<br>
> elements added:<br>
><br>
> PosingFont (Name*, FontMetrics?, Components+)<br>
> -->Name<br>
> -->FontMetrics<br>
> -->Components (ComponentDef | LanguagePreferedList)+<br>
> ----->ComponentDef (LocationHint*, Matrix?, Tracking?,<br>
> UnicodeCharSet*, cmapOverride?)<br>
> -------->LocationHint<br>
> -------->Matrix<br>
> -------->Tracking<br>
> -------->UnicodeCharSet (ToUnicode*)<br>
> ----------->ToUnicode<br>
> -------->cmapOverride (map+)<br>
> ----------->map<br>
> ----->LanguagePreferedList (LanguagePreferedComponentDef+)<br>
> -------->LanguagePreferedComponentDef (ComponentDef, language+)<br>
> ----------->ComponentDef (LocationHint*, Matrix?, Tracking?,<br>
> UnicodeCharSet*, cmapOverride?)<br>
> -------------->LocationHint<br>
> -------------->Matrix<br>
> -------------->Tracking<br>
> -------------->UnicodeCharSet (ToUnicode*)<br>
> ----------------->ToUnicode<br>
> -------------->cmapOverride (map+)<br>
> ----------------->map<br>
> ----------->language<br>
><br>
> Note that "<cfs:Encoding> Original" is an optional element
of the<br>
> UnicodeCharSet element, called "ToUnicode," whose purpose is
remap at<br>
> the encoding level, which could be from Unicode to Unicode, or from<br>
> non-Unicode to Unicode. Also note that "cfs:ComponentFont><br>
> LocationHint" and cfs:ComponentFont> Tracking" are set as
optional<br>
> elements of the "ComponentDef" element.<br>
><br>
> If anyone thinks that are better places for these three elements,<br>
> please let me know. I feel that this is the first step in modifying the<br>
> Spliced Font Format DTD.<br>
><br>
> Regards...<br>
><br>
> -- Ken<br>
><br>
> On 2010/02/26, at 7:45, Levantovsky, Vladimir wrote:<br>
><br>
> > Ken,<br>
> ><br>
> > As far as email blocking is concerned, you may need to take this<br>
> issue up with your IT department - there is nothing I can do (as far as<br>
> AHG email list configuration is concerned) to change this. In the<br>
> meantime - you do have another option - as an alternative solution you<br>
> can post and reply-to messages online<br>
> (<a href="http://tech.groups.yahoo.com/group/mpeg-OTspec/messages">http://tech.groups.yahoo.com/group/mpeg-OTspec/messages</a>)
using the<br>
> "Reply" function in the upper left corner of the message frame.<br>
> ><br>
> > On the subject of CFS - I do not disagree with you that Apple's<br>
> Spliced Font Format may in fact become the good foundation for future<br>
> CFS solution. You advocated for this more than once; however, we have<br>
> not heard yet from Apple's representatives on this list whether they in<br>
> fact would be willing to disclaim copyrights and contribute their<br>
> specification to ISO. As far as CFP is concerned, I don't think we can<br>
> draft it to require a specific implementation, but we can definitely<br>
> strengthen the requirements and evaluation criteria for future solution<br>
> in such a way that would assure that only qualified proposals would<br>
> pass through the submission selection process.<br>
> ><br>
> > Thank you,<br>
> > Vladimir<br>
> ><br>
> >> -----Original Message-----<br>
> >> From: Ken Lunde [mailto:<a href="mailto:lunde%40adobe.com">lunde@adobe.com</a>]<br>
> >> Sent: Friday, February 26, 2010 10:02 AM<br>
> >> To: Levantovsky, Vladimir<br>
> >> Cc: <a href="mailto:mpeg-OTspec%40yahoogroups.com">mpeg-OTspec@yahoogroups.com</a>;
David Lemon<br>
> >> Subject: Re: [mpeg-OTspec] AHG on Font Format Kick-off<br>
> >><br>
> >> Vladimir,<br>
> >><br>
> >> On an administrative note, my messages to the AHG mailing list
are<br>
> no<br>
> >> longer being posted, and I suspect that "<a
href="http://adobe.com">adobe.com</a>" emails are now<br>
> >> being blocked. If you check the messages on the website, the one
you<br>
> >> replied to isn't there (I originally sent it yesterday afternoon,<br>
> and<br>
> >> resent it this morning, explicitly adding your email address),
and I<br>
> >> suspect that this one won't be there.<br>
> >><br>
> >> Back to the topic, I strongly suggest that we work to develop a<br>
> >> modified version of Apple's Spliced Font Format, modified by
having<br>
> the<br>
> >> three identified elements added, and use it with the Requirements<br>
> >> document and CFP.<br>
> >><br>
> >> Regards...<br>
> >><br>
> >> -- Ken<br>
> >><br>
> >> On 2010/02/26, at 6:34, Levantovsky, Vladimir wrote:<br>
> >><br>
> >>> Ken, all,<br>
> >>><br>
> >>> I expect that the requirements and the CFP documents would be<br>
> >> published at the same time (tentatively in April). It is up to us
as<br>
> a<br>
> >> group to agree on the deadline for submissions, but typically
CFPs<br>
> have<br>
> >> deadlines from three to six months from the publication date.
That<br>
> >> being said, it doesn't mean that we should stop any development
work<br>
> -<br>
> >> we can produce a working draft and update it as we go along with
the<br>
> >> evaluation of CFP submissions.<br>
> >>> It might even be desirable (and, again, this is the decision
that<br>
> AHG<br>
> >> would have to make) that the first working draft be prepared and<br>
> >> published at the same time when CFP is published, so that
together<br>
> with<br>
> >> the requirements and CFP itself it would give to potential<br>
> contributors<br>
> >> an idea of the scope of work been done by the AHG (assuming that
the<br>
> >> submitter of a proposal may not yet be an AHG member, which is<br>
> unlikely<br>
> >> but may be the case).<br>
> >>><br>
> >>> Regards,<br>
> >>> Vladimir<br>
> >>><br>
> >>><br>
> >>>> -----Original Message-----<br>
> >>>> From: Ken Lunde [mailto:<a href="mailto:lunde%40adobe.com">lunde@adobe.com</a>]<br>
> >>>> Sent: Friday, February 26, 2010 9:19 AM<br>
> >>>> To: Levantovsky, Vladimir; <a
href="mailto:mpeg-OTspec%40yahoogroups.com">mpeg-OTspec@yahoogroups.com</a><br>
> >>>> Cc: David Lemon<br>
> >>>> Subject: Re: [mpeg-OTspec] AHG on Font Format Kick-off<br>
> >>>><br>
> >>>> Vladimir,<br>
> >>>><br>
> >>>> After the the requirements and use-case document is
accepted at<br>
> the<br>
> >>>> next MPEG meeting, by what date do you expect to have the
CFP<br>
> >> document<br>
> >>>> ready? And, to follow up on that, once the CFP document
is<br>
> >> published,<br>
> >>>> by what date must any proposals be submitted?<br>
> >>>><br>
> >>>> Thanks...<br>
> >>>><br>
> >>>> -- Ken<br>
> >>>><br>
> >>>> On 2010/02/23, at 11:34, Levantovsky, Vladimir wrote:<br>
> >>>><br>
> >>>>> Ken, all,<br>
> >>>>><br>
> >>>>> Thank you for your active participation and support
of Composite<br>
> >> Font<br>
> >>>> Standard activity. I uploaded the draft requirements
document that<br>
> >> we<br>
> >>>> discussed and approved during the last ISO MPEG meeting
in<br>
> January.<br>
> >> The<br>
> >>>> document can be downloaded using the following<br>
> >>>> link:<a
href="http://groups.yahoo.com/group/mpeg-OTspec/files/w11212-">http://groups.yahoo.com/group/mpeg-OTspec/files/w11212-</a><br>
> >>>> DraftRequirements_CFS.zip<br>
> >>>>><br>
> >>>>> The next MPEG meeting will be held in April 19-23,
and part of<br>
> our<br>
> >>>> mandate is to finalize the requirements and use case
document, and<br>
> >> to<br>
> >>>> prepare a draft text for Call for Proposals where we
should<br>
> clearly<br>
> >>>> outline the features of the CFS (including expectations
for future<br>
> >>>> implementations based on the requirements document) and
evaluation<br>
> >>>> criteria for submitted proposals, as well as the
estimated<br>
> schedule<br>
> >> of<br>
> >>>> the development of the CFS specification.<br>
> >>>>><br>
> >>>>> I will make a first stub at drafting the text of CFP;
meanwhile I<br>
> >>>> would like to ask all AHG members to review the draft
requirements<br>
> >>>> document and submit your comments and proposed<br>
> >> changes/clarifications<br>
> >>>> (if any). I would expect to have final drafts of both
document<br>
> >>>> (requirements / use cases, and draft CFP) finalized no
later than<br>
> >> April<br>
> >>>> 12, 2010.<br>
> >>>>><br>
> >>>>> I also would like to remind the AHG that the text of
the draft<br>
> >>>> corrigendum for ISO/IEC 14496-22 OFF is now under open
ballot, and<br>
> >> that<br>
> >>>> we had some comments submitted by Microsoft. We need to
discuss<br>
> and<br>
> >>>> finalize the text of the corrigendum and prepare ballot
comments<br>
> to<br>
> >>>> have the proposed changes incorporated in the current
text.<br>
> >>>>><br>
> >>>>> Thank you,<br>
> >>>>> Vladimir<br>
> >>>>><br>
> >>>>><br>
> >>>>><br>
> >>>>> From: <a href="mailto:mpeg-OTspec%40yahoogroups.com">mpeg-OTspec@yahoogroups.com</a>
[mailto:mpeg-<br>
> >>>> <a href="mailto:OTspec%40yahoogroups.com">OTspec@yahoogroups.com</a>]
On Behalf Of Ken Lunde<br>
> >>>>> Sent: Thursday, February 11, 2010 5:47 PM<br>
> >>>>> To: <a href="mailto:mpeg-OTspec%40yahoogroups.com">mpeg-OTspec@yahoogroups.com</a><br>
> >>>>> Cc: David Lemon<br>
> >>>>> Subject: Re: [mpeg-OTspec] AHG on Font Format Kick-off<br>
> >>>>><br>
> >>>>><br>
> >>>>> Vladimir,<br>
> >>>>><br>
> >>>>> Are you planning to drive the schedule for the
required bits,<br>
> such<br>
> >> as<br>
> >>>> turning the list of requirements for the CFS into
something that<br>
> is<br>
> >> no<br>
> >>>> longer draft, and issuing the CFP? Unless we have
feasible dates<br>
> >>>> attached to these milestones, things will continue to
delay. As<br>
> >> usual,<br>
> >>>> if there is anything I can do to push things along, you
can count<br>
> on<br>
> >> my<br>
> >>>> help and support.<br>
> >>>>><br>
> >>>>> Thanks...<br>
> >>>>><br>
> >>>>> -- Ken<br>
> >>>>><br>
> >>>>> On 2010/02/01, at 14:40, Levantovsky, Vladimir wrote:<br>
> >>>>><br>
> >>>>>> Dear Ken, all,<br>
> >>>>>><br>
> >>>>>> Thank you very much for your efforts and support
for CFS<br>
> >>>> development activity. I agree with you that any existing<br>
> technology<br>
> >>>> that is potentially a good fit for what we are trying to<br>
> accomplish<br>
> >>>> with CFS should be considered and discussed in details. I
am happy<br>
> >> to<br>
> >>>> hear that Apple is open to contributing their Spliced
Font Format<br>
> as<br>
> >> a<br>
> >>>> basis for CFS effort, and that they are open to adding
support for<br>
> >>>> additional elements or attributes.<br>
> >>>>>> However, from the AHG perspective - in order to
successfully<br>
> >>>> evaluate any and all candidate technologies, and
determine and<br>
> >> finalize<br>
> >>>> the set of tags, elements and arguments needed to fulfill
the<br>
> stated<br>
> >>>> goals it would be both useful and necessary to create a
list of<br>
> >>>> requirements we need to address. The requirements, and
the open<br>
> Call<br>
> >>>> for Proposals that will follow, would allow us to make
sure that<br>
> we:<br>
> >>>>>> - have a strong foundation for evaluating
candidate technologies<br>
> >>>> (such as Apple's Spliced Font Format, and maybe other
solutions,<br>
> >>>> including what AHG came up with during the exploration
stage), and<br>
> >>>>>> - develop a final solution that would fully
satisfy the stated<br>
> >>>> requirements, possibly by combining the best of all
proposals we<br>
> >> will<br>
> >>>> have submitted in response to CFP. (It could be that we
end up<br>
> >> taking<br>
> >>>> one particular solution as a basis and adding features
from other<br>
> >>>> solutions we discussed earlier - at this point I am
reluctant to<br>
> try<br>
> >>>> and predict the outcome of this effort.)<br>
> >>>>>><br>
> >>>>>> I also agree with Ken that CFS should be able to
serve both as a<br>
> >>>> composite font and as a fallback font mechanism. Nesting
and<br>
> >> recursion<br>
> >>>> can be allowed if necessary, but, again - this is
something we as<br>
> >> the<br>
> >>>> AHG will determine in the process of finalizing CFS
requirements.<br>
> >>>>>><br>
> >>>>>> Thank you and best regards,<br>
> >>>>>> Vladimir<br>
> >>>>>><br>
> >>>>>> P.S. I know some of you may wonder why Call for
Proposals would<br>
> >>>> even be necessary after all the efforts we, as the AHG,
put in<br>
> place<br>
> >> to<br>
> >>>> engage industry experts and invite them to join the
group. Yes, we<br>
> >> made<br>
> >>>> a concerted effort to make public aware of this activity
by<br>
> >>>> distributing the information in all relevant public
forums;<br>
> however,<br>
> >>>> the ISO process requires that public Call for Proposal
should be<br>
> >> issued<br>
> >>>> to insure that all interested parties are notified about
this<br>
> >> activity<br>
> >>>> through the official channels. In the end, it will only
help us<br>
> >> ensure<br>
> >>>> that we have the best pool of contributors to this
activity, even<br>
> if<br>
> >>>> the CFP itself doesn't bring 'new' proposals for
consideration.<br>
> >>>>>><br>
> >>>>>>> -----Original Message-----<br>
> >>>>>>> From: <a
href="mailto:mpeg-OTspec%40yahoogroups.com">mpeg-OTspec@yahoogroups.com</a> [mailto:mpeg-<br>
> >>>> <a href="mailto:OTspec%40yahoogroups.com">OTspec@yahoogroups.com</a>]<br>
> >>>>>>> On Behalf Of Ken Lunde<br>
> >>>>>>> Sent: Monday, February 01, 2010 12:29 PM<br>
> >>>>>>> To: <a
href="mailto:mpeg-OTspec%40yahoogroups.com">mpeg-OTspec@yahoogroups.com</a><br>
> >>>>>>> Cc: David Lemon<br>
> >>>>>>> Subject: Re: [mpeg-OTspec] AHG on Font Format
Kick-off<br>
> >>>>>>><br>
> >>>>>>> Vladimir,<br>
> >>>>>>><br>
> >>>>>>> I am very glad to see that WG11 is pushing us
toward a<br>
> standard.<br>
> >>>>>>><br>
> >>>>>>> With that said, the highest priority for the
AHG, in my<br>
> opinion,<br>
> >>>> is to<br>
> >>>>>>> determine whether Apple's "Spliced Font
Format" is suitable as<br>
> >> the<br>
> >>>>>>> basis for CFS. Apple confirmed that they are
open to this, and<br>
> >>>> they are<br>
> >>>>>>> also open to adding support for any
additional elements or<br>
> >>>> attributes,<br>
> >>>>>>> as long as they are considered optional. (The
vast majority of<br>
> >>>> elements<br>
> >>>>>>> and attributes are optional, so I don't
anticipate any issues.)<br>
> >>>>>>><br>
> >>>>>>> To help with this effort, please reference/re-read
my<br>
> 01/15/2010<br>
> >>>> email<br>
> >>>>>>> to the AHG that summarized Apple's Spliced
Font Format.<br>
> >>>>>>><br>
> >>>>>>> Secondly, I once brought up the issue of
nesting in the context<br>
> >> of<br>
> >>>> CFS,<br>
> >>>>>>> and stated that it should not be allowed due
to recursion and<br>
> >>>>>>> complexity issues. However, I now believe
that this should be<br>
> >>>> allowed<br>
> >>>>>>> in a specific context, because I believe that
we can now<br>
> >>>> distinguish<br>
> >>>>>>> CFS objects that serve as composite fonts
versus as fallback<br>
> >>>> fonts. Let<br>
> >>>>>>> me explain.<br>
> >>>>>>><br>
> >>>>>>> CFS objects can serve two main purposes or
functions,<br>
> >> specifically<br>
> >>>> as<br>
> >>>>>>> composite fonts or as fallback fonts. I
started going into this<br>
> >>>>>>> distinction in my 01/08/2010 post to the
mailing list.<br>
> >>>> Specifically, a<br>
> >>>>>>> CFS object functioning as a composite font
requires a unique<br>
> >> name,<br>
> >>>>>>> meaning a name that is unique from any
installed font, and<br>
> unique<br>
> >>>> from<br>
> >>>>>>> any other CFS object that is functioning as a
composite font.<br>
> >>>> However,<br>
> >>>>>>> a CFS object that functions as a fallback
font takes on the<br>
> name<br>
> >>>> of an<br>
> >>>>>>> existing font, which may be a standard font
or potentially a<br>
> CFS<br>
> >>>> object<br>
> >>>>>>> that functions as a composite font. This
means that CFS-savvy<br>
> >> OSes<br>
> >>>> and<br>
> >>>>>>> applications need to be prepared to deal with
a CFS object and<br>
> an<br>
> >>>>>>> installed font with the same name, and to
prioritize the CFS<br>
> >>>> object for<br>
> >>>>>>> obvious reasons.<br>
> >>>>>>><br>
> >>>>>>> If you consider how fallback fonts work
today, they take on the<br>
> >>>> name of<br>
> >>>>>>> an existing font resource, and describe
composite font-like<br>
> >>>> behavior,<br>
> >>>>>>> such as referencing other font resources to
provide glyphs for<br>
> >>>>>>> characters that are not supported by the
parent font resource.<br>
> >>>>>>><br>
> >>>>>>> Getting back to the nesting of CFS objects, I
now believe that<br>
> >>>> this can<br>
> >>>>>>> be allowed in CFS objects as long as what is
being nested is a<br>
> >> CFS<br>
> >>>>>>> object that is functioning as a composite
font. Furthermore, I<br>
> >>>> propose<br>
> >>>>>>> that the nesting depth should be one, meaning
a top-level CFS<br>
> >>>> object<br>
> >>>>>>> that functions as a fallback font can
reference one or more CFS<br>
> >>>> objects<br>
> >>>>>>> that function as composite fonts, but that
those "nested" CFS<br>
> >>>> objects<br>
> >>>>>>> that function as composite fonts cannot
reference any CFS<br>
> objects<br>
> >>>>>>> themselves.<br>
> >>>>>>><br>
> >>>>>>> Regards...<br>
> >>>>>>><br>
> >>>>>>> -- Ken<br>
> >>>>>>><br>
> >>>>>>> On 2010/01/28, at 12:39, Levantovsky,
Vladimir wrote:<br>
> >>>>>>><br>
> >>>>>>>><br>
> >>>>>>>> Dear AHG,<br>
> >>>>>>>><br>
> >>>>>>>><br>
> >>>>>>>> First of all, I'd like to welcome many
new members who have<br>
> >>>> recently<br>
> >>>>>>> joined the group - just for the past couple
of weeks our group<br>
> >>>> grew<br>
> >>>>>>> stronger by 20+ members.<br>
> >>>>>>>><br>
> >>>>>>>> At this time, the mandate for the AHG has
been extended with<br>
> new<br>
> >>>> work<br>
> >>>>>>> items - to produce the report summarizing the
results of the<br>
> >>>>>>> exploration activities and to propose and
develop a timeline<br>
> for<br>
> >>>> WG11<br>
> >>>>>>> to achieve stated goals of CFS
standardization.<br>
> >>>>>>>><br>
> >>>>>>>> The timeline should include the following
steps that are part<br>
> of<br>
> >>>> the<br>
> >>>>>>> ISO standards development process:<br>
> >>>>>>>><br>
> >>>>>>>> - Finalization of complete list of
requirements for Composite<br>
> >>>>>>> Font Standard - these should include any and
all features that<br>
> we<br>
> >>>>>>> believe should be part of the CFS (expected
to be finished by<br>
> the<br>
> >>>> next<br>
> >>>>>>> WG11 meeting in April 2010);<br>
> >>>>>>>><br>
> >>>>>>>> - Creation and publication of the Call
for Proposals for<br>
> >>>>>>> either existing or developing technical
solutions that would<br>
> >>>> address<br>
> >>>>>>> indentified list of requirements.<br>
> >>>>>>>><br>
> >>>>>>>> - Review and analysis of responses to the
Call for Proposal,<br>
> >>>>>>> and publication of a working draft
specification;<br>
> >>>>>>>><br>
> >>>>>>>> - Creation of the Committee Draft
(Proposed Draft Amendment if<br>
> >>>>>>> applicable);<br>
> >>>>>>>><br>
> >>>>>>>> - Final Committee Draft ;<br>
> >>>>>>>><br>
> >>>>>>>> - Final Draft International Standard.<br>
> >>>>>>>><br>
> >>>>>>>> As part of the requirements work, I
suggest that we should<br>
> >>>> identify<br>
> >>>>>>> and document both features that are already
supported by known<br>
> /<br>
> >>>>>>> existing technical solutions (such as
features proposed by<br>
> >> Adobe),<br>
> >>>> as<br>
> >>>>>>> well as features / capabilities implemented
in Apple's Spliced<br>
> >>>> Font<br>
> >>>>>>> format and other technologies.<br>
> >>>>>>>><br>
> >>>>>>>> We should also review and discuss the
text of the draft<br>
> >>>> corrigendum<br>
> >>>>>>> for ISO OFF standard that was prepared at the
WG11 meeting last<br>
> >>>> week.<br>
> >>>>>>> If there are any changes or corrections that
need to be made -<br>
> we<br>
> >>>>>>> should review them and bring to the attention
of the respective<br>
> >>>>>>> National Bodies to be included as part of the
ballot comments.<br>
> I<br>
> >>>> have<br>
> >>>>>>> uploaded the draft to the AHG files.<br>
> >>>>>>>><br>
> >>>>>>>><br>
> >>>>>>>><br>
> >>>>>>>> Thank you,<br>
> >>>>>>>><br>
> >>>>>>>> Vladimir<br>
> >>>>>>>><br>
> >>>>>>>><br>
> >>>>>>>><br>
> >>>>>>>><br>
> >>>>>>>><br>
> >>>>>>>><br>
> >>>>>>>><br>
> >>>>>>><br>
> >>>>>>><br>
> >>>>>>><br>
> >>>>>>> ------------------------------------<br>
> >>>>>>><br>
> >>>>>>> Yahoo! Groups Links<br>
> >>>>>>><br>
> >>>>>>><br>
> >>>>>>><br>
> >>>>><br>
> >>>>> <br>
> >>><br>
> ><o:p></o:p></p>
</div>
<div>
<p class=MsoNormal style='background:white'><span style='color:white'><o:p></o:p></span></p>
</div>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
</div>
</body>
</html>