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

[Levantovsky, Vladimir]

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