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

[Ken Lunde]

Michelle,

Thank you for letting us know about Mikhail. He will be missed in the  
context of these discussions.

To the others, I want to take this opportunity to state that Adobe  
Systems plans to support this Composite Font format in our products,  
meaning as a replacement for existing Composite Font functionality in  
our applications that provide such support, along with its use for  
Font Fallback purposes. It may take one or two product release cycles  
for this to happen, but to support this standard is our intent. In  
other words, our stake in making this a useful standard is genuine.

Regards...

-- Ken

On 2009/11/20, at 12:48, Michelle Perham (HILL) wrote:

>
> All,
>
> Microsoft has been quiet on this subject over the last couple  
> months. We are still very interested in this topic, but Mikhail has  
> transitioned to a new team and has been unable to participate in the  
> discussion. We are in the process of transitioning and will reengage  
> in the near future.
>
>
>
> Thank you to those who have continued to actively drive this project.
>
>
>
> Michelle
>
>
>
>
>
> From: mpeg-OTspec at yahoogroups.com [mailto:mpeg- 
> OTspec at yahoogroups.com] On Behalf Of Levantovsky, Vladimir
> Sent: Friday, November 20, 2009 11:56 AM
> To: Ken Lunde; mpeg-OTspec at yahoogroups.com
> Subject: RE: [mpeg-OTspec] Re: A path through the thicket
>
>
>
>
>
> Thank you, Ken!
>
> And if you think the bottle of Amarula will help the work go  
> smoothly (I believe it should :) – even better. You get things done  
> while having fun – what else one can wish for before holiday break.
>
>
>
> Happy Thanksgiving!
>
> Vlad
>
>
>
>
>
> From: mpeg-OTspec at yahoogroups.com [mailto:mpeg- 
> OTspec at yahoogroups.com] On Behalf Of Ken Lunde
> Sent: Friday, November 20, 2009 2:44 PM
> To: mpeg-OTspec at yahoogroups.com
> Subject: Re: [mpeg-OTspec] Re: A path through the thicket
>
>
>
>
>
> 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
> >>
> >>
> >>
>
>
>