<html><head><style data-externalstyle="true">
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
}

p.MsoListParagraphCxSpFirst, li.MsoListParagraphCxSpFirst, div.MsoListParagraphCxSpFirst, p.MsoListParagraphCxSpMiddle, li.MsoListParagraphCxSpMiddle, div.MsoListParagraphCxSpMiddle, p.MsoListParagraphCxSpLast, li.MsoListParagraphCxSpLast, div.MsoListParagraphCxSpLast {
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
line-height:115%;
}
</style></head><body><div data-externalstyle="false" style="font-family:Calibri,'Segoe UI',Meiryo,'Microsoft YaHei UI','Microsoft JhengHei UI','Malgun Gothic','Khmer UI','Nirmala UI',Tunga,'Lao UI',Ebrima,sans-serif;font-size:16px;"><div>

<p>Forwarding on behalf of Andrew Glass</p><p> </p><p>-----Original Message-----</p><p>From: Andrew Glass (WINDOWS) </p><p>Sent: 17 January 2013 13:52</p><p>To: 'Behdad Esfahbod'; Michelle Perham</p><p>Cc: <a tabindex="-1" href="mailto:opentype-migration-list@indx.co.uk">opentype-migration-list@indx.co.uk</a>;
OTspec ()</p><p data-focusfrompointer="true">Subject: RE: [mpeg-OTspec] MS Proposal: new feature tag</p><p> </p><p>Hi Behdad,</p><p> </p><p>Thank you for your feedback. My comments inline.</p><p> </p><p>Andrew</p><p> </p><p> </p><p>There's simply no reason to not introduce a new lookup
type for this.</p><p>[Andrew Glass] Using the proposed feature and updating
the rendering engine means that this functionality is available to existing
applications. That would not be the case if a new feature were introduced.</p><p> </p><p>Moreover, I think it needs more thought.  For example, the proposed 5-piece format is
suitable for the Syriac Abbreviation Mark, but not Arabic Safha mark, etc, in
which different glyphs need to be chosen based on the width of the glyphs they
"enclose".</p><p>[Andrew Glass] The proposed feature is not intended to
solve all rendering issues involving enclosing signs, only those that are
amenable to stretching using repeated elements.</p><p> </p><p>There's a lot of similarity / overlap between this and
JSTF and MATH tables.</p><p>Moreover, there's an architectural mismatch between this
feature and</p><p>GSUB/GPOS: with the proposed feature, some glyph
substitution has to happen</p><p>*after* GPOS is done.</p><p>[Andrew Glass] This is incorrect. The feature triggers
the substitution with GSUB. Any mark positioning is done in GPOS. Then the
rendering engine is positions the fixed components of the substitution,
calculates the number of spacing components needed to fill the space, and
positions them.</p><p> </p><p> </p><p>For these reasons, I like to suggest that:</p><p> </p><p>  * No existing
lookup to be used for this (for simple compatibility reasons), [Andrew Glass]
What compatibility issues do you anticipate?</p><p> </p><p>  * The problem be
studied in more depth, [Andrew Glass] Since there will not be enough time to
resolve this discussion now, we are happy to shelve the proposal for a later
date.</p><p> </p><p>  * New structures
be developed to address this, either in GSUB, or possibly in JSTF.</p><p>[Andrew Glass] Having new structures will likely lead to
compatibility issues.</p><p> </p>

</div><div data-signatureblock="true"><div> </div><div>Sent from Windows Mail</div><div> </div></div></div></body></html>