[mpeg-OTspec] Re: A path through the thicket

[Ken Lunde]

All,

In the spirit of trying to move this project forward, and given that  
there is overwhelming agreement that it is best to defer further  
discussion in favor of working on a draft specification, is there  
anyone who is specifically tasked with writing the draft specification?

Regards...

-- Ken

On 2009/11/02, at 16:23, Daniel Strebe wrote:

>
>
> Vladimir:
>
> Thank you for proposing we defer further discussion in favor of  
> working on the specification. I think that is a wise proposal. We  
> can proceed much of the way on what we already know, especially  
> since we all seem to agree on what a complete implementation should  
> look like. We may digress into exploratory phases and  dead ends  
> along the way, but that would be preferable to choosing an  
> unfavorable policy and adhering to it just on ideological grounds. I  
> certainly agree we will be better informed later than now.
>
> Regards,
>
> Daniel “daan” Strebe
> Senior Computer Scientist
> Adobe Systems Incorporated
>
>
> On 09/10/30 2:09, "Levantovsky, Vladimir" <Vladimir.Levantovsky at MonotypeImaging.com 
> > wrote:
>
> Daniel, all,
>
> The MPEG summary document I submitted earlier outlines few use cases  
> where compliance to the Composite Fonts specification (and full  
> interoperability between different clients or components of the  
> system) would be critical to achieve the stated goals. Among them, I  
> believe that the use case entitled “Interactive Rich Media  
> Environment” would probably be a “train wreck” scenario if there is  
> a lack of interoperability between different tools that are used for  
> media content creation, multiple different implementations from  
> different vendors and Composite Fonts sourced from different  
> foundries. This use case represents real-life scenario that is  
> considered by the industry - we can discuss this case in more  
> details to flesh out some of the details if necessary.
>
> However, I don’t want this discussions to stifle the progress of the  
> development of the specification itself. I strongly believe that  
> once we have the draft of the specification ready we will be better  
> equipped to evaluate the complexity of future implementations, and  
> make educated decisions on whether mandating a particular set of  
> tools would make any significant impact on the overall cost and  
> complexity of the Composite Font solution. I would like to encourage  
> all AHG participants to contribute their ideas and suggestions of  
> the tools (tags, elements, attributes, and their brief descriptions)  
> that should be part of the CF solution.
>
> Thank you and regards,
> Vladimir
>
>
>
>
>
> From: Daniel Strebe [mailto:dstrebe at adobe.com]
> Sent: Wednesday, October 21, 2009 3:54 PM
> To: Levantovsky, Vladimir; mpeg-OTspec at yahoogroups.com
> Subject: Re: A path through the thicket
>
>
> Vladimir,
>
> Thanks for the comments. I think we need to talk about specific  
> scenarios in order to make progress; we can only go so far on  
> principles when ultimately we must deal with reality. May I ask you  
> to describe what you consider to be a “train-wreck” scenario in my  
> advocacy? That would force me to see the error of my ways or allow  
> me to clarify misunderstandings or to correct mistaken inferences.  
> It will give us all a chance to contrast the pros and cons of the  
> descriptive versus prescriptive models as they apply to realistic  
> scenarios.
>
> As for whether this committee is an actor or not is merely a matter  
> of reasonable differences of definition unrelated to whatever we  
> really are. It is what we really are that matters. It can be helpful  
> to think of us as actors, since our intent will persist in the  
> specification. Likewise it can be helpful to think of fonts as  
> tools, for example, even though I categorized them as resources. I  
> would prefer not to worry too much about arbitrary categorizations.  
> In particular, we would be wise not to let what we call something  
> influence our understanding of what it is, but, rather, let our  
> understanding of what it is influence what we call it.
>
> Thanks & regards,
>
> Daniel “daan” Strebe
> Senior Computer Scientist
> Adobe Systems Incorporated
>
>
> On 09/10/21 8:00, "Levantovsky, Vladimir" <vladimir.levantovsky at monotypeimaging.com 
> > wrote:
>
>
>
>
> Daniel, Leonardo, all,
>
> I’d like to thank Daniel for his efforts and dedication to  
> developing the Composite Fonts specification; however, I disagree  
> with some of the Daniel’s definition of the actors and tools, and  
> believe that certain clarifications would help to further understand  
> the realities we face with.
>
> In my opinion, the most important aspect is to clearly understand  
> the relationship between different types of consumers of the  
> Composite Font specification and definition of the “consuming  
> author” as a category. While working on the Composite Fonts Design  
> Philosophy and policies we acknowledged and agreed that deployment  
> environments are diverse and that public environments will need  
> explicit state to be defined while private (controlled) environments  
> may need less explicit state than public. The definition of the  
> “consuming author”, as presented by Daniel, seems to address only  
> the latter (private, controlled environments) where the “consuming  
> author” may indeed play different roles and be a content creator,  
> content consumer and tool/implementation vendor at the same time.  
> However, in public environments this will rarely (if ever) be the  
> case, and the category of “consuming author” will include
> -         composite font recipe creators,
>
> -         content creators,
>
> -         authoring tool vendors,
>
> -         developers of the consuming implementations (content  
> players,) and
>
> -         content consumers.
>
>
> For these different and diverse categories of consuming authors to  
> interact successfully – tools for creating composite font recipes,  
> content authoring tools and content player implementations must be  
> conformant to the Composite Font specification to ensure that the  
> content, created using the intent expressed by a Composite Font  
> recipe, is presented to a content consumer in the same way as  
> envisioned by a content creator. This is why it is necessary for  
> public environments to strictly follow the recipe intent and to  
> mandate compliance between different consuming implementations.
>
> I also disagree with Daniel on the inclusion of this AHG (or, in  
> general, a standard development body) as an actor. As soon as the  
> specification is finalized and approved, this AHG body will cease to  
> exist and will never be in a position to govern the interpretation  
> or implementation details of the standard. Our responsibility is to  
> ensure that the text of the specification we will have produced is  
> clear and unambiguous, and that all necessary resources (such as  
> conformance document and standardized test cases, if applicable) are  
> available for implementers of the standard.
>
> Thank you and regards,
> Vladimir
>
>
>
>
> From: mpeg-OTspec at yahoogroups.com [mailto:mpeg- 
> OTspec at yahoogroups.com] On Behalf Of Daniel Strebe
> Sent: Tuesday, October 20, 2009 7:28 PM
> To: leonardo at chiariglione.org; mpeg-OTspec at yahoogroups.com
> Subject: Re: [mpeg-OTspec] Re: A path through the thicket
>
>
>
>
> Leonardo:
>
> Thank you for your continued interest in this discussion.
>
> “Composite font recipe” is a formal text of observations on how to  
> aggregate, or instructions for aggregating, multiple specific  
> “component fonts” to act as a single font of enhanced capabilities.  
> A recipe adheres to the semantics and grammar (the “composite font  
> specification”) to be defined by this ad hoc committee. Whether a  
> recipe should embody observations (description) or instructions  
> (prescription) is controversial in this discussion.
>
> A “consuming author” is someone who creates content by using a  
> composite font recipe (and presumably many other resources and tools).
>
> “Recipe creator’s intent” is the whatever the person who wrote the  
> recipe intended by the recipe. The significance and scope of this  
> intent is controversial in this discussion. Simplistically, I aver  
> that the recipe creator’s intent for dynamic circumstances cannot be  
> embodied in a static recipe. I further aver that the recipe  
> creator’s intent, insofar as there is one, may not reflect the  
> consuming author’s needs or intent. Hence the intent should be  
> interpreted as a description or set of observations, with no need  
> for intervention by this committee. Vladimir’s advocacy, as I  
> understand it, is that the intent should be interpreted as a  
> prescription, subject to exemptions specified by this committee.
>
> To address your broader request, we have:
>
> Resources
> Component fonts (extant)
>    Composite font recipe
>    Composite font specification
>
> Actors
> Composite font recipe creator
>    Consuming author
>    This committee
>
> Tools
> Consuming implementation (that is, consuming composite font recipes)
>    Producing implementation (that is, producing composite font  
> recipes)
>
> Results
> Content
>
> I think everyone agrees on this description:
>
> This committee defines composite font specification. Composite font  
> recipe creator uses producing implementation to create composite  
> font recipe adhering to composite font specification. Consuming  
> implementation uses composite font specification to interpret  
> composite font recipe. Consuming author uses consuming  
> implementation to exploit composite font recipe’s aggregation of  
> component fonts in order to create content.
>
> The primary controversy seems to be over whether a composite font  
> recipe ought to be descriptive or prescriptive. I think most of the  
> ancillary controversies arise out of that one. My claim is that  
> recipes can be purely descriptive without compromising  
> interoperability, and that designating them as descriptive brings  
> benefits of expressiveness, robustness, flexibility, ease of  
> authorship, ease of interpretation, clearer division of roles, and a  
> simpler specification.
>
> Regards,
> — daan Strebe
>
>
> On 09/10/03 1:27, "Leonardo Chiariglione"  
> <leonardo at chiariglione.org> wrote:
>
> Daniel,
> I have been trying to follow your terminology. I realise that in  
> your world this may be consolidated, but not in mine:
> Recipe creator’s intent
> Consuming author
> Composite font recipe
> And others
> In other words, I would like to have the complete “font” value chain  
> outlined and defined. I think this would be useful to clarify what  
> is that the standard needs to do
> Leonardo
>
>
> From: mpeg-OTspec at yahoogroups.com [mailto:mpeg- 
> OTspec at yahoogroups.com] On Behalf Of Daniel Strebe
> Sent: 01 October 2009 03:38
> To: mpeg-OTspec at yahoogroups.com
> Subject: [mpeg-OTspec] Re: A path through the thicket
>
>
>
> Vladimir:
>
> I appreciate the effort you put into these responses. I apologize  
> for this very lengthy response. Here is a synopsis for those who  
> need to ration their reading time:
>
> 1. Rebuttal of the thesis that the situation with Web browsers  
> argues for more imperatives in this specification.
> 2. Why we won't be able codify the useful possibilities for  
> composite fonts.
> 3. Why the recipe creator's "intent" is not what is important, but  
> rather the consuming author's intent that is important.
> 4. A composite font recipe is not content, it is a resource;  
> therefore the requirement of fidelity to its instructions depends  
> upon context.
> 5. Examples of composite font usage to clarify when fidelity is/ 
> isn't useful.
> 6. My interpretation of Vladimir's proposal, juxtaposed against my  
> proposal. (You might find this instructive.)
> 7. More responses to specific arguments posed by Vladimir.
> 8. A list of objections to Vladimir's proposal.
> 9. Conclusions
>
> 1. Browsers as an analogy to composite fonts
>
> I do not agree with Vladimir's analysis of the situation with Web  
> browsers today or the failures of the W3C recommendations, and  
> therefore I do not agree with the conclusions Vladimir draws. The  
> World Wide Web was not conceived to deliver final-form presentation.  
> We could go into great depth on this matter, but it is peripheral to  
> the discussion, so I will leave it by averring that many Web  
> designer vexations arise out of the natural tension between their  
> need for design and the Web's need to deliver content on displays of  
> unknown resolution and unknown color space, on devices of unknown  
> computational capacity, in unknown window sizes, and using possibly  
> unavailable resources—like fonts — a problem that is still not  
> solved 15+ years later.
>
> To a fair extent the reality of these unknowns forced specifications  
> that allow choice in implementation along with soft failure. I do  
> not claim that no mistakes were made; I do not know enough about  
> those standards to know what mistakes were made and how grave. But  
> my understanding of their purpose does not match the premise of  
> Vladimir's argument well.
>
> 2. On codifying useful possibilities for composite fonts
>
> To return to my elaborate example, Marina's hypothetical problems  
> would not have been alleviated by "better" standards. It is  
> pointless for Web browsers to implement typographical features when  
> the designer's desired font generally isn't even available on the  
> viewing computer. A standard can't do anything about copyright  
> restrictions. If and when legal, commercial, and technical remedies  
> arrive on the scene to deliver the fonts content designers want to  
> Web pages, then surely we will see browsers supporting typography  
> with ever greater sophistication.
>
> Conversely, if standards had dictated such typographical  
> sophistication from the outset, despite its uselessness, the barrier  
> to entering the browser market would have been higher, and expensive  
> effort would have been diverted from more useful functionality  
> elsewhere. This is why I contrived such an elaborate scenario.  
> Marina's quandary arises from conditions that exist now. They did  
> not exist three years ago because there was no RIA framework for her  
> to use. They probably will not exist three years from now because  
> better typography probably will arrive in browsers and RIA  
> frameworks once the type delivery service she subscribed to becomes  
> commonplace.
>
> Meanwhile, we, sitting here now comfortably at our computers  
> contemplating conditions as they exist now, will find ourselves  
> unable to enumerate all the uses people will find for composite  
> fonts even today, let alone five years from now. Therefore I do not  
> understand why we should fossilize our ignorance in a specification.  
> What we do know, or can puzzle through, is what kinds of things  
> people are likely to want to communicate with composite fonts.  
> Therefore we should provide a language for this communication — but  
> we should leave the actions of the communicators up to those who  
> know what they are trying to achieve.
>
> 3. Why the recipe creator's "intent" may not be important, and what is
>
> To address an implicit axiom in Vladimir's arguments, the intent of  
> the composite font creator is not the only intent in play. What we  
> have been calling a consumer — because it consumes a composite font  
> recipe — may also be a content author. This "consuming author" has  
> an intent we know nothing about, but by definition creative forces  
> are in play. Whom are we helping if we stifle those creative forces  
> by shoving them into the only channels we foresaw or that we felt  
> were "important"? To the human authoring that content, our  
> specification means nothing and the composite font recipe means  
> opportunities. That human wants the software "she" is using to do  
> what she expects it to do. How that software adapts an incoming  
> composite font recipe to its purposes is not our business. It is not  
> even the business of the recipe creator. It is the business of the  
> creative mind operating the software because what comes out of that  
> creative mind is or! iginal co ntent. The font is just a tool in  
> creating that content.
>
> The consuming author has a reason for consuming composite fonts.  
> Therefore the consuming author must be interested in what a  
> composite font recipe has to say. That means the language the  
> composite font speaks must be clear, but it does not mean the  
> consuming author is interested in everything the recipe has to say.  
> A font is not content. It is a tool or a resource. It may contain  
> elements extraneous to the content for which it is being exploited.  
> We must not confuse ourselves into lumping composite font recipes  
> into the same category as MPEG videos or PDF, where fidelity of  
> content must be preserved because fidelity of content is the purpose.
>
> A font contains instructions. The purpose of the instructions is for  
> the font to be used usefully. What is useful varies from  
> circumstance to circumstance. The circumstances are innumerable.
>
> 4. On fidelity to the recipe, and when it is/isn't important
>
> I do not discount the need for fidelity, but we need to be clear  
> about what kind of fidelity we are talking about and why it is  
> important. If Vladimir's argument is that consumers must retain the  
> fidelity of the recipe creator's intent, then I completely disagree.  
> For one thing, it's frankly none of the recipe creator's business  
> how the tool "he" created gets used insofar as other interests are  
> not harmed. For another, the creator will be unable to express all  
> the ways he might be willing for the recipe to be used, both because  
> we will not provide a language so complicated and because creators  
> won't want to burden themselves with the infinite permutations of  
> pedantic intent that consumers might find useful. Both the creator  
> and the consumer would wonder what the point is, and the creator is  
> probably even less likely to envision all the useful scenarios than  
> we are. Just because a creator forgot to mention that he's fine with  
> his composite font being used just for i! ts glyph mappings is no  
> reason someone shouldn't use it for that.
>
> When does fidelity to the recipe creator's intent need to be  
> preserved? When the recipe itself becomes part of the instructions  
> for reproducing content. In other words, when the consuming author's  
> content relies on the composite font recipe for whatever form of  
> fidelity it needs. Since what is meaningful to preserve varies from  
> content category to content category, and since neither we nor the  
> recipe creator knows the consuming author's intent, it follows that  
> we cannot be in the business of dictating what portions of a  
> composite font recipe a consuming author's software is allowed to  
> honor or discard.
>
> 5. Examples of when fidelity to a recipe is/isn't important
>
> Example A, page layout software: In page layout software, the  
> composite font recipe will be relied upon to create consuming  
> author's content. Moreover this reliance likely extends to the most  
> minute details of glyph placement. Most content authors will expect  
> a composite font to work the same regardless of what page layout  
> software or word processor they use. Because page layout software's  
> purpose is typographic fidelity, and because the composite font  
> recipe's creator is likely to know more about the typography of the  
> fonts in the recipe than the authors of the page layout software  
> (who probably don't even know about the component fonts  
> specifically), a normal implementation would be a complete one.
>
> In practice, we are likely to see page layout software either not  
> implement composite fonts or else implement the specification in its  
> entirety. Partial implementations, at least as far as body text  
> goes, would confuse content authors and reflect unfavorably on the  
> page layout software publisher. They could result in imported  
> content getting formatted differently from the original. Still,  
> there may be interesting uses for partial implementations outside of  
> body text.
>
> Example B, markup languages: In markup languages that include  
> presentation semantics, some kinds of formatting are provided for  
> while still conforming to environmental constraints. Normally this  
> means line breaks are absent in the content, but some kinds of  
> character and block formatting are present. Their presence ranges  
> from fairly abstract ("header") to fairly concrete ("underline"),  
> depending upon the particular attribute and and upon the particular  
> markup language. Some provide for font categories ("Serif"); some  
> provide for font names.
>
> A composite font could provide for typographic and formatting  
> control beyond the scope or intent of a renderer of the markup  
> language. One could argue for nearly any range of composite font  
> support in this context. If the renderer is a markup editor in  
> "source" view, typographic needs might not exist. A composite font  
> might get selected for some purely semantic reason, such as glyph  
> complement, with no intent or need for typographic control because  
> the editor's reason for choosing the composite font is only to be  
> able to render any glyph expressed within literal strings.
>
> If the markup editor provides a "Preview" mode to see the content  
> formatted, how much typography the mode should enable depends on  
> what expected target systems will be able to render. If the markup  
> language does not even provide a mechanism to designate the specific  
> font for rendering, then clearly the "preview" amounts to little  
> more than a "mock-up", and the need to support various features of  
> composite fonts becomes highly questionable. Transmission fidelity  
> means nothing because the font is not part of the markup.
>
> If, on the other hand, the specific font can be declared in the  
> markup, then the markup editor ought to enable any typographic  
> features that do not conflict with the markup itself. We are in no  
> position to decide what that means in the general case. We may want  
> the rendering engine to honor the small-caps instructions in the  
> composite font recipe, for example, but the markup language or the  
> style guide for the renderer may dictate that all-caps must be used.  
> Or we may declare that a compliant renderer honor the glyph mappings  
> of the composite font, but this markup includes mathematical  
> expressions. The renderer is happy to use the composite font recipe  
> for text, but it knows a lot more about mathematics than we do and  
> than the generic markup editor did, so it always renders formulæ  
> according to a specific font it knows behaves according to its own  
> precise layout needs.
>
> It should be clear from these examples, including the earlier  
> elaborate example of Marina and her cartographic project, that we  
> can contrive plausible subsets of functionality ad nauseum, and  
> therefore that we will never anticipate all the diverse, legitimate  
> uses of composite fonts.
>
> 6. What the contrasting proposals look like
>
> What Vladimir's proposal looks like to me:
>
>    Recipe creator states "his" intent:
>        1. You must shift baseline of Font A 6 design units upward  
> with respect to Font B.
>        2. You must shear glyphs of Font C 4° rightward from base to  
> top with respect to other fonts in the recipe.
>        3. You must map Unicode range W–X to Font C for Latin script,  
> X+1–Y to Font D for Chinese, Y+1–Z to Font E for mathematical  
> symbols...
>
>    We inject our intent here:
>        1. You must implement.
>        2. You may ignore if you declare yourself to be a partially  
> compliant renderer according to Compliant Subset D.
>        3. You may ignore if you are a Latin-script-only renderer  
> according to Compliant Subset E.
>
>    Consumer compares her intent against recipe creator's intent and  
> our intent:
>        1. I am in violation because I do not need to shift baselines  
> because I do not mix component fonts on a single line.
>        2. I need the design characteristics to match, so I shear  
> glyphs.
>        3. I am in violation because I always use Cambria Math for  
> mathematical symbols because I can't lay out equations reliably  
> using arbitrary fonts.
>
> with the result that the recipe creator was unable to state his real  
> intent because his real intent was merely to describe how the  
> components of the composite font can work together to achieve the  
> illusion of a single font, not to dictate what features of the  
> composite font must be used, since he has no idea what the consumer  
> needs anyway. The consumer, whose implementation suits her purposes  
> precisely, does not comply with any recognized subset. Output  
> downstream gives idiosyncratic results because the specification  
> requires her to pass through the composite font recipe unmodified  
> (in order to honor the recipe creator's intent and ignore her use of  
> it).
>
> What my proposal looks like to me:
>
>    Recipe creator states his observations that:
>        1. Shifting baseline of Font A 6 design units upward with  
> respect to Font B gives uniform baselines.
>        2. Shearing glyphs of Font C 4° rightward from base to top  
> with respect to other fonts in the recipe gives matching oblique  
> angles.
>        3.     Mapping Unicode range W–X to Font C gives correct  
> results for Latin scripts.
>            Mapping X+1–Y to Font D for Chinese gives correct results  
> for simplified Chinese.
>            Mapping Y+1–Z to Font E gives correct results for  
> mathematical symbols.
>            ...
>
>    We inject no intent.
>
>    Consumer compares her intent against recipe creator's  
> observations and our intent:
>        1. I do not need to shift baselines because I never mix  
> composite font components on a line.
>        2. I need the design characteristics to match, so I shear  
> glyphs.
>        3. I always use Cambria Math for mathematical symbols because  
> it is impossible to lay out equations reliably using arbitrary fonts.
>
> with the result that this consumer got exactly what she wanted  
> without violating the specification, without violating the creator's  
> intent, and without harming anyone's interests. All output  
> downstream from her deployment behaves correctly because she only  
> passed through the portion of the composite font recipe that she  
> actually deployed... or because her output is in final-form, not  
> dependent upon anything external to the final-form document.
>
> 7. Responses to some specific arguments posed by Vladimir
>
> I sympathize with Vladimir's argument that implementers will look to  
> the specification for guidance even when they only implement part of  
> it. However, I am unable to come up with realistic scenarios that  
> require "interoperability" at partial levels. In scenarios I have  
> managed to contrive, partial implementations are generally dead-end  
> consumers or else their output would always be final-form. Neither  
> scenario requires adherence to some canonized subset, nor does it  
> seem like the situation would confuse implementers, since they have  
> a clear idea of what they need. To ensure fidelity downstream when  
> exporting its content, Partial Implementation A should simply excise  
> those portions of a recipe that it did not use. (I would go so far  
> as to say we should require this.) This way any consuming  
> implementation that is a superset of Partial Implementation A (such  
> as a full implementation) will deliver fidelity to the content  
> created by Partial Implementation A. The odds th! at downst ream  
> consumer Partial Implementation B is both a partial implementation  
> and carries the similar needs and intent as Partial Implementation A  
> is remote unless the two already know about each other in some  
> private or semi-private contract. Therefore our intervention adds  
> little value, if any.
>
> For example, Vladimir notes "...We can specify one subset that would  
> be sufficient for authors creating content utilizing simple scripts  
> only". But if we look at the sorts of functionality we propose for  
> composite fonts, none of it really applies to simple versus complex  
> scripts. Whether a given implementation will work with complex  
> scripts depends on its general font and language handling machinery,  
> not upon whether it supports some feature of composite fonts.  
> Meanwhile "simple script" support means different things to  
> different layout engines. We are not going to convince an  
> established layout engine to improve or change its implementation of  
> "simple scripts" just to gain "compliance" with whatever we decide  
> is meaningful — particularly when our "requirements" actually turn  
> out to be orthogonal to executing the instructions of a composite  
> font recipe.
>
> Vladimir states, "[Consumers] must be able to scale fonts and/or  
> individual glyphs and their metrics to ensure correct layout... I  
> believe that since all existing font engines today support scalable  
> fonts and are capable to do this, the requirement does not present  
> any additional burden on implementations." To which I respond that  
> code must be written to interpret the semantics of the scaling,  
> adjust positioning, and to instruct the font engine to perform the  
> scaling — and even then coding is only a portion of the cost of  
> deploying an implementation. Meanwhile, if such scaling is  
> irrelevant to the content the consuming author creates, who benefits  
> by requiring it?
>
> 8. Ten objections to Vladimir's proposal
>
> To reiterate: I am happy for this committee to prepare a standard  
> for a "complete" implementation. I think that will be of the most  
> interest to the most people, and it covers the most demanding case:  
> typographic fidelity. I am not at all happy to canonize some subset  
> of partial implementations. My objections are:
>    1. We will unable to enumerate all the useful possibilities.
>    2. We do not have the resources to labor over those possibilities  
> we would come up with.
>    3. We do not have the wisdom to winnow down the possibilities  
> into some manageable collection that suits (almost) all needs.
>    4. Whatever list we might come up with would be fragile in the  
> face of technology and market forces.
>    5. Any given partial implementation will not have a large enough  
> constituency for us to expend such effort on.
>    6. Canonized subsets distract and dilute our ability to encourage  
> and "enforce" the complete typographic case.
>    7. We will invite confusion over the meaning of recipes by  
> condoning a special subset of exceptions to their imperatives.
>    8. By considering the recipe's instructions as imperatives at  
> all, we exclude useful possibilities the recipe otherwise implies.
>    9. We will stifle innovate uses which themselves do not harm  
> other interests.
>  10. We will be injecting our own intent into areas we have no  
> business doing so.
>
> 9. In conclusion
>
> We should allow partial implementations to support those aspects of  
> the specification that they need. We should instruct that partial  
> implementations must alter the recipes they consume to reflect their  
> requirements for fidelity in the content they generate. We should  
> instruct anyone intending for broad interoperability to implement  
> the complete specification. We should not add to the specification  
> such requirements for font feature support that are orthogonal to  
> the business of executing the instructions in font recipes.
>
> Regards,
>
> — daan Strebe
> Senior Computer Scientist
> Adobe Systems Incorporated
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.5.409 / Virus Database: 270.13.114/2401 - Release Date:  
> 09/30/09 10:35:00
>
>
>
>
>
>
>