[mpeg-OTspec] Toward a Composite Font format specification

[Leonardo Chiariglione]

Daniel,

Next to the two cases you mention there is a third case

 

(C) the standard specifies both (A) and (B) and the implementer declares to
what his implementation conforms with (only (B) or also (A)).

 

I entirely support your view to be factual and consider use scenarios in
order to decide whether (B) is needed. If it is you may like to consider my
option (C) 

Leonardo 

 

 

From: Daniel Strebe [mailto:dstrebe at adobe.com] 
Sent: 22 September 2009 23:31
To: leonardo at chiariglione.org; Levantovsky, Vladimir; Ken Lunde;
mpeg-OTspec at yahoogroups.com
Subject: Re: [mpeg-OTspec] Toward a Composite Font format specification

 


Leonardo:

Thank you for your considered comments. As with Vladimir’s, I do not
disagree with what you say, but merely with the applicability. Let me try
again from a different angle.

The dispute is not over how to write the specification or its language. It
is not about “shall” versus “should”. The dispute is over what it is we are
specifying.

I argue we should limit the purview of this specification to the grammar and
semantics of composite font recipes. Within the limits of this purview, I
agree entirely with your comments, as well as with their applicability. We
need an incisive specification, and we should do what we can to “enforce” it
and to insulate it from deviant industry practices.

As I understand Vladimir’s argument, the purview of the specification
should, further, require consumers to realize some subset of the
functionality described by the semantics of composite font recipes. This
body would decide upon the subset.

I oppose broadening the purview. My greatest reason is that to broaden the
purview would subject this specification to the very corrupting forces you
describe — starting with us. I do not anticipate we will be able to identify
some universally useful subset of a composite font for us to mandate.
Therefore conjuring up one will only weaken the specification: Because the
mandatory subset will not suit anyone in particular, everyone will feel
motivated to violate it. I have challenged Vladimir to explain how we could
create a mandatory subset that would not be arbitrary.

That argues that we must either (A) require consumers to realize the entire
functionality of a composite font recipe; or (B) not require consumers to
realize any particular subset of functionality.

(A) is not satisfactory because we know of many circumstances where
consumers do not need the complete functionality offered by the semantics of
composite font recipes. Presumably there are many more we do not know about.

(B) is... satisfactory? —as long as it does not cause interoperability
problems. I have asked Vladimir, and I invite anyone else as well, of
course, to identify specific scenarios that will be problematic. So far in
our discussions, none have been forthcoming. Having pondered a lot of
scenarios myself, I doubt any important ones exist. I think identifying such
scenarios should be the thrust of the conversation.

Please understand I do not argue from ideology. If, for example, we had
decided that the purpose of this specification is ONLY to communicate a
synthesis of multiple (available) OpenType fonts for the purpose of
typographic fidelity, then I would turn full circle and advocate mandating
that consumers implement the entire functionality of the specification in
order to claim conformance. But that is not what we have decided. We
recognize diverse uses for composite fonts, and we are stuck with the
reality that component fonts may not be available or may be available in
forms that deviate in various ways from the knowledge of the creator. These
considerations necessarily change what we must consider to be the purview of
the specification. If we do not adapt the purview of the specification to
the situation we face then we will write a poor specification and we will
invite implementers to flout it.

We seem to agree on the need, purpose, and structure of a specification. We
do not seem to agree on what it is we are specifying.

Regards,

— daan Strebe
Senior Computer Scientist
Adobe Systems Incorporated


On 09/09/22 8:44, "Leonardo Chiariglione" <leonardo at chiariglione.org> wrote:

Daniel,
I have been following the discussions of the group and I feel compelled to
intervene at this stage.
First of all a standard is about documenting an agreement by parties
interested in suing the agreement. Therefore I understand the language
“shall” in a standard, while I do not understand “should” (when? Every other
day? When you feel like that?).
I entirely concur that MPEG and ISO are not in the business to enforce a
proper use of their standards. What MPEG provides is 
1.     instructions on what people should do to implement a standard (the
standard itself) 

2.     the means for a third party to assess whether a claimed conformance
statement is indeed to be taken as good.

I can understand that in some cases implementers want to keep the right to
make their own implementations that do not contain the set of tools that is
written in the standard. This has happened in the past and will continue
(alas) to happen in the future. In a recent major case we changed the
standard to accommodate industry practices, but at the same time posted the
MPEG Vision (http://www.chiariglione.org/mpeg/visions/mpeg/index.htm) where
there is a non-so-subliminal message that we will not do it again.
I can understand that there are industries with different traditions and
that some people want to retain freedom to use standards the way they want.
I have nothing against that. I just would like to say that in a convergence
age the established freedoms of an industry may clash with the tenets of
another industry and that it may be so that, in the convergence process, the
second industry has more leeway.
I would encourage people to say now what they want from the standard instead
of reserving the right to take freedoms in the future. It is easy to write
one page more or add another conformance point now, instead of having
millions of clients with no status.
As we said in the MPEG vision we are not going to change our standards to
suit those who take liberties with hem

Leonardo 
 
 

From: mpeg-OTspec at yahoogroups.com [mailto:mpeg-OTspec at yahoogroups.com] On
Behalf Of Daniel Strebe
Sent: 22 September 2009 03:30
To: Levantovsky, Vladimir; Ken Lunde; mpeg-OTspec at yahoogroups.com
Subject: Re: [mpeg-OTspec] Toward a Composite Font format specification

  


Vladimir,

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.

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.

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.

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.

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.

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.

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?

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.

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 optio nal.

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. 

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.

So. If I may make some requests, I would like you to address three matters
specifically:

1.	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? 
2.	How will our decisions on “mandatory” versus “optional” be
defensible as anything better than arbitrary? 
3.	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”? 



Regards,

— daan Strebe
Senior Computer Scientist
Adobe Systems Incorporated


On 09/09/21 14:52, "Levantovsky, Vladimir"
<Vladimir.Levantovsky at MonotypeImaging.com> wrote:
Daan,
 
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.
 
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 h ardware-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. 
 
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
-         need to be compliant to pass a standardized conformance test,
and/or

-         want to advertize my product as compliant with a particular
standard.

 
Now, let’s go back to the use case you presented:
 
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.

 

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 [newly developed] 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.

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.

 

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. She is unable to meet all her objectives with any
technology that delivered content through the browser”. (emphasis is added).

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!).

 

Regards,
Vladimir
 


No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.409 / Virus Database: 270.13.110/2385 - Release Date: 09/20/09
17:51:00

No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.409 / Virus Database: 270.13.112/2387 - Release Date: 09/22/09
05:51:00

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20090923/50ec3579/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/x-ygp-stripped
Size: 126 bytes
Desc: not available
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20090923/50ec3579/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/x-ygp-stripped
Size: 126 bytes
Desc: not available
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20090923/50ec3579/attachment-0001.bin>