[mpeg-OTspec] A path through the thicket

[Levantovsky, Vladimir]

Daniel,

 

Thank you very much for presenting the proposal and examples. Please see
my comments inline.

 

For the record (and with my AHG Chair hat on), I'd suggest avoiding a
language that may introduce a negative connotation to our discussions.
We should not be tired of any discussions where honest but conflicting
opinions are presented for the group to consider and comment - these
discussions are the only way we can resolve the differences of opinions
of AHG members and reach the consensus. (AHG Chair hat is now off.)

 

Regards,

Vladimir

 

 

From: mpeg-OTspec at yahoogroups.com [mailto:mpeg-OTspec at yahoogroups.com]
On Behalf Of Daniel Strebe
Sent: Tuesday, September 22, 2009 8:38 PM
To: mpeg-OTspec at yahoogroups.com
Subject: [mpeg-OTspec] A path through the thicket

 

  


Colleagues,

I'm sure you're all aware of, and tired of, the long debate between
Vladimir and me over what ought/ought not be part of the specification.
Pondering Leonardo's posting today, I began to think perhaps, when we
examine details, our positions might not be so far apart. This is a
proposal that I think agrees with the sensibilities of those who have
posted on the topic.

1.	Deviations from the specification when constructing or parsing a
composite font recipe are prohibited, both with regard to syntax and
semantics. This ensures precise communication of intent. 

Agree.

2.	A "compliant" consumer enables the full functionality
representable by a composite font recipe when rendering. This helps
those who want typographic fidelity to get it. 

Agree, this would be an ideal solution. We might also consider
introducing different conformance points where e.g. one subset of tools
(elements, attributes, etc.) can be defined for implementations
supporting simple scripts, and another, more elaborate subsets (or full
set) is defined for more sophisticated uses where support for complex
scripts is required.

3.	The specification acknowledges and condones partial
implementations of composite font functionality. This ensures that the
needs of consumers not concerned with typographic fidelity are met. Such
consumers must not claim "compliance". 

If we agree to introduce certain pre0defined subsets for composite fonts
functionality then partial implementations defined by those subset would
still be considered compliant implementations.

4.	The specification prohibits behavior that contradicts the
specification. This ensures those who violate the specification know
they are violating it. 

Agree

5.	The specification recommends courses of action when a recipe's
intent cannot be fulfilled due to circumstances outside the control of
the consumer. Implementations may deviate from these recommendations
without compromising compliance, since the behavior concerns exceptional
circumstances.

Agree


Some examples:

A consuming renderer does not apply the component font's transformation
matrix to glyphs. This consumer cannot claim compliance, but is not in
violation.

 

This would be true if we do not include glyph transformation as part of
a particular conformance point. E.g., I do believe that applying
transformation matrix to glyphs is an operation that does not introduce
any additional burden for implementers since most (if not all) font
engines are capable to do this.

A user interface for constructing composite fonts does not include
controls for specifying a transformation matrix. This user interface is
compliant, since it is not a consumer and since it creates compliant
recipes.

 

Agree. Unlike consumers who (in theory) have to be able to interpret and
execute any and all components of a recipe, the creators do have
complete freedom to always use only the elements they choose to be part
of a recipe.


A consuming application adds 10% extra slant to italic forms. This
consumer is in violation.

 

Agree. Any arbitrary action that is not part of original creator's
intent should be considered a violation.


A consuming application discards all instructions from the recipe other
than font selection and glyph selection from those fonts. This
applications cannot claim compliance, but is not in violation.

 

I disagree. Voluntarily discarding all/any instructions from the recipe
should be considered a violation of the creator's intent and, therefore,
violation of the spec. However, if we define a subset of instructions as
a valid conformance point, discarding instructions that are not part of
that predefined subset is not a violation.


A consuming application follows all instructions of the composite font
recipe except the per-language glyph selection instructions. Instead it
uses its own tables. This consumer is in violation.

 

Agree, this is another example of the arbitrary action by a consumer.


With regard to this final example, the distinction between "partial
implementation" and "violating implementation" might seem obscure. After
all, one might argue the consumer simply did not implement that part of
the specification. The difference is that a partial implementation
effectively removes instructions from a recipe whereas a violating
implementation effectively changes instructions. In the end the
distinction is not so important except in the sense of guiding
implementers to adhere to a recipe's instructions as closely as they can
while fulfilling their implementation's peculiar needs.

Regards,

- daan Strebe
Senior Computer Scientist
Adobe Systems Incorporated



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20090923/fd206b89/attachment.html>