Re: [css3-writing-modes] inconsistent handling of 'Tr' codepoints in 'text-orientation'

> On Sep 24, 2013, at 1:58 PM, John Daggett <jdaggett@mozilla.com> wrote:
>
> Koji Ishii wrote:
>
>> Second about implementations, it depends on what you use for the
>> underlying engine. I understand that harfbuzz as of today does not
>> have such mechanism and both you and Nat are right on that point,
>> but developers in Japan say it's not that hard to add such feature
>> if desired.
>
> OpenType layout is done with a *set* of features, not simply single,
> individual features.  Yes, I've seen the "easy" implementation code
> which is map character to default glyph, then dig through the lookups
> to see whether 'vert' implements a mapping for that glyph.  But
> that ignores the possible interactions of other features, so it's
> only half-right.

The Microsoft specs for various Indic scripts require the shaping
engine to determine whether various characters are affected by
particular features in a particular font.  See the dynamic character
properties section of [1]. It does not require digging through the
lookups; rather it simply applies the 'locl' feature together with the
particular feature to each of the relevant characters in isolation.
Although the model in OpenType standard is that all features are
applied together, most of the script-specific OpenType specs require
that most features are applied separately in a particular order (and
this is what both Uniscribe and HarfBuzz do).

So I would suggest that the spec should say that a UA must determine
whether an OpenType font provides an appropriate rotated glyph for a
Tr character by testing whether applying the 'locl' and 'vert' GSUB
features together to a glyph string consisting of the single glyph id
to which the character is mapped results in a change to the glyph
string.  This would ensure all OpenType-based implementatons behave
consistently with each other and with UTR#50. I can't see this having
a performance impact: there are relatively few Tr characters and you
can do this test up-front, once per font.

The only case that this doesn't handle if the 'vert' feature provides
an alternative glyph for a U, Tu or Tr character but it is of a
different orientation than what UTR#50 requires.  I don't see anyway
around this, but hopefully it's not a problem in practice.  However,
going forward, it might be worth registering a new OpenType feature,
e.g. 'vt50', like 'vert' but with the additional semantics of being
UTR#50 compliant. (A font implementing 'vt50' would map both 'vert'
and 'vt50' to the same list of lookups.)  A UA would be required to
assume that the 'vt50' feature provided glyphs with UTR#50 compliant
orientation for all glyphs in categories U, Tu and Tr.

James

[1] http://www.microsoft.com/typography/otfntdev/devanot/shaping.aspx

Received on Thursday, 26 September 2013 05:15:12 UTC