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

[Leonardo Chiariglione]

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 original 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
its 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 that 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20091003/9f451586/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/x-ygp-stripped
Size: 126 bytes
Desc: not available
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20091003/9f451586/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/x-ygp-stripped
Size: 126 bytes
Desc: not available
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20091003/9f451586/attachment-0001.bin>