[HarfBuzz] default features for vertical text runs

[John Daggett]

The code in hb-ot-shape.cc defines default features, distinguishing
between defaults for horizontal and vertical text runs:

  static hb_tag_t common_features[] = {
    HB_TAG('c','c','m','p'),
    HB_TAG('l','i','g','a'),
    HB_TAG('l','o','c','l'),
    HB_TAG('m','a','r','k'),
    HB_TAG('m','k','m','k'),
    HB_TAG('r','l','i','g'),
  };
  
  
  static hb_tag_t horizontal_features[] = {
    HB_TAG('c','a','l','t'),
    HB_TAG('c','l','i','g'),
    HB_TAG('c','u','r','s'),
    HB_TAG('k','e','r','n'),
    HB_TAG('r','c','l','t'),
  };
  
  /* Note:
   * Technically speaking, vrt2 and vert are mutually exclusive.
   * According to the spec, valt and vpal are also mutually exclusive.
   * But we apply them all for now.
   */
  static hb_tag_t vertical_features[] = {
    HB_TAG('v','a','l','t'),
    HB_TAG('v','e','r','t'),
    HB_TAG('v','k','r','n'),
    HB_TAG('v','p','a','l'),
    HB_TAG('v','r','t','2'),
  };
  
OpenType actually has two mutually exclusive vertical text layout
models, one based on 'vert', the other based on 'vrt2'.  There's never
a situation where both should be enabled.

Within vertical text runs, by default Chinese characters and kana are
placed upright while subspans of Latin text are laid out horizontally
and rotated into place within the vertical run.  One way to achieve
this is to separate the run into vertical and horizontal runs and
shape the subspans with the 'vert' feature on to enable vertical
alternates (e.g. the comma mark in Japanese [、] changes to a version
with the comma in the upper-right corner of the em-box).

The 'vrt2' model embeds rotated Latin glyphs within the font which
obviates the need for the layout engine to slice up the text run.  A
layout engine simply enables 'vrt2' and glyphs are automatically
placed correctly.  Vertical alternates are also enabled via the 'vrt2'
feature, so the set of substitutions applied are effectively a
superset of the 'vert' substitutions.  In some controlled environments
where the fonts and contents are known, the 'vrt2' model can simplify
application logic.  However, it's not commonly used, the more general
model is the one in which the layout engine handles orientation
decisions.  Formalizing the orientation of different codepoints in
Unicode has recently been a discussion within Unicode, leading to the
recent publication of TR50.

I also checked with some of the Adobe engineers who originally
registered the vertical text features in OpenType.  Their opinion was
that 'vkrn', 'vpal' and 'valt' should all be off by default, despite
what's written in the feature descriptions for these features.

So I think the resulting vertical defaults should be reduced to just
'vert', since that's the most common model used for vertical layout:

  static hb_tag_t vertical_features[] = {
    HB_TAG('v','e','r','t'),
  };

Cheers,

John Daggett
Mozilla Japan

diff --git a/src/hb-ot-shape.cc b/src/hb-ot-shape.cc
index 6a0c786..5b35abd 100644
--- a/src/hb-ot-shape.cc
+++ b/src/hb-ot-shape.cc
@@ -59,16 +59,11 @@ static hb_tag_t horizontal_features[] = {
 };
 
 /* Note:
- * Technically speaking, vrt2 and vert are mutually exclusive.
- * According to the spec, valt and vpal are also mutually exclusive.
- * But we apply them all for now.
+ * Use vert by default. Layout engines are responsible for separating
+ * vertical/horizontal runs.
  */
 static hb_tag_t vertical_features[] = {
-  HB_TAG('v','a','l','t'),
   HB_TAG('v','e','r','t'),
-  HB_TAG('v','k','r','n'),
-  HB_TAG('v','p','a','l'),
-  HB_TAG('v','r','t','2'),
 };