[mpeg-OTspec] Toward a Composite Font format specification

[Daniel Strebe]

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 optional.

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

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20090921/59d10b45/attachment.html>