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

[Peter Constable]

To be more precise, Lookup tables operate on glyphs, but they are triggered by OT features, and features are attributed in the client to characters. So, I don't think there's any break in philosophy. The only innovation along this line is to introduce a Feature Parameters table that includes character information indicating what character(s) the feature is applicable to. But again, this is connected to the features, not lookups, and so is applied to the character level.

If two cvXX features are applicable to the same character and both are applied to the same string, then lookups associated with both features will be processed over that string, and the interaction of the lookups is determined by the content and relative order of those lookups as determined by the font developer. (I think it wouldn't really make sense to have two cvXX features applicable to the same character, though.)

The character information provided in the (optional) feature parameters table is intended for use by the client in determining UI behavior (should the client wish to use it).

As for comments about OT Layout in comparison with GX, let me offer a different perspective: Dave wrote, "[O]ne of the principal advantages of the GX approach is that a developer does not need to know any of the details described in the previous sections." The assertion of developers not needing to know various details is true of *software* developers, but certainly not true of font developers. So, there's just a transfer of burden.

Also, the comparison at this point is not an apples-to-apples comparison: he's comparing the OT font format with the GX line-layout implementation. If a developer is presented with nothing more than the GX font format, e.g. if implementing support for TrueType GX fonts on Windows or Linux, then there are additional details (granted, not exactly all the same ones discussed earlier in the paper) they must take into consideration than if they were developing an app in a context in which GX line layout already existed. A software developer creating an implementation of GDEF, GSUB and GPOS tables has certain additional work; and a software developer creating an implementation of the feat, mort, and prop tables has certain additional work; it's just different work in each case. I think a more even comparison with GX layout and ATSUI would be GDI text, WPF, DirectWrite or similar APIs: developers writing at these levels just need to know how to use the APIs correctly, and most or all of the details are handled for them.

I won't comment on dead ends-this isn't an appropriate forum for that.


Peter

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


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

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