[mpeg-OTspec] OFF "cv01"-"cv99", and a more general question

[Peter Constable]

In the intended usage scenarios for cvXX, I can see more than one feature being applied to the same text, but I would not expect more than one feature to have lookups affecting any given character. E.g. if cv01 is used for variants of "a", then I would expect all the variants of "a" to be accessed using cv01 rather than having some variants of "a" accessed using cv01 but other variants of "a" accessed using a different cvXX feature.

If that is done, then there will not be any interactions between different cvXX features: they will affect mutually exclusive sets of characters.


Peter

From: mpeg-OTspec at yahoogroups.com [mailto:mpeg-OTspec at yahoogroups.com] On Behalf Of Thomas Phinney
Sent: Friday, March 13, 2009 9:13 AM
To: karstenluecke
Cc: mpeg-OTspec at yahoogroups.com
Subject: Re: [mpeg-OTspec] OFF "cv01"-"cv99", and a more general question


For both ssXX and cvXX features, the spec should say if interaction should be allowed among the features.

Certainly for ssXX, I believe the answer should be "yes" because there are plenty of good use cases for it.

For cvXX, it would be interesting to hear from SIL and any others what they think.

T
On Fri, Mar 13, 2009 at 5:12 AM, karstenluecke <karstenluecke at yahoo.de<mailto:karstenluecke at yahoo.de>> wrote:

Character Variants (cv01-cv99)

So far, OT layout tables operate on glyph level, not on character level. Once 'cmap' has mapped codepoints to GIDs, the character level is completely ignored. Now character variants smuggle in character level information (optionally?) which seems to "break" the OTL philosophy.
That you suggest doing it is interesting though because it indicates that typographic layout behavior may require more than glyph level information and that OT's inherent neglect of the character level (like paragraph, line, word boundaries) makes it hard or impossible to do certain things.

How is this to be implemented? I could imagine that 'cvXX' features that relate to the same character would be treated as mutually exclusive (a UI could automatically group 'cvXX' features that relate to the same source character/GID) while those that relate to different characters could be applied additively. So in effect one would have different groups of 'cvXX' features, within each groups mutually exclusive, but groups are additive to each other.
It could work the same way if no codepoints are provided and glyphs are identified by GID. So I don't really see a need for character level information. But may miss something.
The behavior I sketched implies that 'cvXX' features should NOT interact with each other, as InDesign's implementation of the 'ssXX' features allows. (I am not sure if mutually-exclusive or additive support of 'ssXX' features is considered as "normal" behavior.)

Standardizing what?

You are making OT/OFF a standard. Specifying a font format however is just part one which is of limited use without part two: defining what a text/layout engine is to do with the data a font provides, and what to do before applying behavior defined in layout tables. (So why not add a documentation of what WPF or Uniscribe do, as models for other text/layout engines?)
For example, I heard that people have problems supporting the 'curs' feature / GPOS lookup type 3. And some minutes ago I found Mr Opstad's old document "Comparing GX Line Layout and OpenType layout" (http://developer.apple.com/textfonts/WhitePapers/GXvsOTLayout.html) which, in the last section "The system support question", pointed out this conceptual flaw already in 1997, and as far as I see nothing has changed about it. (Btw, OT layout tables seem to be dead end when it comes to complex layout behavior, which is nicely illustrated in the Opstad-paper's comparison of GX's "state machines" vs OT's mere "string matches" in the sections "Contextual"/"Ligature"/"Insertion".)

Best wishes,
Karsten Luecke



--
"Men occasionally stumble over the truth, but most of them pick themselves up
and hurry off as if nothing ever happened."
- Sir Winston Churchill


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