<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<title>Re: [mpeg-OTspec] Toward a Composite Font format specification</title>
<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;}
/* 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.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.EmailStyle17
{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:716701888;
mso-list-template-ids:-796748210;}
@list l1
{mso-list-id:1258058827;
mso-list-type:hybrid;
mso-list-template-ids:648717576 -1401026992 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l1:level1
{mso-level-text:"%1\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
mso-ascii-font-family:Calibri;
mso-fareast-font-family:Calibri;
mso-hansi-font-family:Calibri;
mso-bidi-font-family:"Times New Roman";}
@list l2
{mso-list-id:1672830835;
mso-list-type:hybrid;
mso-list-template-ids:772676130 -336976118 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l2:level1
{mso-level-start-at:4;
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";}
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=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'>I appreciate your detailed response.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>To answer your question about inadequacy of tools available to
Marina in the use case you presented – I believe that the situation with
browsers today is a very appropriate and useful example of standardization
efforts failing to specify deterministic behavior of a client consuming a content.
It is a known fact that many existing W3C Recommendations adopted the same
approach you are advocating for Composite Fonts – they specified a collection
of optional tools but did not mandate any particular subset be implemented by
all browsers. As a result, most browser implementations today do not guarantee deterministic
behavior, which places an undue burden on authors – they often have to
create multiple versions of the same content to accommodate the differences in
browser implementations, and almost always have to resort to using other (either
third party, such as Flash, or custom) tools when deterministic rendering and
presentation of content is a requirement. Quite often, web authors have no
choice but to pre-render a content and display it as an image to insure the correct
presentation. All this could have been avoided if all browsers have complied
with the same strictly defined set of specification requirements to guarantee
that authors have necessary tools in their arsenal.<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'>We find ourselves today in the convergent environment where the content
is created with the expectation to be consumed by many different devices and on
different platforms. I strongly believe that a content is indeed the king and that
the success of any standardization effort relevant to content presentation will
be determined by whether or not the new set of tools gives authors sufficient
guarantees of faithful presentation of content they create. This is why I
believe that the Composite Fonts specification should strictly define the
mandatory minimal set of tools that must be supported by all implementations –
the main purpose of this is to provide authors with the guarantee that the creator’s
intent can be fulfilled. This subset will become the basis for interoperable
implementations to exist. Let me explain this using the following example:<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Let’s assume for the purpose of this discussion that all
conformant implementations of Composite Fonts specification shall support a
certain set of tools:<o:p></o:p></span></p>
<p class=MsoListParagraph style='text-indent:-.25in;mso-list:l1 level1 lfo2'><![if !supportLists]><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span
style='mso-list:Ignore'>1)<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'>They must be able to parse XML to decode Composite Fonts recipe
and recognize the meaning of certain elements and their attributes.<o:p></o:p></span></p>
<p class=MsoListParagraph style='text-indent:-.25in;mso-list:l1 level1 lfo2'><![if !supportLists]><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span
style='mso-list:Ignore'>2)<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'>They must be able to scale fonts and/or individual glyphs and
their metrics to ensure correct layout of text when different components are
utilized (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).<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Now, let’s ask ourselves – will this subset be
sufficient to insure creator’s intent? The answer is probably “no”
since the ability to read and understand the Composite Fonts recipe does not
guarantee the availability of component fonts on a target platform or a device.
So, the next logical step would be to require that<o:p></o:p></span></p>
<p class=MsoListParagraph style='text-indent:-.25in;mso-list:l1 level1 lfo2'><![if !supportLists]><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span
style='mso-list:Ignore'>3)<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'>All Composite Font consumers must be able to process the embedded
fonts (this way content creators will be able to include the fonts of their own
choice to make sure they are always available on a target device).<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Does this extended set of requirements guarantee the faithful
content presentation? The answer is “no”, not yet. A font may be
embedded in a format that is not supported by a consuming device and the
content author has no way of knowing what formats are supported, unless this
specification also includes the additional requirement that<o:p></o:p></span></p>
<p class=MsoListParagraph style='text-indent:-.25in;mso-list:l1 level1 lfo2'><![if !supportLists]><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span
style='mso-list:Ignore'>4)<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'>All implementations of Composite Fonts specification must be
able to render embedded fonts in at least one certain format, support for other
formats is optional.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Now, we have come up with the list of requirements that gives
content creators a set of tools known to be supported by all compliant implementations.
Authors have now multiple different options in their possession which give them
certain level of l control over the content presentation:<o:p></o:p></span></p>
<p class=MsoListParagraph style='text-indent:-.25in;mso-list:l2 level1 lfo3'><![if !supportLists]><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span
style='mso-list:Ignore'>-<span style='font:7.0pt "Times New Roman"'>
</span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>they can create a recipe that specify component fonts <b>hoping</b>
that the consumer will be able to find the right fonts or substitute them with
the appropriate choice of alternate font, or<o:p></o:p></span></p>
<p class=MsoListParagraph style='text-indent:-.25in;mso-list:l2 level1 lfo3'><![if !supportLists]><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span
style='mso-list:Ignore'>-<span style='font:7.0pt "Times New Roman"'>
</span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>if they want to <b>insure</b> deterministic behavior, they <b>can
embed</b> the fonts that are part of the recipe knowing what format is
guaranteed to be supported by all clients. <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'>This is just an example, the actual specification will likely
have to be more detailed and also specify a certain subset of font tables to be
supported. The bottom line is that the specification has to define a subset of
tools that enables all consumers to fulfill the creator’s intent, at
least for some number of uses cases. So, to answer your question 1 - I see this
as the only possible way to define the meaning of interoperable solution as the
one that gives content creators at least limited guarantees of certain consumer
behavior.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>As far as question 2 is concerned – our decision to
mandate a certain subset of tools will be determined based on the analysis of use
cases and scenarios we, as the experts in the field, can foresee and agree on
(i.e. by consensus). And finally, on question 3 – as I mentioned earlier,
I don’t believe we have any way to enforce compliance but I hope that by defining
the reasonable and justifiable set of tools we will be able to convince
consumers to implement the Composite Fonts standard in full compliance with the
spec. I also believe that many implementers are not the experts in the field of
typography and fonts, and would appreciate the specification that provides
clear guidelines of what has to be implemented and why.<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'>In the end, I want to emphasize once again that, in my opinion,
the success of our efforts will be determined not by consumers implementing the
spec but by content creators, and by how successful we are in communicating and
executing the creator’s intent. If creators do not embrace Composite
Fonts because it fails to guarantee certain level of deterministic results –
our efforts in creating this technology and the investments of consumers
supporting different components of the spec will be a waste.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Best regards,<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Vladimir<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<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"'> Daniel Strebe
[mailto:dstrebe@adobe.com] <br>
<b>Sent:</b> Monday, September 21, 2009 9:30 PM<br>
<b>To:</b> Levantovsky, Vladimir; Ken Lunde; mpeg-OTspec@yahoogroups.com<br>
<b>Subject:</b> Re: [mpeg-OTspec] Toward a Composite Font format specification<o:p></o:p></span></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal style='margin-bottom:12.0pt'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif"'><br>
Vladimir,<br>
<br>
Thank you for taking the time to comment on the scenario I contrived. Let me
note first that I do not disagree with anything you wrote, particularly, but
only on the significance. Hence we may be back to a philosophical discussion.<br>
<br>
With regard to your point (3), I agree entirely, but I do not see the
relevance. The inadequate tools presenting themselves to Marina’s team
did not arise out of failures of specification. Specifically they did not come
about as a consequence of a specification failing to describe compliance
criteria. Therefore our prescribing mandatory versus optional portions of a
consumer implementation will not prevent the circumstances Marina’s team
finds itself in.<br>
<br>
Instead, the inadequate tools came about because of gaps in implementation, if
we wish to judge unkindly. But a more realistic view is that those who
developed the tools judged that the market for a fuller implementation would
not reward the effort needed. It means little to for us to chide the browser
developers for not even kerning their text—and yes, that is the present
state of affairs with all browsers except Firefox on Macintosh—when there
is no practical mechanism available for a Web designer to display body text in
the font of her choice. It is the market that determined how much effort Web
browser developers were willing to invest into compliance, not the
specification. When the market conditions change, browser implementations will
change.<br>
<br>
The same goes for Marina’s team. You are correct to note that they would
not have to do the work later if they implemented the specification according
to our standards, but that is almost never anyone’s goal, and
shouldn’t be. The only time it makes sense to delay putting out a product
in order to add potential future functionality is if the cost of doing it later
would overwhelmingly exceed the cost of doing it now. That would never be the
case with composite font levels of implementation.<br>
<br>
Our constituency will find themselves in same position. We may elect to gather
together some arbitrary subset of our final specification and call it
“mandatory”, but: (A) I am fairly certain the subset WILL be
arbitrary, meaning not reflecting the needs of any particular market or
consumer; and (B) Whatever we have to say about it will get ignored entirely in
favor of market forces anyway. That will happen for several reasons.<br>
<br>
For one thing, this specification will never carry any sort of marketing
cachet. That is the cold, hard truth. There won’t ever be some emblem on
a box that people will look for with confidence. No company will come to us
begging to certify their implementation so that they gain a market advantage.<br>
<br>
For another, this is not some optical storage medium specification, where the
realities of physics and engineering not only dictate the tolerances that get
written into the specification, but also punish the violators. Our enterprise
is fundamentally different. Composite fonts won’t fail catastrophically
just because someone only implements part of the specification. There are
endless grades of utility. We will not be able to isolate some subset of the
specification and defend that subset as being somehow better or preferable to
some other subset. If so, then why would we do it? More to the point, why would
an implementer bother to follow our implementation requirements if they
perceive an advantage to not following them?<br>
<br>
For yet another, and this is corollary to the last, there isn’t really
any such thing as “interoperability” on the consuming side.
Therefore implementers of composite font consumers won’t feel any
pressure to adhere to recommendations whose ostensible purpose is
“interoperability”. The consumer knows what it’s trying to
achieve when it consumes composite fonts. We do not. Unlike optical media, we
cannot describe the consumer’s precise intent. We cannot say anything so
pithy and absolute as “The consumer wants to read off the disc any of the
information that was recorded onto it, unchanged, now and forever.” All
we can say with any confidence is that the consumer is trying to do something
with fonts (possibly) aggregated into some über-font. What the consumer wishes
to do next with the data it works with is entirely the consumer’s
purview, not ours.<br>
<br>
More specifically, If the consumer writes a PDF, the consumer is going to want
to write one according to how it used the composite fonts, not how we thought
it might want to use them. Therefore our argument for interoperability would
fail. If the consumer wishes to put out text in some interchange format, it may
consider its own usage to be idiosyncratic and specific to its own
circumstances, and therefore may pass on the composite font recipe in its
original form. Or, like the PDF case, the consuming application may be
directing downstream consumers to retain fidelity to its own document
presentation, and therefore the consuming application may write out the subset
of the composite font recipe that it made use of while discarding the rest.
“Interoperability” here is, again, a decision we cannot make for
the consumer because we know nothing about the consumer’s intent.
Therefore we cannot be in the business of telling consumers this or that is
mandatory versus optional.<br>
<br>
We must focus our efforts on the communication of the intent. Seeing to it that
consumers fulfill the intent is not our business. We have no means to enforce
it, no way to divine the consumer’s intent or business, no realistic
expectation we will be heeded if we try. <br>
<br>
Meanwhile it is in everyone’s interest to adhere to the specification of
recipes. That the part we should focus on and get right. We do not have to make
any arbitrary decisions for anyone in specifying this language for
communication. Everyone will be happy if the intent can be specified as
precisely as needed.<br>
<br>
So. If I may make some requests, I would like you to address three matters
specifically:</span><o:p></o:p></p>
<ol start=1 type=1>
<li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
mso-list:l0 level1 lfo1'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>What
do you mean when you talk about “interoperability”? What
scenarios will fail if consumers are allowed to decide their own level of
implementation, versus our deciding what is mandatory and what is
optional? </span><o:p></o:p></li>
<li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
mso-list:l0 level1 lfo1'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>How
will our decisions on “mandatory” versus
“optional” be defensible as anything better than arbitrary? </span><o:p></o:p></li>
<li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
mso-list:l0 level1 lfo1'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>You
stated that, if the consumer did not claim “compliance” with
the specification, that no harm would be done in only partially
implementing the specification. Do you believe this specification will
become so important that overt statements of compliance will carry market
weight? (I would argue even OpenType does not carry such weight. Products
merely state they can use OpenType fonts and what kinds of things they can
do with them; nobody claims “compliance”.) If it does not
carry market weight, what would be the motive for a developer to implement
more than they believed their application needed just to be able to claim
“compliance”?</span><o:p></o:p></li>
</ol>
<p class=MsoNormal style='margin-bottom:12.0pt'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif"'><br>
<br>
Regards,<br>
<br>
— daan Strebe<br>
Senior Computer Scientist<br>
Adobe Systems Incorporated<br>
<br>
<br>
On 09/09/21 14:52, "Levantovsky, Vladimir" <<a
href="Vladimir.Levantovsky@MonotypeImaging.com">Vladimir.Levantovsky@MonotypeImaging.com</a>>
wrote:</span><o:p></o:p></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>Daan,<br>
<br>
Thank you for presenting a very elaborate use case, I really appreciate it. It
brings attention to some very specific details but, first and foremost, I think
it will by and large help us better understand the concepts of mandatory
features in a specification language; and, in particular, it may help us better
understand the scope and goals of the Composite Fonts specification.<br>
<br>
First of all, I would like to make sure we are all on the same page when it
comes to the meaning of the notion of “mandatory” or
“required” components in a specification – they exist and are
useful only for the purposes of defining the meaning of “compliant implementation”
and establishing certain conformance points. There is no such thing as
‘standards police’, and “violation” of a specification
by not following its recommendations or requirements (and/or not implementing
everything that is deemed mandatory) does not result in any repercussions for
the implementer. In the worst case, the only “punishment” for not
following the spec mandate may be inability to claim compliance with that
standard, and in some circumstances, being compliant to the spec may bring certain
market advantages (e.g. an opportunity to use a spec logo to promote a final
product). Some standards organizations (e.g. those that define
hardware-acceleration or software development APIs) and their specifications
are very rigid about “enforcing” the conformance requirements by
mandating implementers to run and pass a standardized test suite as part of
self-certification process. Sometimes, they even require to submit the test
results to be validated by a standards organization, e.g. in exchange for a
grant to use its logo on a final product. However, in many cases implementers
are free to make their own choices whether or not to follow all specification
requirements – the result of creating a non-compliant implementation may
be justified by the market conditions. <br>
<br>
For example, if I wanted to build a closed-circuit digital video surveillance
system using MPEG-4 AVC video standard – I may choose not to implement
some video compression/decompression tools that would be mandatory for a
Blu-Ray DVD player. My video surveillance system may work just fine without
them, and I’d have no need or intention to claim that my video
encoding/decoding capabilities are compliant with the standard that all DVD
players must adhere to. To summarize – I’d only have to implement
all mandatory parts of the standard if I<br>
- need to be compliant to pass
a standardized conformance test, and/or<br>
<br>
- want to advertize my product
as compliant with a particular standard.<br>
<br>
<br>
Now, let’s go back to the use case you presented:<br>
<br>
1) The team of developers decided to create a
“rich internet application (RIA)” client where its sole purpose is
to render interactive online map. They concluded that “the project has no
need for VDMX, vhea, vmtx, BASE, JSTF, chunks of GSUB and GPOS, and several
other tables and portions thereof. They will never mix two scripts on the same
line, so they do not care about relative baselines. They lay out no vertical
text. They will never lay out a complete sentence. They do not need punctuation
in any general sense. The slightly different aspect ratios of some of the
components do not concern them because they do not mix text of the different
component fonts on the same line.“ Based on the facts you presented, I
think that it would be fair to say that the RIA client has very limited scope.
Therefore, implementing a limited subset of Composite Fonts specification may
satisfy their needs even though the RIA developers would never be able (and
likely would have no intention) to claim compliance with the standard. And, if
they don’t claim a conformance to the spec, there is no harm done and
there is no authority that would be in a position to “punish” them.<br>
<br>
<br>
<br>
2) Let’s assume that the RIA team has been
successful in delivering everything they planned for, and their very next step
would be to build on their own success and enhance their application by
accommodating end-user suggestions to introduce a new feature – e.g.
displaying a paragraph of text with ethnic data when an end-user clicks
on the name of the ethnic group or their territory on the map. The RIA team may
suddenly realize that they do need to support punctuation and lay out complete
sentences, and be able to mix two scripts on the same line because “the
place names [and now the description text should] be presented in the script of
the viewer’s choice, they will also be presented in the official script
or scripts of the jurisdiction of the place name.” All of a sudden,
“the grad student tasked with the typography discovers that the <span
style='color:#1F497D'>[newly developed]</span> RIA framework’s support
for typography is no better than a typical Web browser’s”, and that
the industry experts who wrote Composite Fonts specification did have a point
when they said that certain features defined by the standard must be supported
by all implementations.<br>
<br>
In fact, this is another important role of the standards specifications –
many implementers do not possess the same level of expertise in a particular
field (as spec authors do), and they rely on industry / international standards
to provide clear guidance and specify the set of requirements that must be
satisfied to make their implementations compliant and useful.<br>
<br>
<br>
<br>
3) This use case brings even more important aspects to
consider. “Marina is a university professor with a grant from her
government to develop a detailed, interactive online ethnographic map of the
world … Marina concludes they [place (and ethnic group) names] must get
rendered real-time. Because the server budget is limited, she realizes much of the
processing must be client-side. <b>She is unable to meet all her objectives
with any technology that delivered content through the browser</b>”.
(emphasis is added).<br>
<br>
The developers of RIA client wouldn’t have been in a position where
they’d have to develop their own text processing engine with such a
limited scope if they had a choice of standard-compliant text rendering
implementations that are either readily available or simply supported by a
platform of their choice. And, assuming that browser vendors had followed the
standards as well, Marina might have come to a different conclusion that the
existing infrastructure of standards-compliant solutions would provide her with
everything she needs to develop and deploy valuable new content and service
– with minimal efforts, no market fragmentation introduced by a custom
RIA client, and without any need for custom development (all this while saving
government’s and taxpayer’s money!).<br>
<br>
<br>
<br>
Regards,<br>
Vladimir<br>
</span><o:p></o:p></p>
</div>
</div>
</body>
</html>