RE: [mpeg-OTspec] MS Proposal: new feature tag

Simon Daniels MSFT iloveverdana at hotmail.com
Thu Jan 17 23:02:12 CET 2013


Forwarding on behalf of Andrew Glass

 

-----Original Message-----

From: Andrew Glass (WINDOWS) 

Sent: 17 January 2013 13:52

To: 'Behdad Esfahbod'; Michelle Perham

Cc: opentype-migration-list at indx.co.uk; OTspec ()

Subject: RE: [mpeg-OTspec] MS Proposal: new feature tag

 

Hi Behdad,

 

Thank you for your feedback. My comments inline.

 

Andrew

 

 

There's simply no reason to not introduce a new lookup type for this.

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

 

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

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

 

There's a lot of similarity / overlap between this and JSTF and MATH tables.

Moreover, there's an architectural mismatch between this feature and

GSUB/GPOS: with the proposed feature, some glyph substitution has to happen

*after* GPOS is done.

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

 

 

For these reasons, I like to suggest that:

 

  * No existing lookup to be used for this (for simple compatibility reasons), [Andrew Glass] What compatibility issues do you anticipate?

 

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

 

  * New structures be developed to address this, either in GSUB, or possibly in JSTF.

[Andrew Glass] Having new structures will likely lead to compatibility issues.

 



Sent from Windows Mail
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20130117/d18d9402/attachment.html>


More information about the mpeg-otspec mailing list