[mpeg-OTspec] RE: Two proposals: 1) Register a new OpenType feature (vrtr) & 2) Update a registered OpenType feature description (vert)

[Chris Lilley]

Hello Vladimir,

Thursday, October 17, 2013, 8:53:01 PM, you wrote:


> I am in the process of collecting all the OFF updates we discussed
> during the last period. This proposal from Ken Lunde didn’t get any
> responses – should I  treat silence as approval? Please speak up if
> you are *for* or *against* the proposed new feature updates.

Please note that the W3C Cascading Style Sheets (CSS) working group is
very interested in support for Unicode UTR 50 (and contributed to that
specification); also, CSS3 Fonts provides access from stylesheets to
enType features and CSS3 Writing Modes normatively references UTR50.

Thus, W3C requests that this Microsoft/Adobe/W3C proposal be taken up
for discussion.

Of course, if people have technical objections we would want to hear
what those are, rather than assuming either that silence is assent or
dissent. That way, they can be addressed.

> From: mpeg-OTspec at yahoogroups.com
> [mailto:mpeg-OTspec at yahoogroups.com] On Behalf Of Ken Lunde
>  Sent: Friday, August 09, 2013 4:57 PM
>  To: mpeg-OTspec at yahoogroups.com
>  Subject: [mpeg-OTspec] Two proposals: 1) Register a new OpenType
> feature (vrtr) & 2) Update a registered OpenType feature description (vert)
>    
>  
>  
>   
>  
>  
>  
>  
> All,
>  
>  Two proposals are included below, one of which is to register a
> new OpenType feature in order to better support the
> approved-but-not-yet-published UTR #50, and the other is to modify
> the description of a register OpenType feature to comply with
> current practice,  and to better support UTR #50. Here is the latest draft of UTR #50:
>  
>  http://www.unicode.org/reports/tr50/
>  
>  The first proposal is to register a new OpenType feature to be
> tagged 'vrtr', and the full description is below (note that NCRs are
> used to represent non-ASCII characters in the "Example" section):
>  
>  ----------------
>  Tag: 'vrtr'
>  
>  Friendly name: Vertical Alternates For Rotation
>  
>  Registered by: Adobe/Microsoft/W3C
>  
>  Function: Transforms default glyphs into glyphs that are
> appropriate for sideways presentation in vertical writing mode.
> While the glyphs for most characters in East Asian writing systems
> remain upright when set in vertical writing mode, glyphs for other
> characters  -- such as those of other scripts or for particular
> Western-style punctuation -- are expected to be presented sideways in vertical writing.
>  
>  Example: As a first example, the glyphs for FULLWIDTH LESS-THAN
> SIGN (U+FF1C; "＜") and FULLWIDTH GREATER-THAN SIGN (U+FF1E; "＞") in
> a font with a non-square em-box are  transformed into glyphs whose
> aspect ratio differs from the default glyphs, which are properly
> sized for sideways presentation in vertical writing mode. As a
> second example, the glyph for LEFT SQUARE BRACKET (U+005B, "[") in a
> brush-script font that exhibits  slightly rising horizontal strokes
> may use an obtuse angle for its upper-left corner when in horizontal
> writing mode, but an alternate glyph with an acute angle for that
> corner is supplied for vertical writing mode.
>  
>  Recommended implementation: The font includes versions of the
> glyphs covered by this feature that, when rotated 90 degrees
> clockwise by the layout engine for sideways presentation in vertical
> writing, differ in some visual way from rotated versions of the
> default  glyphs, such as by shifting or shape. The vrtr feature maps
> the default glyphs to the corresponding to-be-rotated glyphs (GSUB lookup type 1).
>  
>  Application interface: For GIDs found in the vrtr coverage table,
> the layout engine passes GIDs to the feature, then gets back new GIDs.
>  
>  UI suggestion: This feature should be active by default for
> sideways runs in vertical writing mode.
>  
>  Script/language sensitivity: Applies to any script when set in vertical writing mode.
>  
>  Feature interaction: The vrtr and vert features are intended to be
> used in conjunction: vrtr for glyphs intended to be presented
> sideways in vertical writing, and vert for glyphs to be presented
> upright. Since they must never be activated simultaneously for  a
> given glyph, there should be no interaction between the two
> features. These features are intended for layout engines that
> graphically rotate glyphs for sideways runs in vertical writing
> mode, such as those conforming to UTR#50. (Layout engines that
> instead  depend on the font to supply pre-rotated glyphs for all
> sideways glyphs should use the vrt2 feature in lieu of vrtr and
> vert.) Because vrt2 supplies pre-rotated glyphs, the vrtr feature
> should never be used with vrt2, but may be used in addition to any other  feature.
>  ----------------
>  
>  The second proposal is to modify the description of a registered
> OpenType feature, specifically the one tagged 'vert'. Please compare
> the modified description with the current description:
>  
>  http://www.microsoft.com/typography/otspec/features_uz.htm#vert
>  
>  Here is the modified description (note that NCRs are used to
> represent non-ASCII characters in the "Example" section):
>  
>  ----------------
>  Tag: 'vert'
>  
>  Friendly name: Vertical Alternates
>  
>  Registered by: Adobe/Microsoft
>  
>  Function: Transforms default glyphs into glyphs that are
> appropriate for upright presentation in vertical writing mode. While
> the glyphs for most characters in East Asian writing systems remain
> upright when set in vertical writing mode, some must be transformed 
> -- usually by rotation, shifting, or different component ordering --
> for upright presentation in vertical writing mode.
>  
>  Example: As a first example, the glyph for HIRAGANA LETTER SMALL A
> (U+3041; "ぁ") is transformed into a glyph that is shifted up and to
> the right, which is properly positioned for upright presentation in
> vertical  writing mode. As a second example, the glyph for SQUARE
> MAIKURO (U+3343; "㍃"), whose component katakana characters are
> ordered from left to right then top to bottom (like horizontal
> writing mode), is transformed  into a glyph whose component katakana
> characters are ordered from top to bottom then right to left (like vertical writing mode).
>  
>  Recommended implementation: The font includes versions of the
> glyphs covered by this feature that differ in some visual way from
> the default glyphs, such as by rotation, shifting, or different
> component ordering. The vert feature maps the default glyphs to  the
> corresponding vertical glyphs (GSUB lookup type 1).
>  
>  Application interface: For GIDs found in the vert coverage table,
> the layout engine passes GIDs to the feature, then gets back new GIDs.
>  
>  UI suggestion: This feature should be active by default in vertical writing mode.
>  
>  Script/language sensitivity: Applies only to scripts with vertical writing capability.
>  
>  Feature interaction: The vert and vrtr features are intended to be
> used in conjunction: vert for glyphs to be presented upright, and
> vrtr for glyphs intended to be presented sideways in vertical
> writing. Since they must never be activated simultaneously for  a
> given glyph, there should be no interaction between the two
> features. These features are intended for layout engines that
> graphically rotate glyphs for sideways runs in vertical writing
> mode, such as those conforming to UTR#50. (Layout engines that
> instead  depend on the font to supply pre-rotated glyphs for all
> sideways glyphs should use the vrt2 feature in lieu of vert and
> vrtr.) Because vrt2 supplies pre-rotated glyphs, the vert feature
> should never be used with vrt2, but may be used in addition to any other  feature.
>  ----------------
>  
>  Regards...
>  
>  -- Ken
>   
>  
>           
>    
>      
>   


-- 
Best regards,
 Chris  Lilley
Technical Director, W3C Interaction Domain