[mpeg-OTspec] MS Proposal: new feature tag

[Behdad Esfahbod]

I fully appreciate and support the aim of this proposal.  However, I strongly
oppose abusing an existing mechanism (GSUB Multiple Substitute lookups) to
achieve this.

There's simply no reason to not introduce a new lookup type for this.
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".

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.

For these reasons, I like to suggest that:

  * No existing lookup to be used for this (for simple compatibility reasons),

  * The problem be studied in more depth,

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

Regards,
behdad


On 13-01-03 02:20 PM, Michelle Perham wrote:
>  
> Here is another proposal put together by Andrew Glass of Microsoft. He’d like
> to propose a new feature tag to support the Syriac Abbreviation Mark and other
> marks which stretch to enclose other characters.
> 
>  
> 
> Tag: “stch”
> 
> Friendly name: Stretching Glyph Decomposition
> 
> Registered by: Microsoft
> 
>  
> 
> Function: Unicode characters, such as the Syriac Abbreviation Mark (U+070F),
> that enclose other characters need to be able to stretch in order to
> dynamically adapt to the width of the enclosed text. This feature defines a
> decomposition set consisting of an odd number of glyphs which describe the
> stretching glyph. The odd numbered glyphs in the decomposition are fixed
> reference points which are distributed evenly from the start to the end of the
> enclosed text. The even numbered glyphs may be repeated as necessary to fill
> the space between the fixed glyphs. The first and last glyphs may either be
> simple glyphs with width at the baseline, or mark glyphs. All other
> decomposition glyphs should have width, but must be defined as mark glyphs.
> 
>  
> 
> Example: In Syriac, the character 0x070F is a control character that is
> rendered as a line above an abbreviation in Syriac script. The line should
> have a circle at each end and at the mid point. The decomposition sequence for
> this character should consist of a circle at the start of a line, a connecting
> line, a circle on a line for the mid point, a second connecting line, and a
> circle at the end of the line. The connecting lines will repeat in order to
> fill the space between the circle glyphs.
> 
>  
> 
> Recommended implementation: The stch table maps the character to a set
> containing an odd number of corresponding glyphs (GSUB lookup type 2). The
> rendering engine reorders the last glyph from the substituted set to the end
> of the set of characters being enclosed. The remaining glyphs from the
> substituted set are positioned at the start of the set of characters being
> enclosed. Odd-numbered glyphs in the decomposition set are positioned so that
> they are distributed evenly over the width of the text being enclosed.
> Even-numbered glyphs in the decomposition set are repeated by the rendering
> engine so the width of the space between fixed, odd-numbered glyphs is filled
> by the spacing, even-numbered glyphs.
> 
>  
> 
> Application interface: For GIDs found in the stch coverage table, the
> application passes the sequence of GIDs to the table, and gets back the GIDs
> for the multiple substitution.
> 
>  
> 
> UI suggestion: This feature should be on by default.
> 
> Script/language sensitivity: None.
> 
> Feature interaction: None.
> 
>  
> 
>  
> 
> Please respond with questions of comments. Thanks!
> 
>  
> 
> Michelle
> 
> Microsoft Typography Group
> 
> 

-- 
behdad
http://behdad.org/