<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:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@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: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";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.left
{mso-style-name:left;}
span.bld
{mso-style-name:bld;}
p.ad, li.ad, div.ad
{mso-style-name:ad;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"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:1740977980;
mso-list-type:hybrid;
mso-list-template-ids:1854541286 -265673642 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-start-at:0;
mso-level-number-format:bullet;
mso-level-text:-;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Calibri","sans-serif";
mso-fareast-font-family:Calibri;
mso-bidi-font-family:"Times New Roman";}
@list l1
{mso-list-id:2110007925;
mso-list-template-ids:437182324;}
@list l1: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'>Daniel,<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 your continued commitment to resolving differences
in our opinions (I think we agree on a lot more things than those we disagree
on, which is a good sign). To make the rest of my email clear, I would like to
define the actors and terminology I am going to use:<o:p></o:p></span></p>
<p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo2'><![if !supportLists]><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span
style='mso-list:Ignore'>-<span style='font:7.0pt "Times New Roman"'>
</span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Implementer: a developer / entity creating applications or
software libraries to support composite fonts ( a consumer of Composite Font
recipe);<o:p></o:p></span></p>
<p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo2'><![if !supportLists]><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span
style='mso-list:Ignore'>-<span style='font:7.0pt "Times New Roman"'>
</span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Composite Font creator – a font vendor / developer who
produces the recipe utilizing the constructs (tags, attributes, elements, etc.)
[to be] defined by the Composite Font specification ;<o:p></o:p></span></p>
<p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo2'><![if !supportLists]><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span
style='mso-list:Ignore'>-<span style='font:7.0pt "Times New Roman"'>
</span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Content creator – anyone who may end up using Composite
Fonts for producing any kind of the content – graphics artists, web authors,
office employees creating business documents (including all of us writing
emails), etc.<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 will try as best as I can explain once again why I believe
establishing certain formal reference points of conformance to the spec is not
only necessary to satisfy the established ISO/IEC practices and directives but
is also vital for all of the categories of consumers of Composite Fonts
specification mentioned above.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I agree with you that fonts are tools, and tools are only useful
when they are reliable. So , from the content creator point of view –
when I pick a font to work with, the last thing on my mind is to investigate if
this font has been designed in such a way that will work on any (or many)
platforms and with any application, or if I will be limited in using the font
for only a specific purpose, or if a content of a document I created will not
be seen the same way I see it on my computer screen. As an end user of a tool,
I expect the font to just work – anytime, anywhere. If this promise of
universal tool usability cannot be fulfilled because the specification that
defined the font technology failed to establish sufficient interoperability
guarantees, Composite Fonts as a tool would have little or no value for content
creators (IMHO).<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'>To the same tune, as a Composite Font creator/developer –
I consider the constructs [to be] defined by the Composite Font specification as
a special purpose API. Like any other developer using any standardized API that
is available to me – I can use any API call I need to fulfill my goals,
and while I have total freedom to use only those API calls I need, I do expect
the compliant standardized implementation of the API to support any and all API
calls defined by a standard, or by its corresponding profile (/ level) conformance
document. A standard that defines API with no guarantee that any particular
subset of this API will be universally supported by all implementations is of
no use to me as a developer.<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'>Similarly, unlike the group of experts who develop and author
the standard, many implementers may not possess enough of an expertise to make
their own decisions and choose what subset of the standardized technologies
they need to implement for their applications – they do rely on standards
to convey this information in addition to specifying technical solutions. This
becomes especially important when font engine implementations are used as a
core service for other applications (e.g. the same font/text engine may be used
by all resident device applications, including web browser, email client, media
player, etc. As an implementer, I want the specification to be clear and
unambiguous, and to spell out in details what needs to be implemented, how and,
most importantly, why (and under what circumstances I can / cannot deviate from
the spec). Any ambiguity creates a problem for an implementer – I simply
do not want to be in a position where I have to investigate other
implementations to find out e.g. how Microsoft implemented the technology in
their OS, or how Adobe implemented it in their application suite. I’d
rather have a spec that tells me everything I need to know (and then I always have
a freedom to decide what to do and how).<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'>All of the parties identified above are potential consumers of
the Composite Fonts specification and/or products built according to it, and
for this new technology to offer a real value we need to make sure that the different
components all work together and are interoperable. This is why I believe there
is a real need for the specification to define one or more of the subsets
(profiles) that would mandate certain parts/tools/technologies be implemented
to enable interoperability between different types of consumers and between
different devices and applications, besides the need to satisfy the
requirements of the ISO standardization process.<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'>Daniel, I do understand the validity of the situation you
presented in your elaborate example. Like I said in one of my earlier emails,
there is no “standards police” that can punish people for not
strictly adhering to the letter of a standard and implementing only a subset
they see useful. There will be certainly quite a few corner cases where a
consumer of the Composite Fonts solution may at the same time play multiple
different roles and be a content author and implementer at the same time (as
in your example), and people may certainly choose to use the specification any
way they like and cherry-pick the technology they believe is useful for their
particular needs. This is all fine, and as long as they do not claim that their
implementation is compliant with mandatory requirements of the spec, there is
no harm in implementing only a part of the standard (think of my earlier
example with CCTV digital video system where video signal is always created and
consumed inside this CCTV environment). Deviating from the standard and Implementing
only certain subset is okay if my encoder and my decoder are the only two ‘consumers’
of the standard. <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'>To the contrary, let’s consider Blu-Ray Disk as the
example of the open environment. The content itself is usually a mix of multiple
different technologies – video and audio encoding solutions integrated
with interactive Java applications that generate graphic content and text,
which may use custom fonts recorded on the BD for text rendering. Player
devices are produced and sold by different manufacturers who are typically not
associated in any way with content producers. All of the parties involved (OEM,
tools vendors, content creators, etc.) rely on 100% interoperability between
different authoring/compression/rendering tools and player implementations so
that any disk can be inserted in any BD player and be seen the same way,
including interactive content and text rendered using custom fonts. The BD
implementations have no choice but to strictly adhere to various specification
that define among others video and audio compression formats, Java API profile,
image, graphics and font file formats that BD player can read and rendering
capabilities that have to be supported, etc. This is the environment where
complete 100% interoperability is the key to successful deployment of products
and services, and if we ever want Composite Fonts solution to succeed we have
to enable interoperability by mandating all (or certain) parts of the solution
be implemented. I am all for mandating the complete solution (I believe the
additional complexities we introduce would be negligible comparing to the
capabilities of existing font/text engines) and I am happy that we seem to
agree at least on this important issue.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Best regards,<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>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>
<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>Daniel Strebe<br>
<b>Sent:</b> Wednesday, September 30, 2009 9:38 PM<br>
<b>To:</b> mpeg-OTspec@yahoogroups.com<br>
<b>Subject:</b> [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><span style='font-size:9.0pt;font-family:"Helvetica","sans-serif"'>Vladimir:<br>
<br>
I appreciate the effort you put into these responses. I apologize for this very
lengthy response. Here is a synopsis for those who need to ration their reading
time:<br>
<br>
1. Rebuttal of the thesis that the situation with Web browsers argues for more
imperatives in this specification.<br>
2. Why we won't be able codify the useful possibilities for composite fonts.<br>
3. Why the recipe creator's "intent" is not what is important, but
rather the consuming author's intent that is important.<br>
4. A composite font recipe is not content, it is a resource; therefore the
requirement of fidelity to its instructions depends upon context.<br>
5. Examples of composite font usage to clarify when fidelity is/isn't useful.<br>
6. My interpretation of Vladimir's proposal, juxtaposed against my 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>
<b>1. Browsers as an analogy to composite fonts<br>
</b><br>
I do not agree with Vladimir's analysis of the situation with Web browsers
today or the failures of the W3C recommendations, and therefore I do not agree
with the conclusions Vladimir draws. The World Wide Web was not conceived to
deliver final-form presentation. We could go into great depth on this matter,
but it is peripheral to the discussion, so I will leave it by averring that
many Web designer vexations arise out of the natural tension between their need
for design and the Web's need to deliver content on displays of unknown
resolution and unknown color space, on devices of unknown computational
capacity, in unknown window sizes, and using possibly unavailable
resources—like fonts — a problem that is still not solved 15+ years
later. <span style='color:#1F497D'><o:p></o:p></span></span></p>
<p><span style='font-size:9.0pt;font-family:"Helvetica","sans-serif"'>To a fair
extent the reality of these unknowns forced specifications that allow choice in
implementation along with soft failure. I do not claim that no mistakes were
made; I do not know enough about those standards to know what mistakes were
made and how grave. But my understanding of their purpose does not match the
premise of Vladimir's argument well.<br>
<br>
<b>2. On codifying useful possibilities for composite fonts<br>
</b><br>
To return to my elaborate example, Marina's hypothetical problems would not
have been alleviated by "better" standards. It is pointless for Web
browsers to implement typographical features when the designer's desired font
generally isn't even available on the viewing computer. A standard can't do
anything about copyright restrictions. If and when legal, commercial, and
technical remedies arrive on the scene to deliver the fonts content designers
want to Web pages, then surely we will see browsers supporting typography with
ever greater sophistication.<br>
<br>
Conversely, if standards had dictated such typographical sophistication from
the outset, despite its uselessness, the barrier to entering the browser market
would have been higher, and expensive effort would have been diverted from more
useful functionality elsewhere. This is why I contrived such an elaborate
scenario. Marina's quandary arises from conditions that exist now. They did not
exist three years ago because there was no RIA framework for her to use. They
probably will not exist three years from now because better typography probably
will arrive in browsers and RIA frameworks once the type delivery service she
subscribed to becomes commonplace.<br>
<br>
Meanwhile, we, sitting here now comfortably at our computers contemplating
conditions as they exist now, will find ourselves unable to enumerate all the
uses people will find for composite fonts even today, let alone five years from
now. Therefore I do not understand why we should fossilize our ignorance in a
specification. What we do know, or can puzzle through, is what kinds of things
people are likely to want to communicate with composite fonts. Therefore we
should provide a language for this communication — but we should leave
the actions of the communicators up to those who know what they are trying to
achieve.<span style='color:#1F497D'><o:p></o:p></span></span></p>
<p><b><span style='font-size:9.0pt;font-family:"Helvetica","sans-serif"'>3. Why
the recipe creator's "intent" may not be important, and what is<br>
</span></b><span style='font-size:9.0pt;font-family:"Helvetica","sans-serif"'><br>
To address an implicit axiom in Vladimir's arguments, the intent of the
composite font creator is not the only intent in play. What we have been
calling a consumer — because it consumes a composite font recipe —
may also be a content author. This "consuming author" has an intent
we know nothing about, but by definition creative forces are in play. Whom are
we helping if we stifle those creative forces by shoving them into the only
channels we foresaw or that we felt were "important"? To the human
authoring that content, our specification means nothing and the composite font recipe
means opportunities. That human wants the software "she" is using to
do what she expects it to do. How that software adapts an incoming composite
font recipe to its purposes is not our business. It is not even the business of
the recipe creator. It is the business of the creative mind operating the
software because what comes out of that creative mind is original content. The
font is just a tool in creating that content.<br>
<br>
The consuming author has a reason for consuming composite fonts. Therefore the
consuming author must be interested in what a composite font recipe has to say.
That means the language the composite font speaks must be clear, but it does
not mean the consuming author is interested in everything the recipe has to
say. A font is not content. It is a tool or a resource. It may contain elements
extraneous to the content for which it is being exploited. We must not confuse
ourselves into lumping composite font recipes into the same category as MPEG
videos or PDF, where fidelity of content must be preserved because fidelity of
content is <i>the</i> purpose.<br>
<br>
A font contains instructions. The purpose of the instructions is for the font
to be used usefully. What is useful varies from circumstance to circumstance.
The circumstances are innumerable.<br>
<br>
<b>4. On fidelity to the recipe, and when it is/isn't important<br>
</b><br>
I do not discount the need for fidelity, but we need to be clear about what
kind of fidelity we are talking about and why it is important. If Vladimir's
argument is that consumers must retain the fidelity of the recipe creator's
intent, then I completely disagree. For one thing, it's frankly none of the
recipe creator's business how the tool "he" created gets used insofar
as other interests are not harmed. For another, the creator will be unable to express
all the ways he might be willing for the recipe to be used, both because we
will not provide a language so complicated and because creators won't want to
burden themselves with the infinite permutations of pedantic intent that
consumers might find useful. Both the creator and the consumer would wonder
what the point is, and the creator is probably even less likely to envision all
the useful scenarios than we are. Just because a creator forgot to mention that
he's fine with his composite font being used just for its glyph mappings is no
reason someone shouldn't use it for that.<br>
<br>
When does fidelity to the recipe creator's intent need to be preserved? <i>When
the recipe itself becomes part of the instructions for reproducing content. </i>In
other words, when the consuming author's content relies on the composite font
recipe for whatever form of fidelity it needs. Since what is meaningful to
preserve varies from content category to content category, and since neither we
nor the recipe creator knows the consuming author's intent, it follows that we
cannot be in the business of dictating what portions of a composite font recipe
a consuming author's software is allowed to honor or discard.<br>
<br>
<b>5. Examples of when fidelity to a recipe is/isn't important<br>
</b><br>
<b> Example A, page layout software:</b> In page layout
software, the composite font recipe will be relied upon to create consuming
author's content. Moreover this reliance likely extends to the most minute
details of glyph placement. Most content authors will expect a composite font
to work the same regardless of what page layout software or word processor they
use. Because page layout software's purpose is typographic fidelity, and
because the composite font recipe's creator is likely to know more about the
typography of the fonts in the recipe than the authors of the page layout
software (who probably don't even know about the component fonts specifically),
a normal implementation would be a complete one.<br>
<br>
In practice, we are likely to see page layout software either not implement
composite fonts or else implement the specification in its entirety. Partial
implementations, at least as far as body text goes, would confuse content
authors and reflect unfavorably on the page layout software publisher. They
could result in imported content getting formatted differently from the
original. Still, there may be interesting uses for partial implementations
outside of body text.<br>
<br>
<b> Example B, markup languages:</b> In markup languages
that include presentation semantics, some kinds of formatting are provided for
while still conforming to environmental constraints. Normally this means line
breaks are absent in the content, but some kinds of character and block
formatting are present. Their presence ranges from fairly abstract
("header") to fairly concrete ("underline"), depending upon
the particular attribute and and upon the particular markup language. Some
provide for font categories ("Serif"); some provide for font names.<br>
<br>
A composite font could provide for typographic and formatting control beyond
the scope or intent of a renderer of the markup language. One could argue for
nearly any range of composite font support in this context. If the renderer is
a markup editor in "source" view, typographic needs might not exist.
A composite font might get selected for some purely semantic reason, such as
glyph complement, with no intent or need for typographic control because the
editor's reason for choosing the composite font is only to be able to render
any glyph expressed within literal strings.<br>
<br>
If the markup editor provides a "Preview" mode to see the content
formatted, how much typography the mode should enable depends on what expected
target systems will be able to render. If the markup language does not even
provide a mechanism to designate the specific font for rendering, then clearly
the "preview" amounts to little more than a "mock-up", and
the need to support various features of composite fonts becomes highly
questionable. Transmission fidelity 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 markup, then
the markup editor ought to enable any typographic features that do not conflict
with the markup itself. We are in no position to decide what that means in the
general case. We may want the rendering engine to honor the small-caps
instructions in the composite font recipe, for example, but the markup language
or the style guide for the renderer may dictate that all-caps must be used. Or
we may declare that a compliant renderer honor the glyph mappings of the
composite font, but this markup includes mathematical expressions. The renderer
is happy to use the composite font recipe for text, but it knows a lot more
about mathematics than we do and than the generic markup editor did, so it always
renders formulę according to a specific font it knows behaves according to its
own precise layout needs.<br>
<br>
It should be clear from these examples, including the earlier elaborate example
of Marina and her cartographic project, that we can contrive plausible subsets
of functionality ad nauseum, and therefore that we will never anticipate all
the diverse, legitimate uses of composite fonts.<br>
<br>
<b>6. What the contrasting proposals look like<br>
</b><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 with respect to Font B.<br>
2. You must shear glyphs of
Font C 4° rightward from base to top with respect to other fonts in the recipe.<br>
3. You must map Unicode range W–X
to Font C for Latin script, X+1–Y to Font D for Chinese, Y+1–Z to
Font E for mathematical 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 compliant renderer according to Compliant
Subset D.<br>
3. You may ignore if you are a
Latin-script-only renderer according to Compliant Subset E.<br>
<br>
Consumer compares her intent against recipe creator's
intent and our intent:<br>
1. I am in violation because I
do not need to shift baselines because I do not mix component fonts on a single
line.<br>
2. I need the design
characteristics to match, so I shear glyphs.<br>
3. I am in violation because I
always use Cambria Math for mathematical symbols because I can't lay out
equations reliably using arbitrary fonts.<br>
<br>
with the result that the recipe creator was unable to state his real intent
because his real intent was merely to describe how the components of the
composite font can work together to achieve the illusion of a single font, not
to dictate what features of the composite font must be used, since he has no
idea what the consumer needs anyway. The consumer, whose implementation suits
her purposes precisely, does not comply with any recognized subset. Output downstream
gives idiosyncratic results because the specification requires her to pass
through the composite font recipe unmodified (in order to honor the recipe
creator's intent and ignore her use of 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 respect to Font B gives uniform baselines.<br>
2. Shearing glyphs of Font C 4°
rightward from base to top with respect to other fonts in the recipe gives
matching oblique angles.<br>
3.
Mapping Unicode range W–X to Font C gives correct
results for Latin scripts.<br>
Mapping
X+1–Y to Font D for Chinese gives correct results for simplified Chinese.<br>
Mapping
Y+1–Z to Font E gives correct results for mathematical symbols.<br>
...<br>
<br>
We inject no intent.<br>
<br>
Consumer compares her intent against recipe creator's
observations and our intent:<br>
1. I do not need to shift
baselines because I never mix composite font components on a line.<br>
2. I need the design
characteristics to match, so I shear glyphs.<br>
3. I always use Cambria Math
for mathematical symbols because it is impossible to lay out equations reliably
using arbitrary fonts.<br>
<br>
with the result that this consumer got exactly what she wanted without
violating the specification, without violating the creator's intent, and
without harming anyone's interests. All output downstream from her deployment
behaves correctly because she only passed through the portion of the composite
font recipe that she actually deployed... or because her output is in
final-form, not dependent upon anything external to the final-form document.<br>
<br>
<b>7. Responses to some specific arguments posed by Vladimir<br>
</b><br>
I sympathize with Vladimir's argument that implementers will look to the
specification for guidance even when they only implement part of it. However, I
am unable to come up with realistic scenarios that require
"interoperability" at partial levels. In scenarios I have managed to
contrive, partial implementations are generally dead-end consumers or else
their output would always be final-form. Neither scenario requires adherence to
some canonized subset, nor does it seem like the situation would confuse
implementers, since they have a clear idea of what they need. To ensure
fidelity downstream when exporting its content, Partial Implementation A should
simply excise those portions of a recipe that it did not use. (I would go so
far as to say we should require this.) This way any consuming implementation
that is a superset of Partial Implementation A (such as a full implementation)
will deliver fidelity to the content created by Partial Implementation A. The
odds that downstream consumer Partial Implementation B is both a partial implementation
and carries the similar needs and intent as Partial Implementation A is remote
unless the two already know about each other in some private or semi-private
contract. Therefore our intervention adds little value, if any.<br>
<br>
For example, Vladimir notes "...We can specify one subset that would be
sufficient for authors creating content utilizing simple scripts only".
But if we look at the sorts of functionality we propose for composite fonts,
none of it really applies to simple versus complex scripts. Whether a given
implementation will work with complex scripts depends on its general font and
language handling machinery, not upon whether it supports some feature of
composite fonts. Meanwhile "simple script" support means different
things to different layout engines. We are not going to convince an established
layout engine to improve or change its implementation of "simple
scripts" just to gain "compliance" with whatever we decide is
meaningful — particularly when our "requirements" actually turn
out to be orthogonal to executing the instructions of a composite font recipe.<br>
<br>
Vladimir states, "[Consumers] must be able to scale fonts and/or
individual glyphs and their metrics to ensure correct layout... I believe that
since all existing font engines today support scalable fonts and are capable to
do this, the requirement does not present any additional burden on
implementations." To which I respond that code must be written to
interpret the semantics of the scaling, adjust positioning, and to instruct the
font engine to perform the scaling — and even then coding is only a
portion of the cost of deploying an implementation. Meanwhile, if such scaling
is irrelevant to the content the consuming author creates, who benefits by
requiring it?<br>
<br>
<b>8. Ten objections to Vladimir's proposal<br>
</b><br>
To reiterate: I am happy for this committee to prepare a standard for a
"complete" implementation. I think that will be of the most interest
to the most people, and it covers the most demanding case: typographic
fidelity. I am not at all happy to canonize some subset 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 we would come up with.<br>
3. We do not have the wisdom to winnow down the
possibilities into some manageable collection that suits (almost) all needs.<br>
4. Whatever list we might come up with would be fragile
in the face of technology and market forces.<br>
5. Any given partial implementation will not have a
large enough constituency for us to expend such effort on.<br>
6. Canonized subsets distract and dilute our ability to
encourage and "enforce" the complete typographic case.<br>
7. We will invite confusion over the meaning of recipes
by condoning a special subset of exceptions to their imperatives.<br>
8. By considering the recipe's instructions as
imperatives at all, we exclude useful possibilities the recipe otherwise
implies.<br>
9. We will stifle innovate uses which themselves do not
harm other interests.<br>
10. We will be injecting our own intent into areas we have no
business doing so.<br>
<br>
<b>9. In conclusion<br>
</b><br>
We should allow partial implementations to support those aspects of the
specification that they need. We should instruct that partial implementations
must alter the recipes they consume to reflect their requirements for fidelity
in the content they generate. We should instruct anyone intending for broad
interoperability to implement the complete specification. We should not add to
the specification such requirements for font feature support that are
orthogonal to the business of executing the instructions in font recipes.<br>
<br>
Regards,<br>
<br>
— daan Strebe<br>
Senior Computer Scientist<br>
Adobe Systems Incorporated</span><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>