Re: [css3-writing-modes] Summary of Tr in UTR#50 and 'text-orientation' discussions

I would not state John's point 3 as "CSS should prohibit implementation of
Tr as defined in UTR#50".  Rather I would state it as: with a font
subsystem based on OpenType and with a font providing the 'vert' feature,
the best approach is to say that it is up to the the font to implement
UTR#50 correctly and the shaper should not try to work around any
deficiencies in the font.  I think this would be a reasonable position for
CSS to adopt.

The other position that I think it would be reasonable for CSS to adopt is
to require implementations to check whether an OpenType font contains
appropriate glyphs for Tr characters using the algorithm I have proposed or
something similar.

I believe the current spec is unsatisfactory in two ways.

a)  It does not adequately specify how a UA should do this checking: with
the complexities of OpenType -- notably contextual lookups and multiple
features -- it is not at all obvious how to do it.  Leaving this
under-specified will create interoperability problems.

b) Given that my proposed algorithm is not expensive either in terms of
implementation complexity or runtime performance, there is insufficient
justification for making this checking optional.

James

On Sep 28, 2013, at 8:30 PM, Koji Ishii <kojiishi@gluesoft.co.jp> wrote:

Since the discussion is long and complex, I’m making a summary of current
discussions. I try short, accurate, and not-misleading, please point out if
I’m not doing well.



*John* is making 3 different arguments in parallel:

1.     *Tr in UTR#50 has technical issues.* This should go to Unicode, not
www-style.

2.     *Tr impl costs is not worth to its value.* Accepted. CSS now allows
tailoring by re-defining Tr as U. The diff by this change is subtle.

3.     *CSS should prohibit impl of Tr as defined in UTR#50 for consistency
and simplicity.* Disagreed, 1) we should allow any Unicode-compliant impl
as CSS-compliant, 2) we acknowledged the diff is subtle in #2, and 3)
UTR#50 impl is simpler under different architecture.



*Some members of UTC* requested that *CSS should allow any
Unicode-compliant impl as CSS-compliant*.



*Sylvain* said *as a matter of principle we should avoid optional behavior*.



*James Clark* said, for the same reason as John’s #3 and Sylvain, *CSS
should only allow UTR#50-compliant impl and disallow tailoring*.



My preference is to allow both UTR#50 and the tailoring in John’s #2. CSS
already allows a lot of tailoring, such as Turkish uppercasing or UAX#14
grapheme cluster. As a secondary preference, if tailoring is really bad and
that subtle consistency is critical, I’d agree with James.



I18N WG puts this topic on its agenda next week, I hope this clarifies the
whole discussions and each position for I18N WG to discuss, and anyone else
to jump in if s/he wants to.



/koji