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

[Thomas Phinney]

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>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/6caa1e93/attachment.html>