<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)">
<title>Re: [mpeg-OTspec] Toward a Composite Font format specification</title>
<style>
<!--
/* Font Definitions */
@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;}
/* 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";}
span.EmailStyle18
{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:1085418563;
mso-list-template-ids:1740828690;}
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'>You wrote:<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>“Meanwhile,
what is a specification? It is a rigorous communication of intent. Because of
the many variables we cannot control, and because of inability to anticipate
the consumer’s intent, we are left to ask what it is we are
communicating. The answer is that we are communicating the creator’s
intent. That is this specification’s raison d’être. If we start
issuing instructions to the consumer about what we have decided is necessary
from that recipe, then we are no longer communicating the creator’s
intent — which is already conveyed by the recipe — but instead we
are communicating OUR intent. How did our intent come into play here?”<br>
<br>
</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I am in full agreement with your statement that the only reason
for specification to be developed is to communicate the creator’s intent.
This is exactly why the specification must issue the instructions to the
consumer about what has to be done on the implementation side to ensure that
creator’s intent can be fulfilled. Please note – this is necessary only
for the purpose to fulfill the creator’s intent, and it has nothing to do
with OUR intent.<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'>Ideally, all provisions of the spec have to be implemented by
all consumers – this will guarantee the 100% interoperability between
different implementations. At a minimum, in order to enable the guaranteed minimal
level of interoperability we ought to come up with the list of elements (data
formats, attributes, etc.) that must be supported by all consumers - this has
to be done so that <b>the creator’s intent</b> (not <b>our</b> intent) can
be fulfilled. Making everything optional would make it impossible for creators
to communicate their intent reliably, knowing full well that consumers may
disregard any and all parts of their recipe.<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"'>“Any
consumer who cares about typographic fidelity ought to implement the entire
specification.”</span><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'>Again, I agree with you. In ideal world – this is exactly
what we should do, and the spec must mandate everything. In reality - this is
just another reason why I believe that the spec ought to say what must be
implemented (and why), and what may be implemented if a certain outcome is desired.
(OpenType specification is a good example of this – it has mandatory required
tables, conditional mandatory tables that are necessary only if a certain type
of outlines is supported, and optional table that are needed only if certain
functionality is needed.)<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 believe that making everything optional and giving consumers the
complete freedom to implement any parts of the spec of their own choosing will make
it impossible to fulfill the creator’s intent and will result in
interoperability nightmare.<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'>Regards,<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Vladimir<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'>
<div>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>
<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Daniel Strebe
[mailto:dstrebe@adobe.com] <br>
<b>Sent:</b> Friday, September 11, 2009 3:52 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"'>Vlad, and colleagues,<br>
<br>
I had hoped our policy in this regard was settled so we could move on.</span><o:p></o:p></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1E487C'>I see the interoperability as the main benefit of
standardization since it provides a certain level of guarantee for a content
creator (in this case, for a Composite Font creator) that the font resource (a
Composite Font) and a content that uses it will be processed and presented to
an end-user as intended by the author.</span><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>
The specification we produce will guarantee nothing regardless of how we
write it. Composite fonts will be only a tiny component of a broader
environment that we have no control over even if we “mandate”
aspects of consumer behavior. Specifically, we cannot guarantee:</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"'>The
presence of the base fonts by some loose match (i.e, font name). </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"'>The
presence of the base fonts by some strict match (i.e., font technology,
version number, or computational hash). </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"'>The
ability of the environment at large to render according to the component
fonts’ specifications. </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"'>Strict
adherence of the component fonts to their formats’ specifications. </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"'>Clarity
(lack of ambiguity) in the specifications of the component fonts’
formats. </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"'>Anything
at all about how the viewing application lays out text. </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"'>Anything
at all about the intent of the consumer.</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>
PDF has control over everything except (4) and (5), and could conceivably even
make reasonable contingencies or clarifications for both. How does PDF have
control over the intent of the consumer? It doesn’t directly, of course.
But the implied intent of the consumer is PDF’s raison d’être. It
is built on the assumption that the consumer wishes to display a document in
exactly the same way it was created, now and forever, even if the original
constructing software is not available. PDF purports to separate construction
of a document from display of the completed document so that it retains its
fidelity during subsequent communications in and through hostile environments.
That is its utility. If that is not your intent, you do not need to use PDF.<br>
<br>
We have already agreed, however, that we cannot anticipate the intent of the
composite font consumer. We have imagined typographic scenarios, where details
of layout are critica</span><span style='font-size:10.5pt;font-family:"Calibri","sans-serif"'>l</span><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>. We have imagined
fallback scenarios where layout is subordinate to legibility. We have imagined
deployment in mobile environments where typography has no meaning. We have
imagined propriety systems where the intent is some implied contract outside
the composite font specification. Even if the creator had some intent, the fact
that the consumer “violates” that intent in no way invalidates the
utility of the recipe. It is the consumer who ultimately determines the utility
of what is consumed, not the creator. You can create an exquisite chocolate,
but you cannot make the eater taste it as you do.<br>
<br>
Meanwhile, what is a specification? It is a rigorous communication of intent.
Because of the many variables we cannot control, and because of inability to
anticipate the consumer’s intent, we are left to ask what it is we are
communicating. The answer is that we are communicating the creator’s
intent. That is this specification’s raison d’être. If we start
issuing instructions to the consumer about what we have decided is necessary
from that recipe, then we are no longer communicating the creator’s
intent — which is already conveyed by the recipe — but instead we
are communicating OUR intent. How did our intent come into play here?<br>
<br>
Nor do I find the argument of interoperability compelling. Any consumer who
cares about typographic fidelity ought to implement the entire specification.
If typographic fidelity is not the intent of the consumer, then what do we mean
by “interoperability”? From whose standpoint? And how does
dictating some portions of the specification but not others contribute to
interoperability? If the consumer receives a document containing a richly
specified composite font, but the consumer is only concerned with legibility,
then what is wrong with the consumer saving the document with only the
abbreviated portion of the recipe that it knows how to deal with? It is hardly
likely that the remaining traits of the original document were otherwise
preserved by the viewing application, since its purpose never was typographic
fidelity. Alternatively, what if the consumer saves the full recipe? What good
is that when it strips out all the typography of the document anyway? <br>
<br>
Hence I cannot agree that PDF provides an analogy for our circumstances. The
factors that contributed to its success differ greatly from the factors in play
here. We would be better served by looking at XML, for example. There is a case
where the specification of creator’s intent is rigorous but the consumer
is free to deal with “recipes” as best it may. Needless to say, XML
is extremely successful, and indeed we seem to have settled on it ourselves for
creating recipes.<br>
<br>
Let me suggest we issue recommendations on minimal support levels for various
consumer intentions we identify. I do not even see much harm in
“requiring” such support in order to be “compliant”
with those specific categories of intent. Perhaps that will make the job of
consumers easier: they can pick some canned definition of their intent and
implement against it without having to think hard about it. I strongly advise
against precluding implementations outside those recommendations, however. No
one is well-served by throttling innovative uses — and I have a strong
suspicion we will witness uses we never imagined.<br>
<br>
— Regards,<br>
<br>
Daniel “daan” Strebe<br>
Senior Computer Scientist<br>
Adobe Systems Incorporated<br>
<br>
<br>
On 09/09/11 7:55, "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"'><br>
<br>
<br>
<br>
<span style='color:#1F497D'>Ken,<br>
<br>
I do understand your concerns and agree that in some circumstances the mandate
to implement a particular feature may put an additional burden on the consumers
of the Composite Font recipe.<br>
<br>
At the same time, the main intent of any standardization activity is to
create an environment where multiple different implementations are compliant
and interoperable. I see the interoperability as the main benefit of standardization
since it provides a certain level of guarantee for a content creator (in this
case, for a Composite Font creator) that the font resource (a Composite Font)
and a content that uses it will be processed and presented to an end-user as
intended by the author.<br>
<br>
Developing a standard that does not provide this guarantee of baseline
interoperability defeats the purpose of standardization. We may end up having
multiple different implementations that are all compliant with the
specification but incompatible with each other, producing different results
when presented with the same content for rendering. This would be a very
unfortunate outcome. <br>
<br>
Currently, we have very few consumers that support Composite Font
functionality. For many, the Composite Fonts specification will offer a
guideline of what (and how) new features should be implemented. I am sure that
in many circumstances the implementers will appreciate specification that
provides clear and unambiguous description of the features to be supported,
rather than presenting them with many different options for implementers to
choose from. Striking the healthy balance between the core set of features
(that we want to see supported by all interoperable implementations) and a set
of optional features (that we wish to see supported) is the ultimate challenge
that in my opinion should be looked at not only from the position of the
implementer (a consumer of the Composite Font recipe) but first and foremost
from the creator point of view. PDF is a good example – its success was
to significant extent determined by the guarantees of consistency of
presentation of PDF documents it offered to content creators.<br>
<br>
Best regards,<br>
Vlad<br>
<br>
<br>
</span><br>
</span><b><span style='font-size:10.0pt;font-family:"Calibri","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Calibri","sans-serif"'> <a
href="mpeg-OTspec@yahoogroups.com">mpeg-OTspec@yahoogroups.com</a> [<a
href="mailto:mpeg-OTspec@yahoogroups.com">mailto:mpeg-OTspec@yahoogroups.com</a>]
<b>On Behalf Of </b>Ken Lunde<br>
<b>Sent:</b> Friday, September 04, 2009 4:47 PM<br>
<b>To:</b> <a href="mpeg-OTspec@yahoogroups.com">mpeg-OTspec@yahoogroups.com</a><br>
<b>Subject:</b> Re: [mpeg-OTspec] Toward a Composite Font format specification<br>
</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><br>
<br>
<br>
Vladimir,<br>
<br>
My main fear in this is that we'd be asking consumers to do something <br>
that they are already doing, or overriding it. Some consumers may lack <br>
the ability to override the behavior that dictates whether a device or <br>
embedded (or web) font is used.<br>
<br>
Ultimately, each consumer will need to decide whether it can honor the <br>
intent of the Composite Font recipe.<br>
<br>
Regards...<br>
<br>
-- Ken<br>
<br>
On 2009/08/31, at 12:17, Levantovsky, Vladimir wrote:<br>
<br>
> Ken,<br>
><br>
> I agree that existing implementations already deal with the scenarios<br>
> where fonts may be present locally and/or embedded, and that consumers<br>
> who support embedded fonts may behave differently with regard to <br>
> giving<br>
> preferences to embedded vs. local fonts. I see this uncertainty in<br>
> consumer behavior as a potential interoperability problem.<br>
><br>
> It is true that embedded fonts are most likely to be used when a<br>
> producer cares about content presentation and appearance, and this is<br>
> when the attribute about font location is likely to be present. I <br>
> think<br>
> it would be seen as a benefit to give producers a certain level of<br>
> assurance of consumer's behavior. In fact, I know that in some<br>
> environments this has already been done. For example, in Java MIDP3.0<br>
> profile - if there is an apparent conflict between embedded and local<br>
> font (e.g. both fonts have the same names), the embedded (or <br>
> downloaded)<br>
> font is always given a preference to make sure that the content is<br>
> rendered using a resource chosen by producer (author).<br>
><br>
> In general, I believe that we should try (whenever possible) to reduce<br>
> potential uncertainty in consumer behavior, especially if a feature<br>
> under consideration (e.g. a preference between embedded and local <br>
> font)<br>
> is not going to affect implementation complexity and cost. A good<br>
> specification should have a healthy balance between mandatory and<br>
> optional features - a specification that is overly strict may be <br>
> seen as<br>
> burden for implementers, but, alternatively, a specification where<br>
> everything is optional (MMS come to mind) will likely result in<br>
> producing incompatible implementations.<br>
><br>
> Regards,<br>
> Vladimir<br>
><br>
><br>
>> -----Original Message-----<br>
>> From: <a href="mpeg-OTspec@yahoogroups.com">mpeg-OTspec@yahoogroups.com</a>
<<a href="mailto:mpeg-OTspec%40yahoogroups.com">mailto:mpeg-OTspec%40yahoogroups.com</a>>
[<a href="mailto:mpeg-">mailto:mpeg-</a> <br>
>> <a href="OTspec@yahoogroups.com">OTspec@yahoogroups.com</a> <<a
href="mailto:OTspec%40yahoogroups.com">mailto:OTspec%40yahoogroups.com</a>>
]<br>
>> On Behalf Of Ken Lunde<br>
>> Sent: Saturday, August 29, 2009 10:32 AM<br>
>> To: <a href="mpeg-OTspec@yahoogroups.com">mpeg-OTspec@yahoogroups.com</a>
<<a href="mailto:mpeg-OTspec%40yahoogroups.com">mailto:mpeg-OTspec%40yahoogroups.com</a>>
<br>
>> Subject: Re: [mpeg-OTspec] Toward a Composite Font format<br>
> specification<br>
>><br>
>> Vladimir,<br>
>><br>
>> In thinking about the issue that you raised, I don't think that we<br>
>> need to worry about the case when a font with the same name exists on<br>
>> the device and also embedded in the file. Consider the fact that<br>
>> consumers who support embedded fonts already need to deal with this<br>
>> scenario, and obviously prefer one over the other. So, if this<br>
>> attribute specifies one or the other (device versus embedded), that <br>
>> is<br>
>> sufficient to guide the consumer. And, there are some consumers that<br>
>> are unable to support files with embedded fonts. Likewise, some<br>
> closed-<br>
>> environment consumers may even be unable to support device fonts,<br>
>> though there will be very few of these in the real world.<br>
>><br>
>> In any case, if the producer cares about font location (device,<br>
>> embedded, or web), what this attribute constitutes is a preference. <br>
>> If<br>
>> it is flagged as a device font, a path to the font may be included as<br>
>> part of this attribute. If it is flagged as embedded, it is treated <br>
>> as<br>
>> a boolean, because it is a binary condition.<br>
>><br>
>> My reasoning is that producers would be asking consumers to do<br>
>> something that they already support, or already have a strong<br>
>> preference one way or another, and also that producers may be<br>
>> specifying information that a consumer would be forced to ignore.<br>
>><br>
>> Feel free to prove me wrong about this issue.<br>
>><br>
>> -- Ken<br>
>><br>
>> On 2009/08/28, at 14:02, Levantovsky, Vladimir wrote:<br>
>><br>
>>> Ken,<br>
>>><br>
>>> I like your proposed approach, and I agree that issues such as<br>
>>> rendering and font access permissions should be left out of<br>
>>> composite font recipe. With regards to font location, one additional<br>
>>> case that we should consider and clarify is if the font is
embedded<br>
>>> in a document (or in a CF recipe) and is also present on a device.
I<br>
>>> believe that some implementations in these circumstances may<br>
>>> sometime disregard the embedded font and use local copy instead,<br>
>>> although I can imagine there may be circumstances when authors may<br>
>>> want the embedded font be used at all times, regardless of whether<br>
>>> the same font is present on a device (e.g. if embedded font
contains<br>
>>> additional character set that may not be part of the local font).<br>
>>><br>
>>> Regards,<br>
>>> Vladimir<br>
>>><br>
>>><br>
>>>> -----Original Message-----<br>
>>>> From: <a href="mpeg-OTspec@yahoogroups.com">mpeg-OTspec@yahoogroups.com</a>
<<a href="mailto:mpeg-OTspec%40yahoogroups.com">mailto:mpeg-OTspec%40yahoogroups.com</a>>
[<a href="mailto:mpeg-">mailto:mpeg-</a><br>
>>>> <a href="OTspec@yahoogroups.com">OTspec@yahoogroups.com</a>
<<a href="mailto:OTspec%40yahoogroups.com">mailto:OTspec%40yahoogroups.com</a>>
]<br>
>>>> On Behalf Of Ken Lunde<br>
>>>> Sent: Friday, August 28, 2009 4:41 PM<br>
>>>> To: <a href="mpeg-OTspec@yahoogroups.com">mpeg-OTspec@yahoogroups.com</a>
<<a href="mailto:mpeg-OTspec%40yahoogroups.com">mailto:mpeg-OTspec%40yahoogroups.com</a>>
<br>
>>>> Subject: Re: [mpeg-OTspec] Toward a Composite Font format<br>
>>>> specification<br>
>>>><br>
>>>> Mikhail and others,<br>
>>>><br>
>>>> Sorry for the delay. I was discussing this issue internally
with a<br>
>>>> couple different development teams. I wanted to make sure that
our<br>
>>>> bases are covered before I suggested some working definitions.<br>
>>>><br>
>>>> I like the idea of using "LocationHint" as the name
of this<br>
>>>> <ComponentFont> attribute.<br>
>>>><br>
>>>> Getting back to the issue, I think that there are three of
them to<br>
>>>> consider:<br>
>>>><br>
>>>> 1) Font location. Installed onto the device proper, meaning in
a<br>
>>>> standard location, embedded in the file that references it,
either<br>
>>>> directly or via a Composite Font recipe, or elsewhere (web
fonts).<br>
>>>><br>
>>>> 2) Rendering. Done by the OS, the application itself, or some
other<br>
>>>> rendering client such as a library.<br>
>>>><br>
>>>> 3) Access. This boils down to private versus public. In
general, if<br>
>> a<br>
>>>> font is embedded in the file that references it, it is
effectively<br>
>>>> private, and available only to the consumer. If a font is
installed<br>
>>>> on<br>
>>>> the device in a standard location, it is effectively public,<br>
>> multiple<br>
>>>> consumers have access to it, and can thus use it.<br>
>>>><br>
>>>> In the context of Composite Fonts, and considering producers
(those<br>
>>>> who create the Composite Font recipes) and consumers (those
who use<br>
>>>> or<br>
>>>> "consume" the Composite Font recipes), I cannot
think of any usage<br>
>>>> scenarios that specify how rendering is to be done. So, Issue
#2<br>
>>>> becomes moot. The consumer already knows how to handle this,
and<br>
>>>> simply knowing where to look for the font is sufficient.<br>
>>>><br>
>>>> And, Issue #3 is a non-issue in the sense that the location of
the<br>
>>>> font implies its access level.<br>
>>>><br>
>>>> Thus, what we have left is Issue #1, which is about location.<br>
>>>> Embedded<br>
>>>> fonts do not need a location, but need a name (this is
required<br>
>>>> anyway<br>
>>>> for any Component Font), and it may be useful to flag it as an<br>
>>>> embedded font. Device fonts can benefit from a location, such
as a<br>
>>>> path, and the usage scenario you gave helps. I assume that web<br>
> fonts<br>
>>>> merely require a URL.<br>
>>>><br>
>>>> The following are three definitions to consider:<br>
>>>><br>
>>>> Device font:<br>
>>>> A font installed on the device, in a standard location, and
thus<br>
>>>> accessible by multiple consumers.<br>
>>>><br>
>>>> Embedded font:<br>
>>>> A font or subset of a font that is embedded in a file that<br>
>>>> references it, and thus accessible only by the file's
consumer.<br>
>>>><br>
>>>> Web font:<br>
>>>> A font that is neither installed on the device nor embedded in
a<br>
>>>> file, but is otherwise accessible through the network.<br>
>>>><br>
>>>> Thoughts?<br>
>>>><br>
>>>> -- Ken<br>
>>>><br>
>>>> On 2009/08/26, at 15:52, Mikhail Leonov wrote:<br>
>>>><br>
>>>>> Hi Ken,<br>
>>>>> This type of issue came up in some of my recent
conversations as<br>
>>>> well.<br>
>>>>><br>
>>>>> Conceptually, recipe creators want to specify some
additional<br>
>>>>> properties about a component font, such as its location.
For some<br>
>>>>> scenarios a simple Boolean flag is sufficient, while for
other<br>
>>>>> scenarios something like a URL or an internal resource
path is<br>
>>>>> necessary.<br>
>>>>><br>
>>>>> To give an example of the latter, a document could embed 2<br>
> versions<br>
>>>>> of the same font and use different resource paths, for
example /<br>
>>>>> Resources/Fonts/1/arial.ttf and
/Resources/Fonts/2/arial.ttf.<br>
>>>>><br>
>>>>> Given there is a large number of potential methods for
storing<br>
> font<br>
>>>>> file locations, I(tm)fd like to suggest for this property
to be<br>
> opaque<br>
>>>>> and optional, akin to a hint rather than a strict
directive.<br>
>>>>><br>
>>>>> How does a new string property LocationHint sound?<br>
>>>>><br>
>>>>> Thanks!<br>
>>>>> Mikhail Leonov<br>
>>>>> Microsoft<br>
>>>>><br>
>>>>><br>
>>>>> From: <a href="mpeg-OTspec@yahoogroups.com">mpeg-OTspec@yahoogroups.com</a>
<<a href="mailto:mpeg-OTspec%40yahoogroups.com">mailto:mpeg-OTspec%40yahoogroups.com</a>>
[<a href="mailto:mpeg-">mailto:mpeg-</a><br>
>>>>> <a href="OTspec@yahoogroups.com">OTspec@yahoogroups.com</a>
<<a href="mailto:OTspec%40yahoogroups.com">mailto:OTspec%40yahoogroups.com</a>>
] On Behalf Of Ken Lunde<br>
>>>>> Sent: Wednesday, August 26, 2009 2:26 PM<br>
>>>>> To: <a href="mpeg-OTspec@yahoogroups.com">mpeg-OTspec@yahoogroups.com</a>
<<a href="mailto:mpeg-OTspec%40yahoogroups.com">mailto:mpeg-OTspec%40yahoogroups.com</a>>
<br>
>>>>> Subject: Re: [mpeg-OTspec] Toward a Composite Font format<br>
>>>>> specification<br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> All,<br>
>>>>><br>
>>>>> Slight topic deviation ahead...<br>
>>>>><br>
>>>>> I was in a meeting this morning, and its discussions led
to an<br>
> idea<br>
>>>>> for another <ComponentFont> attribute that we have
not yet<br>
>>>> considered.<br>
>>>>> Under some circumstances, especially when dealing with
embedded<br>
>>>> fonts,<br>
>>>>> it may be useful to specify whether the font is embedded
(in a<br>
> file<br>
>>>>> that references the Composite Font or the Component Font)
or<br>
>>>> available<br>
>>>>> on the device (a "device" font). This, of
course, would be<br>
>> optional,<br>
>>>>> but I guarantee that some producers will want to specify
this.<br>
>>>>><br>
>>>>> I am not sure about the best way to characterize this, in
terms of<br>
>>>>> an<br>
>>>>> attribute name, but perhaps we can state that all
<ComponentFont><br>
>>>>> instances are "device fonts" unless an
"IsEmbedded" boolean flag<br>
> is<br>
>>>>> specified.<br>
>>>>><br>
>>>>> I would welcome any thoughts about this.<br>
>>>>><br>
>>>>> -- Ken<br>
>>>>><br>
>>>>> On 2009/08/26, at 12:20, Thomas Phinney wrote:<br>
>>>>><br>
>>>>>> My first assumption would be that all scaling should
include<br>
>>>>>> scaling<br>
>>>>>> metrics, though I am mindful of the issues Karsten
brings up.<br>
>>>>>><br>
>>>>>> T<br>
>>>>>><br>
>>>>>> On Wed, Aug 26, 2009 at 9:27 AM, Daniel<br>
>>>> Strebe<<a href="dstrebe@adobe.com">dstrebe@adobe.com</a>
<<a href="mailto:dstrebe%40adobe.com">mailto:dstrebe%40adobe.com</a>>
<<a href="mailto:dstrebe%40adobe.com">mailto:dstrebe%40adobe.com</a><br>
>>>>>>>><br>
>>>>>> wrote:<br>
>>>>>>><br>
>>>>>>> Thomas,<br>
>>>>>>><br>
>>>>>>> Thanks for chiming in. To clarify, do you mean to
advocate<br>
>> scaling<br>
>>>>>>> horizontally within the same design space when you
mention faux<br>
>>>>>>> small caps?<br>
>>>>>>> (Meaning, without increasing the glyph advance
width,<br>
> escapement,<br>
>>>>>>> and<br>
>>>>>>> kerning values?)<br>
>>>>>>><br>
>>>>>>> Regards,<br>
>>>>>>><br>
>>>>>>> (tm)\ daan Strebe<br>
>>>>>>> Senior Computer Scientist<br>
>>>>>>> Adobe Systems Incorporated<br>
>>>>>>><br>
>>>>>>><br>
>>>>>>> On 09/08/25 21:51, "Thomas Phinney"<br>
>>>> <<a href="tphinney@cal.berkeley.edu">tphinney@cal.berkeley.edu</a>
<<a href="mailto:tphinney%40cal.berkeley.edu">mailto:tphinney%40cal.berkeley.edu</a>>
<<a href="mailto:tphinney%40cal.berkeley.edu">mailto:tphinney%40cal.berkeley.edu</a><br>
>>>>>>>>><br>
>>>>>>> wrote:<br>
>>>>>>><br>
>>>>>>><br>
>>>>>>><br>
>>>>>>><br>
>>>>>>><br>
>>>>>>> I'd advocate keeping the three different scaling
factors<br>
>> (overall,<br>
>>>> X<br>
>>>>>>> and Y). I can honestly imagine plenty of use cases
for them,<br>
> both<br>
>>>> in<br>
>>>>>>> traditional and non-traditional cases.<br>
>>>>>>><br>
>>>>>>> One use for asymmetric X/Y scaling is in
manufacturing small<br>
>> caps.<br>
>>>>>>> One<br>
>>>>>>> could use a composite font mechanism to build faux
small caps,<br>
>>>>>>> possibly scaled slightly so as to be slightly wider
than<br>
> strictly<br>
>>>>>>> proportional scaling. Ditto for creating numeric
(or alphabetic)<br>
>>>>>>> inferiors or superiors. Using the composite font
mechanism would<br>
>>>>>>> allow<br>
>>>>>>> for taking the base glyphs from a heavier weight
of the "same"<br>
>>>>>>> typeface....<br>
>>>>>>><br>
>>>>>>> cheers,<br>
>>>>>>><br>
>>>>>>> T<br>
>>>>>>><br>
>>>>>>><br>
>>>>>>><br>
>>>>>>><br>
>>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> --<br>
>>>>>> "Men occasionally stumble over the truth, but
most of them pick<br>
>>>>>> themselves up<br>
>>>>>> and hurry off as if nothing ever happened."<br>
>>>>>> - Sir Winston Churchill<br>
>>>>>><br>
>>>>>><br>
>>>>>> ------------------------------------<br>
>>>>>><br>
>>>>>> Yahoo! Groups Links<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>> ------------------------------------<br>
>>>><br>
>>>> Yahoo! Groups Links<br>
>>>><br>
>>>><br>
>>>><br>
>><br>
>><br>
>><br>
>> ------------------------------------<br>
>><br>
>> Yahoo! Groups Links<br>
>><br>
>><br>
>><br>
<br>
<br>
<br>
<span style='color:white'></span></span><o:p></o:p></p>
</div>
</div>
</body>
</html>