<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:x="urn:schemas-microsoft-com:office:excel" xmlns:p="urn:schemas-microsoft-com:office:powerpoint" xmlns:a="urn:schemas-microsoft-com:office:access" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:z="#RowsetSchema" xmlns:b="urn:schemas-microsoft-com:office:publisher" xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet" xmlns:c="urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc="urn:schemas-microsoft-com:office:odc" xmlns:oa="urn:schemas-microsoft-com:office:activation" xmlns:html="http://www.w3.org/TR/REC-html40" xmlns:q="http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc="http://microsoft.com/officenet/conferencing" xmlns:D="DAV:" xmlns:Repl="http://schemas.microsoft.com/repl/" xmlns:mt="http://schemas.microsoft.com/sharepoint/soap/meetings/" xmlns:x2="http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ppda="http://www.passport.com/NameSpace.xsd" xmlns:ois="http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir="http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:dsp="http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc="http://schemas.microsoft.com/data/udc" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:sub="http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec="http://www.w3.org/2001/04/xmlenc#" xmlns:sp="http://schemas.microsoft.com/sharepoint/" xmlns:sps="http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:udcs="http://schemas.microsoft.com/data/udc/soap" xmlns:udcxf="http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p="http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf="http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss="http://schemas.microsoft.com/office/2006/digsig-setup" xmlns:dssi="http://schemas.microsoft.com/office/2006/digsig" xmlns:mdssi="http://schemas.openxmlformats.org/package/2006/digital-signature" xmlns:mver="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels="http://schemas.openxmlformats.org/package/2006/relationships" xmlns:spwp="http://microsoft.com/sharepoint/webpartpages" xmlns:ex12t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:pptsl="http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" xmlns:spsl="http://microsoft.com/webservices/SharePointPortalServer/PublishedLinksService" xmlns:Z="urn:schemas-microsoft-com:" xmlns:st="" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<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:#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.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:9.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:10.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:3.0pt;
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:7.5pt;
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.EmailStyle34
{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:1301836854;
mso-list-template-ids:945432572;}
@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="#1E66AE" vlink="#1E66AE">
<div class=Section1>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Thank you, Ken! <o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>And if you think the bottle of Amarula will help the work go
smoothly (I believe it should :) – even better. You get things done while
having fun – what else one can wish for before holiday break.<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'>Happy Thanksgiving!<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Vlad<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> Friday, November 20, 2009 2:44 PM<br>
<b>To:</b> mpeg-OTspec@yahoogroups.com<br>
<b>Subject:</b> Re: [mpeg-OTspec] Re: A path through the thicket<o:p></o:p></span></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal> <o:p></o:p></p>
<div id=ygrp-mlmsg>
<div id=ygrp-msg>
<div id=ygrp-text>
<p style='margin-bottom:12.0pt'>Vladimir,<br>
<br>
I will try to put together a list/summary of the tags, elements, and <br>
attributes that have been discussed, either over the weekend, or <br>
before the Thanksgiving Day holiday break. I opened a bottle of <br>
Amarula that may help me with this task. :-)<br>
<br>
Regards...<br>
<br>
-- Ken<br>
<br>
On 2009/11/17, at 7:21, Levantovsky, Vladimir wrote:<br>
<br>
> I can help with editorial work to create a working draft of the <br>
> specification. But I think that as a pre-requisite we need to create <br>
> a list of tags / elements / attributes and their descriptions that <br>
> we agree to be part of the Composite Fonts draft specification. <br>
> We've had some limited discussions about it in the past - it may <br>
> make sense to try to review and summarize them in a single list <br>
> (either as an informal AHG document or in the email) that would be <br>
> our starting point towards the working draft.<br>
> Vladimir<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: Tuesday, November 17, 2009 9:39 AM<br>
>> To: <a href="mailto:mpeg-OTspec%40yahoogroups.com">mpeg-OTspec@yahoogroups.com</a><br>
>> Subject: Re: [mpeg-OTspec] Re: A path through the thicket<br>
>><br>
>> All,<br>
>><br>
>> In the spirit of trying to move this project forward, and given that<br>
>> there is overwhelming agreement that it is best to defer further<br>
>> discussion in favor of working on a draft specification, is there<br>
>> anyone who is specifically tasked with writing the draft <br>
>> specification?<br>
>><br>
>> Regards...<br>
>><br>
>> -- Ken<br>
>><br>
>> On 2009/11/02, at 16:23, Daniel Strebe wrote:<br>
>><br>
>>><br>
>>><br>
>>> Vladimir:<br>
>>><br>
>>> Thank you for proposing we defer further discussion in favor of<br>
>>> working on the specification. I think that is a wise proposal. We<br>
>>> can proceed much of the way on what we already know, especially<br>
>>> since we all seem to agree on what a complete implementation
should<br>
>>> look like. We may digress into exploratory phases and dead ends<br>
>>> along the way, but that would be preferable to choosing an<br>
>>> unfavorable policy and adhering to it just on ideological grounds.
I<br>
>>> certainly agree we will be better informed later than now.<br>
>>><br>
>>> Regards,<br>
>>><br>
>>> Daniel "daan" Strebe<br>
>>> Senior Computer Scientist<br>
>>> Adobe Systems Incorporated<br>
>>><br>
>>><br>
>>> On 09/10/30 2:09, "Levantovsky, Vladimir"<br>
>> <<a href="mailto:Vladimir.Levantovsky%40MonotypeImaging.com">Vladimir.Levantovsky@MonotypeImaging.com</a><br>
>>>> wrote:<br>
>>><br>
>>> Daniel, all,<br>
>>><br>
>>> The MPEG summary document I submitted earlier outlines few use
cases<br>
>>> where compliance to the Composite Fonts specification (and full<br>
>>> interoperability between different clients or components of the<br>
>>> system) would be critical to achieve the stated goals. Among them,
I<br>
>>> believe that the use case entitled "Interactive Rich Media<br>
>>> Environment" would probably be a "train wreck"
scenario if there is<br>
>>> a lack of interoperability between different tools that are used
for<br>
>>> media content creation, multiple different implementations from<br>
>>> different vendors and Composite Fonts sourced from different<br>
>>> foundries. This use case represents real-life scenario that is<br>
>>> considered by the industry - we can discuss this case in more<br>
>>> details to flesh out some of the details if necessary.<br>
>>><br>
>>> However, I don't want this discussions to stifle the progress of
the<br>
>>> development of the specification itself. I strongly believe that<br>
>>> once we have the draft of the specification ready we will be
better<br>
>>> equipped to evaluate the complexity of future implementations, and<br>
>>> make educated decisions on whether mandating a particular set of<br>
>>> tools would make any significant impact on the overall cost and<br>
>>> complexity of the Composite Font solution. I would like to
encourage<br>
>>> all AHG participants to contribute their ideas and suggestions of<br>
>>> the tools (tags, elements, attributes, and their brief
descriptions)<br>
>>> that should be part of the CF solution.<br>
>>><br>
>>> Thank you and regards,<br>
>>> Vladimir<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> From: Daniel Strebe [mailto:<a href="mailto:dstrebe%40adobe.com">dstrebe@adobe.com</a>]<br>
>>> Sent: Wednesday, October 21, 2009 3:54 PM<br>
>>> To: Levantovsky, Vladimir; <a
href="mailto:mpeg-OTspec%40yahoogroups.com">mpeg-OTspec@yahoogroups.com</a><br>
>>> Subject: Re: A path through the thicket<br>
>>><br>
>>><br>
>>> Vladimir,<br>
>>><br>
>>> Thanks for the comments. I think we need to talk about specific<br>
>>> scenarios in order to make progress; we can only go so far on<br>
>>> principles when ultimately we must deal with reality. May I ask
you<br>
>>> to describe what you consider to be a "train-wreck"
scenario in my<br>
>>> advocacy? That would force me to see the error of my ways or allow<br>
>>> me to clarify misunderstandings or to correct mistaken inferences.<br>
>>> It will give us all a chance to contrast the pros and cons of the<br>
>>> descriptive versus prescriptive models as they apply to realistic<br>
>>> scenarios.<br>
>>><br>
>>> As for whether this committee is an actor or not is merely a
matter<br>
>>> of reasonable differences of definition unrelated to whatever we<br>
>>> really are. It is what we really are that matters. It can be
helpful<br>
>>> to think of us as actors, since our intent will persist in the<br>
>>> specification. Likewise it can be helpful to think of fonts as<br>
>>> tools, for example, even though I categorized them as resources. I<br>
>>> would prefer not to worry too much about arbitrary
categorizations.<br>
>>> In particular, we would be wise not to let what we call something<br>
>>> influence our understanding of what it is, but, rather, let our<br>
>>> understanding of what it is influence what we call it.<br>
>>><br>
>>> Thanks & regards,<br>
>>><br>
>>> Daniel "daan" Strebe<br>
>>> Senior Computer Scientist<br>
>>> Adobe Systems Incorporated<br>
>>><br>
>>><br>
>>> On 09/10/21 8:00, "Levantovsky, Vladimir"<br>
>> <<a href="mailto:vladimir.levantovsky%40monotypeimaging.com">vladimir.levantovsky@monotypeimaging.com</a><br>
>>>> wrote:<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> Daniel, Leonardo, all,<br>
>>><br>
>>> I'd like to thank Daniel for his efforts and dedication to<br>
>>> developing the Composite Fonts specification; however, I disagree<br>
>>> with some of the Daniel's definition of the actors and tools, and<br>
>>> believe that certain clarifications would help to further
understand<br>
>>> the realities we face with.<br>
>>><br>
>>> In my opinion, the most important aspect is to clearly understand<br>
>>> the relationship between different types of consumers of the<br>
>>> Composite Font specification and definition of the "consuming<br>
>>> author" as a category. While working on the Composite Fonts
Design<br>
>>> Philosophy and policies we acknowledged and agreed that deployment<br>
>>> environments are diverse and that public environments will need<br>
>>> explicit state to be defined while private (controlled)
environments<br>
>>> may need less explicit state than public. The definition of the<br>
>>> "consuming author", as presented by Daniel, seems to
address only<br>
>>> the latter (private, controlled environments) where the
"consuming<br>
>>> author" may indeed play different roles and be a content
creator,<br>
>>> content consumer and tool/implementation vendor at the same time.<br>
>>> However, in public environments this will rarely (if ever) be the<br>
>>> case, and the category of "consuming author" will
include<br>
>>> - composite font recipe creators,<br>
>>><br>
>>> - content creators,<br>
>>><br>
>>> - authoring tool vendors,<br>
>>><br>
>>> - developers of the consuming implementations (content<br>
>>> players,) and<br>
>>><br>
>>> - content consumers.<br>
>>><br>
>>><br>
>>> For these different and diverse categories of consuming authors to<br>
>>> interact successfully - tools for creating composite font recipes,<br>
>>> content authoring tools and content player implementations must be<br>
>>> conformant to the Composite Font specification to ensure that the<br>
>>> content, created using the intent expressed by a Composite Font<br>
>>> recipe, is presented to a content consumer in the same way as<br>
>>> envisioned by a content creator. This is why it is necessary for<br>
>>> public environments to strictly follow the recipe intent and to<br>
>>> mandate compliance between different consuming implementations.<br>
>>><br>
>>> I also disagree with Daniel on the inclusion of this AHG (or, in<br>
>>> general, a standard development body) as an actor. As soon as the<br>
>>> specification is finalized and approved, this AHG body will cease
to<br>
>>> exist and will never be in a position to govern the interpretation<br>
>>> or implementation details of the standard. Our responsibility is
to<br>
>>> ensure that the text of the specification we will have produced is<br>
>>> clear and unambiguous, and that all necessary resources (such as<br>
>>> conformance document and standardized test cases, if applicable)
are<br>
>>> available for implementers of the standard.<br>
>>><br>
>>> Thank you and regards,<br>
>>> Vladimir<br>
>>><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 Daniel Strebe<br>
>>> Sent: Tuesday, October 20, 2009 7:28 PM<br>
>>> To: <a href="mailto:leonardo%40chiariglione.org">leonardo@chiariglione.org</a>;
<a href="mailto:mpeg-OTspec%40yahoogroups.com">mpeg-OTspec@yahoogroups.com</a><br>
>>> Subject: Re: [mpeg-OTspec] Re: A path through the thicket<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> Leonardo:<br>
>>><br>
>>> Thank you for your continued interest in this discussion.<br>
>>><br>
>>> "Composite font recipe" is a formal text of observations
on how to<br>
>>> aggregate, or instructions for aggregating, multiple specific<br>
>>> "component fonts" to act as a single font of enhanced
capabilities.<br>
>>> A recipe adheres to the semantics and grammar (the "composite
font<br>
>>> specification") to be defined by this ad hoc committee.
Whether a<br>
>>> recipe should embody observations (description) or instructions<br>
>>> (prescription) is controversial in this discussion.<br>
>>><br>
>>> A "consuming author" is someone who creates content by
using a<br>
>>> composite font recipe (and presumably many other resources and<br>
>> tools).<br>
>>><br>
>>> "Recipe creator's intent" is the whatever the person who
wrote the<br>
>>> recipe intended by the recipe. The significance and scope of this<br>
>>> intent is controversial in this discussion. Simplistically, I aver<br>
>>> that the recipe creator's intent for dynamic circumstances cannot
be<br>
>>> embodied in a static recipe. I further aver that the recipe<br>
>>> creator's intent, insofar as there is one, may not reflect the<br>
>>> consuming author's needs or intent. Hence the intent should be<br>
>>> interpreted as a description or set of observations, with no need<br>
>>> for intervention by this committee. Vladimir's advocacy, as I<br>
>>> understand it, is that the intent should be interpreted as a<br>
>>> prescription, subject to exemptions specified by this committee.<br>
>>><br>
>>> To address your broader request, we have:<br>
>>><br>
>>> Resources<br>
>>> Component fonts (extant)<br>
>>> Composite font recipe<br>
>>> Composite font specification<br>
>>><br>
>>> Actors<br>
>>> Composite font recipe creator<br>
>>> Consuming author<br>
>>> This committee<br>
>>><br>
>>> Tools<br>
>>> Consuming implementation (that is, consuming composite font
recipes)<br>
>>> Producing implementation (that is, producing composite font<br>
>>> recipes)<br>
>>><br>
>>> Results<br>
>>> Content<br>
>>><br>
>>> I think everyone agrees on this description:<br>
>>><br>
>>> This committee defines composite font specification. Composite
font<br>
>>> recipe creator uses producing implementation to create composite<br>
>>> font recipe adhering to composite font specification. Consuming<br>
>>> implementation uses composite font specification to interpret<br>
>>> composite font recipe. Consuming author uses consuming<br>
>>> implementation to exploit composite font recipe's aggregation of<br>
>>> component fonts in order to create content.<br>
>>><br>
>>> The primary controversy seems to be over whether a composite font<br>
>>> recipe ought to be descriptive or prescriptive. I think most of
the<br>
>>> ancillary controversies arise out of that one. My claim is that<br>
>>> recipes can be purely descriptive without compromising<br>
>>> interoperability, and that designating them as descriptive brings<br>
>>> benefits of expressiveness, robustness, flexibility, ease of<br>
>>> authorship, ease of interpretation, clearer division of roles, and
a<br>
>>> simpler specification.<br>
>>><br>
>>> Regards,<br>
>>> - daan Strebe<br>
>>><br>
>>><br>
>>> On 09/10/03 1:27, "Leonardo Chiariglione"<br>
>>> <<a href="mailto:leonardo%40chiariglione.org">leonardo@chiariglione.org</a>>
wrote:<br>
>>><br>
>>> Daniel,<br>
>>> I have been trying to follow your terminology. I realise that in<br>
>>> your world this may be consolidated, but not in mine:<br>
>>> Recipe creator's intent<br>
>>> Consuming author<br>
>>> Composite font recipe<br>
>>> And others<br>
>>> In other words, I would like to have the complete "font"
value chain<br>
>>> outlined and defined. I think this would be useful to clarify what<br>
>>> is that the standard needs to do<br>
>>> Leonardo<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 Daniel Strebe<br>
>>> Sent: 01 October 2009 03:38<br>
>>> To: <a href="mailto:mpeg-OTspec%40yahoogroups.com">mpeg-OTspec@yahoogroups.com</a><br>
>>> Subject: [mpeg-OTspec] Re: A path through the thicket<br>
>>><br>
>>><br>
>>><br>
>>> Vladimir:<br>
>>><br>
>>> I appreciate the effort you put into these responses. I apologize<br>
>>> for this very lengthy response. Here is a synopsis for those who<br>
>>> need to ration their reading time:<br>
>>><br>
>>> 1. Rebuttal of the thesis that the situation with Web browsers<br>
>>> argues for more imperatives in this specification.<br>
>>> 2. Why we won't be able codify the useful possibilities for<br>
>>> composite fonts.<br>
>>> 3. Why the recipe creator's "intent" is not what is
important, but<br>
>>> rather the consuming author's intent that is important.<br>
>>> 4. A composite font recipe is not content, it is a resource;<br>
>>> therefore the requirement of fidelity to its instructions depends<br>
>>> upon context.<br>
>>> 5. Examples of composite font usage to clarify when fidelity is/<br>
>>> isn't useful.<br>
>>> 6. My interpretation of Vladimir's proposal, juxtaposed against my<br>
>>> proposal. (You might find this instructive.)<br>
>>> 7. More responses to specific arguments posed by Vladimir.<br>
>>> 8. A list of objections to Vladimir's proposal.<br>
>>> 9. Conclusions<br>
>>><br>
>>> 1. Browsers as an analogy to composite fonts<br>
>>><br>
>>> I do not agree with Vladimir's analysis of the situation with Web<br>
>>> browsers today or the failures of the W3C recommendations, and<br>
>>> therefore I do not agree with the conclusions Vladimir draws. The<br>
>>> World Wide Web was not conceived to deliver final-form
presentation.<br>
>>> We could go into great depth on this matter, but it is peripheral
to<br>
>>> the discussion, so I will leave it by averring that many Web<br>
>>> designer vexations arise out of the natural tension between their<br>
>>> need for design and the Web's need to deliver content on displays
of<br>
>>> unknown resolution and unknown color space, on devices of unknown<br>
>>> computational capacity, in unknown window sizes, and using
possibly<br>
>>> unavailable resources-like fonts - a problem that is still not<br>
>>> solved 15+ years later.<br>
>>><br>
>>> To a fair extent the reality of these unknowns forced
specifications<br>
>>> that allow choice in implementation along with soft failure. I do<br>
>>> not claim that no mistakes were made; I do not know enough about<br>
>>> those standards to know what mistakes were made and how grave. But<br>
>>> my understanding of their purpose does not match the premise of<br>
>>> Vladimir's argument well.<br>
>>><br>
>>> 2. On codifying useful possibilities for composite fonts<br>
>>><br>
>>> To return to my elaborate example, Marina's hypothetical problems<br>
>>> would not have been alleviated by "better" standards. It
is<br>
>>> pointless for Web browsers to implement typographical features
when<br>
>>> the designer's desired font generally isn't even available on the<br>
>>> viewing computer. A standard can't do anything about copyright<br>
>>> restrictions. If and when legal, commercial, and technical
remedies<br>
>>> arrive on the scene to deliver the fonts content designers want to<br>
>>> Web pages, then surely we will see browsers supporting typography<br>
>>> with ever greater sophistication.<br>
>>><br>
>>> Conversely, if standards had dictated such typographical<br>
>>> sophistication from the outset, despite its uselessness, the
barrier<br>
>>> to entering the browser market would have been higher, and
expensive<br>
>>> effort would have been diverted from more useful functionality<br>
>>> elsewhere. This is why I contrived such an elaborate scenario.<br>
>>> Marina's quandary arises from conditions that exist now. They did<br>
>>> not exist three years ago because there was no RIA framework for
her<br>
>>> to use. They probably will not exist three years from now because<br>
>>> better typography probably will arrive in browsers and RIA<br>
>>> frameworks once the type delivery service she subscribed to
becomes<br>
>>> commonplace.<br>
>>><br>
>>> Meanwhile, we, sitting here now comfortably at our computers<br>
>>> contemplating conditions as they exist now, will find ourselves<br>
>>> unable to enumerate all the uses people will find for composite<br>
>>> fonts even today, let alone five years from now. Therefore I do
not<br>
>>> understand why we should fossilize our ignorance in a
specification.<br>
>>> What we do know, or can puzzle through, is what kinds of things<br>
>>> people are likely to want to communicate with composite fonts.<br>
>>> Therefore we should provide a language for this communication -
but<br>
>>> we should leave the actions of the communicators up to those who<br>
>>> know what they are trying to achieve.<br>
>>><br>
>>> 3. Why the recipe creator's "intent" may not be
important, and what<br>
>> is<br>
>>><br>
>>> To address an implicit axiom in Vladimir's arguments, the intent
of<br>
>>> the composite font creator is not the only intent in play. What we<br>
>>> have been calling a consumer - because it consumes a composite
font<br>
>>> recipe - may also be a content author. This "consuming
author" has<br>
>>> an intent we know nothing about, but by definition creative forces<br>
>>> are in play. Whom are we helping if we stifle those creative
forces<br>
>>> by shoving them into the only channels we foresaw or that we felt<br>
>>> were "important"? To the human authoring that content,
our<br>
>>> specification means nothing and the composite font recipe means<br>
>>> opportunities. That human wants the software "she" is
using to do<br>
>>> what she expects it to do. How that software adapts an incoming<br>
>>> composite font recipe to its purposes is not our business. It is
not<br>
>>> even the business of the recipe creator. It is the business of the<br>
>>> creative mind operating the software because what comes out of
that<br>
>>> creative mind is or! iginal co ntent. The font is just a tool in<br>
>>> creating that content.<br>
>>><br>
>>> The consuming author has a reason for consuming composite fonts.<br>
>>> Therefore the consuming author must be interested in what a<br>
>>> composite font recipe has to say. That means the language the<br>
>>> composite font speaks must be clear, but it does not mean the<br>
>>> consuming author is interested in everything the recipe has to
say.<br>
>>> A font is not content. It is a tool or a resource. It may contain<br>
>>> elements extraneous to the content for which it is being
exploited.<br>
>>> We must not confuse ourselves into lumping composite font recipes<br>
>>> into the same category as MPEG videos or PDF, where fidelity of<br>
>>> content must be preserved because fidelity of content is the <br>
>>> purpose.<br>
>>><br>
>>> A font contains instructions. The purpose of the instructions is
for<br>
>>> the font to be used usefully. What is useful varies from<br>
>>> circumstance to circumstance. The circumstances are innumerable.<br>
>>><br>
>>> 4. On fidelity to the recipe, and when it is/isn't important<br>
>>><br>
>>> I do not discount the need for fidelity, but we need to be clear<br>
>>> about what kind of fidelity we are talking about and why it is<br>
>>> important. If Vladimir's argument is that consumers must retain
the<br>
>>> fidelity of the recipe creator's intent, then I completely
disagree.<br>
>>> For one thing, it's frankly none of the recipe creator's business<br>
>>> how the tool "he" created gets used insofar as other
interests are<br>
>>> not harmed. For another, the creator will be unable to express all<br>
>>> the ways he might be willing for the recipe to be used, both
because<br>
>>> we will not provide a language so complicated and because creators<br>
>>> won't want to burden themselves with the infinite permutations of<br>
>>> pedantic intent that consumers might find useful. Both the creator<br>
>>> and the consumer would wonder what the point is, and the creator
is<br>
>>> probably even less likely to envision all the useful scenarios
than<br>
>>> we are. Just because a creator forgot to mention that he's fine
with<br>
>>> his composite font being used just for i! ts glyph mappings is no<br>
>>> reason someone shouldn't use it for that.<br>
>>><br>
>>> When does fidelity to the recipe creator's intent need to be<br>
>>> preserved? When the recipe itself becomes part of the instructions<br>
>>> for reproducing content. In other words, when the consuming
author's<br>
>>> content relies on the composite font recipe for whatever form of<br>
>>> fidelity it needs. Since what is meaningful to preserve varies
from<br>
>>> content category to content category, and since neither we nor the<br>
>>> recipe creator knows the consuming author's intent, it follows
that<br>
>>> we cannot be in the business of dictating what portions of a<br>
>>> composite font recipe a consuming author's software is allowed to<br>
>>> honor or discard.<br>
>>><br>
>>> 5. Examples of when fidelity to a recipe is/isn't important<br>
>>><br>
>>> Example A, page layout software: In page layout software, the<br>
>>> composite font recipe will be relied upon to create consuming<br>
>>> author's content. Moreover this reliance likely extends to the
most<br>
>>> minute details of glyph placement. Most content authors will
expect<br>
>>> a composite font to work the same regardless of what page layout<br>
>>> software or word processor they use. Because page layout
software's<br>
>>> purpose is typographic fidelity, and because the composite font<br>
>>> recipe's creator is likely to know more about the typography of
the<br>
>>> fonts in the recipe than the authors of the page layout software<br>
>>> (who probably don't even know about the component fonts<br>
>>> specifically), a normal implementation would be a complete one.<br>
>>><br>
>>> In practice, we are likely to see page layout software either not<br>
>>> implement composite fonts or else implement the specification in
its<br>
>>> entirety. Partial implementations, at least as far as body text<br>
>>> goes, would confuse content authors and reflect unfavorably on the<br>
>>> page layout software publisher. They could result in imported<br>
>>> content getting formatted differently from the original. Still,<br>
>>> there may be interesting uses for partial implementations outside
of<br>
>>> body text.<br>
>>><br>
>>> Example B, markup languages: In markup languages that include<br>
>>> presentation semantics, some kinds of formatting are provided for<br>
>>> while still conforming to environmental constraints. Normally this<br>
>>> means line breaks are absent in the content, but some kinds of<br>
>>> character and block formatting are present. Their presence ranges<br>
>>> from fairly abstract ("header") to fairly concrete
("underline"),<br>
>>> depending upon the particular attribute and and upon the
particular<br>
>>> markup language. Some provide for font categories
("Serif"); some<br>
>>> provide for font names.<br>
>>><br>
>>> A composite font could provide for typographic and formatting<br>
>>> control beyond the scope or intent of a renderer of the markup<br>
>>> language. One could argue for nearly any range of composite font<br>
>>> support in this context. If the renderer is a markup editor in<br>
>>> "source" view, typographic needs might not exist. A
composite font<br>
>>> might get selected for some purely semantic reason, such as glyph<br>
>>> complement, with no intent or need for typographic control because<br>
>>> the editor's reason for choosing the composite font is only to be<br>
>>> able to render any glyph expressed within literal strings.<br>
>>><br>
>>> If the markup editor provides a "Preview" mode to see
the content<br>
>>> formatted, how much typography the mode should enable depends on<br>
>>> what expected target systems will be able to render. If the markup<br>
>>> language does not even provide a mechanism to designate the
specific<br>
>>> font for rendering, then clearly the "preview" amounts
to little<br>
>>> more than a "mock-up", and the need to support various
features of<br>
>>> composite fonts becomes highly questionable. Transmission fidelity<br>
>>> means nothing because the font is not part of the markup.<br>
>>><br>
>>> If, on the other hand, the specific font can be declared in the<br>
>>> markup, then the markup editor ought to enable any typographic<br>
>>> features that do not conflict with the markup itself. We are in no<br>
>>> position to decide what that means in the general case. We may
want<br>
>>> the rendering engine to honor the small-caps instructions in the<br>
>>> composite font recipe, for example, but the markup language or the<br>
>>> style guide for the renderer may dictate that all-caps must be
used.<br>
>>> Or we may declare that a compliant renderer honor the glyph
mappings<br>
>>> of the composite font, but this markup includes mathematical<br>
>>> expressions. The renderer is happy to use the composite font
recipe<br>
>>> for text, but it knows a lot more about mathematics than we do and<br>
>>> than the generic markup editor did, so it always renders formulæ<br>
>>> according to a specific font it knows behaves according to its own<br>
>>> precise layout needs.<br>
>>><br>
>>> It should be clear from these examples, including the earlier<br>
>>> elaborate example of Marina and her cartographic project, that we<br>
>>> can contrive plausible subsets of functionality ad nauseum, and<br>
>>> therefore that we will never anticipate all the diverse,
legitimate<br>
>>> uses of composite fonts.<br>
>>><br>
>>> 6. What the contrasting proposals look like<br>
>>><br>
>>> What Vladimir's proposal looks like to me:<br>
>>><br>
>>> Recipe creator states "his" intent:<br>
>>> 1. You must shift baseline of Font A 6 design units upward<br>
>>> with respect to Font B.<br>
>>> 2. You must shear glyphs of Font C 4° rightward from base to<br>
>>> top with respect to other fonts in the recipe.<br>
>>> 3. You must map Unicode range W-X to Font C for Latin script,<br>
>>> X+1-Y to Font D for Chinese, Y+1-Z to Font E for mathematical<br>
>>> symbols...<br>
>>><br>
>>> We inject our intent here:<br>
>>> 1. You must implement.<br>
>>> 2. You may ignore if you declare yourself to be a partially<br>
>>> compliant renderer according to Compliant Subset D.<br>
>>> 3. You may ignore if you are a Latin-script-only renderer<br>
>>> according to Compliant Subset E.<br>
>>><br>
>>> Consumer compares her intent against recipe creator's intent and<br>
>>> our intent:<br>
>>> 1. I am in violation because I do not need to shift baselines<br>
>>> because I do not mix component fonts on a single line.<br>
>>> 2. I need the design characteristics to match, so I shear<br>
>>> glyphs.<br>
>>> 3. I am in violation because I always use Cambria Math for<br>
>>> mathematical symbols because I can't lay out equations reliably<br>
>>> using arbitrary fonts.<br>
>>><br>
>>> with the result that the recipe creator was unable to state his
real<br>
>>> intent because his real intent was merely to describe how the<br>
>>> components of the composite font can work together to achieve the<br>
>>> illusion of a single font, not to dictate what features of the<br>
>>> composite font must be used, since he has no idea what the
consumer<br>
>>> needs anyway. The consumer, whose implementation suits her
purposes<br>
>>> precisely, does not comply with any recognized subset. Output<br>
>>> downstream gives idiosyncratic results because the specification<br>
>>> requires her to pass through the composite font recipe unmodified<br>
>>> (in order to honor the recipe creator's intent and ignore her use
of<br>
>>> it).<br>
>>><br>
>>> What my proposal looks like to me:<br>
>>><br>
>>> Recipe creator states his observations that:<br>
>>> 1. Shifting baseline of Font A 6 design units upward with<br>
>>> respect to Font B gives uniform baselines.<br>
>>> 2. Shearing glyphs of Font C 4° rightward from base to top<br>
>>> with respect to other fonts in the recipe gives matching oblique<br>
>>> angles.<br>
>>> 3. Mapping Unicode range W-X to Font C gives correct<br>
>>> results for Latin scripts.<br>
>>> Mapping X+1-Y to Font D for Chinese gives correct results<br>
>>> for simplified Chinese.<br>
>>> Mapping Y+1-Z to Font E gives correct results for<br>
>>> mathematical symbols.<br>
>>> ...<br>
>>><br>
>>> We inject no intent.<br>
>>><br>
>>> Consumer compares her intent against recipe creator's<br>
>>> observations and our intent:<br>
>>> 1. I do not need to shift baselines because I never mix<br>
>>> composite font components on a line.<br>
>>> 2. I need the design characteristics to match, so I shear<br>
>>> glyphs.<br>
>>> 3. I always use Cambria Math for mathematical symbols because<br>
>>> it is impossible to lay out equations reliably using arbitrary <br>
>>> fonts.<br>
>>><br>
>>> with the result that this consumer got exactly what she wanted<br>
>>> without violating the specification, without violating the
creator's<br>
>>> intent, and without harming anyone's interests. All output<br>
>>> downstream from her deployment behaves correctly because she only<br>
>>> passed through the portion of the composite font recipe that she<br>
>>> actually deployed... or because her output is in final-form, not<br>
>>> dependent upon anything external to the final-form document.<br>
>>><br>
>>> 7. Responses to some specific arguments posed by Vladimir<br>
>>><br>
>>> I sympathize with Vladimir's argument that implementers will look
to<br>
>>> the specification for guidance even when they only implement part
of<br>
>>> it. However, I am unable to come up with realistic scenarios that<br>
>>> require "interoperability" at partial levels. In
scenarios I have<br>
>>> managed to contrive, partial implementations are generally dead-end<br>
>>> consumers or else their output would always be final-form. Neither<br>
>>> scenario requires adherence to some canonized subset, nor does it<br>
>>> seem like the situation would confuse implementers, since they
have<br>
>>> a clear idea of what they need. To ensure fidelity downstream when<br>
>>> exporting its content, Partial Implementation A should simply
excise<br>
>>> those portions of a recipe that it did not use. (I would go so far<br>
>>> as to say we should require this.) This way any consuming<br>
>>> implementation that is a superset of Partial Implementation A
(such<br>
>>> as a full implementation) will deliver fidelity to the content<br>
>>> created by Partial Implementation A. The odds th! at downst ream<br>
>>> consumer Partial Implementation B is both a partial implementation<br>
>>> and carries the similar needs and intent as Partial Implementation
A<br>
>>> is remote unless the two already know about each other in some<br>
>>> private or semi-private contract. Therefore our intervention adds<br>
>>> little value, if any.<br>
>>><br>
>>> For example, Vladimir notes "...We can specify one subset
that would<br>
>>> be sufficient for authors creating content utilizing simple
scripts<br>
>>> only". But if we look at the sorts of functionality we
propose for<br>
>>> composite fonts, none of it really applies to simple versus
complex<br>
>>> scripts. Whether a given implementation will work with complex<br>
>>> scripts depends on its general font and language handling
machinery,<br>
>>> not upon whether it supports some feature of composite fonts.<br>
>>> Meanwhile "simple script" support means different things
to<br>
>>> different layout engines. We are not going to convince an<br>
>>> established layout engine to improve or change its implementation
of<br>
>>> "simple scripts" just to gain "compliance"
with whatever we decide<br>
>>> is meaningful - particularly when our "requirements"
actually turn<br>
>>> out to be orthogonal to executing the instructions of a composite<br>
>>> font recipe.<br>
>>><br>
>>> Vladimir states, "[Consumers] must be able to scale fonts
and/or<br>
>>> individual glyphs and their metrics to ensure correct layout... I<br>
>>> believe that since all existing font engines today support
scalable<br>
>>> fonts and are capable to do this, the requirement does not present<br>
>>> any additional burden on implementations." To which I respond
that<br>
>>> code must be written to interpret the semantics of the scaling,<br>
>>> adjust positioning, and to instruct the font engine to perform the<br>
>>> scaling - and even then coding is only a portion of the cost of<br>
>>> deploying an implementation. Meanwhile, if such scaling is<br>
>>> irrelevant to the content the consuming author creates, who
benefits<br>
>>> by requiring it?<br>
>>><br>
>>> 8. Ten objections to Vladimir's proposal<br>
>>><br>
>>> To reiterate: I am happy for this committee to prepare a standard<br>
>>> for a "complete" implementation. I think that will be of
the most<br>
>>> interest to the most people, and it covers the most demanding
case:<br>
>>> typographic fidelity. I am not at all happy to canonize some
subset<br>
>>> of partial implementations. My objections are:<br>
>>> 1. We will unable to enumerate all the useful possibilities.<br>
>>> 2. We do not have the resources to labor over those possibilities<br>
>>> we would come up with.<br>
>>> 3. We do not have the wisdom to winnow down the possibilities<br>
>>> into some manageable collection that suits (almost) all needs.<br>
>>> 4. Whatever list we might come up with would be fragile in the<br>
>>> face of technology and market forces.<br>
>>> 5. Any given partial implementation will not have a large enough<br>
>>> constituency for us to expend such effort on.<br>
>>> 6. Canonized subsets distract and dilute our ability to encourage<br>
>>> and "enforce" the complete typographic case.<br>
>>> 7. We will invite confusion over the meaning of recipes by<br>
>>> condoning a special subset of exceptions to their imperatives.<br>
>>> 8. By considering the recipe's instructions as imperatives at<br>
>>> all, we exclude useful possibilities the recipe otherwise implies.<br>
>>> 9. We will stifle innovate uses which themselves do not harm<br>
>>> other interests.<br>
>>> 10. We will be injecting our own intent into areas we have no<br>
>>> business doing so.<br>
>>><br>
>>> 9. In conclusion<br>
>>><br>
>>> We should allow partial implementations to support those aspects
of<br>
>>> the specification that they need. We should instruct that partial<br>
>>> implementations must alter the recipes they consume to reflect
their<br>
>>> requirements for fidelity in the content they generate. We should<br>
>>> instruct anyone intending for broad interoperability to implement<br>
>>> the complete specification. We should not add to the specification<br>
>>> such requirements for font feature support that are orthogonal to<br>
>>> the business of executing the instructions in font recipes.<br>
>>><br>
>>> Regards,<br>
>>><br>
>>> - daan Strebe<br>
>>> Senior Computer Scientist<br>
>>> Adobe Systems Incorporated<br>
>>><br>
>>><br>
>>> No virus found in this incoming message.<br>
>>> Checked by AVG - www.avg.com<br>
>>> Version: 8.5.409 / Virus Database: 270.13.114/2401 - Release Date:<br>
>>> 09/30/09 10:35:00<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>><br>
>><br>
>><br>
>> ------------------------------------<br>
>><br>
>> Yahoo! Groups Links<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>