For both ssXX and cvXX features, the spec should say if interaction should be allowed among the features.<div><br></div><div>Certainly for ssXX, I believe the answer should be "yes" because there are plenty of good use cases for it.</div>
<div><br></div><div>For cvXX, it would be interesting to hear from SIL and any others what they think.</div><div><br></div><div>T<br><br><div class="gmail_quote">On Fri, Mar 13, 2009 at 5:12 AM, karstenluecke <span dir="ltr"><<a href="mailto:karstenluecke@yahoo.de">karstenluecke@yahoo.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">









<div style="background-color:#ffffff">


<div style="width:655px">
<div style="width:470px;margin:0;padding:0 25px 0 0;float:left">


    <div>
            <p>Character Variants (cv01-cv99)<br>
<br>
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.<br>

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.<br>

<br>
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.<br>

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.<br>
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.)<br>

<br>
Standardizing what?<br>
<br>
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?)<br>

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" (<a href="http://developer.apple.com/textfonts/WhitePapers/GXvsOTLayout.html" target="_blank">http://developer.apple.com/textfonts/WhitePapers/GXvsOTLayout.html</a>) 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".)<br>

<br>
Best wishes,<br>
Karsten Luecke<br>
<br>
</p>
 

    </div>  

    
    <div width="1" style="color:white;clear:both"></div>
        
        </div>
        
        


        


        
        
        
        
        

</blockquote></div><br><br clear="all"><br>-- <br>"Men occasionally stumble over the truth, but most of them pick themselves up<br>and hurry off as if nothing ever happened."<br>- Sir Winston Churchill<br><br><br>

</div>