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

[Ken Lunde]

Vladimir,

I will try to put together a list/summary of the tags, elements, and  
attributes that have been discussed, either over the weekend, or  
before the Thanksgiving Day holiday break. I opened a bottle of  
Amarula that may help me with this task. :-)

Regards...

-- Ken

On 2009/11/17, at 7:21, Levantovsky, Vladimir wrote:

> I can help with editorial work to create a working draft of the  
> specification. But I think that as a pre-requisite we need to create  
> a list of tags / elements / attributes and their descriptions that  
> we agree to be part of the Composite Fonts draft specification.  
> We've had some limited discussions about it in the past - it may  
> make sense to try to review and summarize them in a single list  
> (either as an informal AHG document or in the email) that would be  
> our starting point towards the working draft.
> Vladimir
>
>> -----Original Message-----
>> From: mpeg-OTspec at yahoogroups.com [mailto:mpeg- 
>> OTspec at yahoogroups.com]
>> On Behalf Of Ken Lunde
>> Sent: Tuesday, November 17, 2009 9:39 AM
>> To: mpeg-OTspec at yahoogroups.com
>> Subject: Re: [mpeg-OTspec] Re: A path through the thicket
>>
>> 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
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>> ------------------------------------
>>
>> Yahoo! Groups Links
>>
>>
>>