W3C home > Mailing lists > Public > www-style@w3.org > October 2013

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

From: John Daggett <jdaggett@mozilla.com>
Date: Mon, 30 Sep 2013 19:09:25 -0700 (PDT)
To: Koji Ishii <kojiishi@gluesoft.co.jp>
Cc: Sylvain Galineau <galineau@adobe.com>, W3C Style <www-style@w3.org>
Message-ID: <934553932.1132019.1380593365241.JavaMail.zimbra@mozilla.com>

Koji Ishii wrote:

> > Given the explicit lack of agreement that Unicode compliance is an
> > issue I do not quite see how this could *possibly* be the point of
> > discussion???
> > 
> > Or is 'Unicode compliance' the last-ditch argument to force your
> > preferred solution in the absence of any actual implementor
> > feedback?
> Who asked for it, and whether a spec is Unicode compliant or not,
> are two different issues. Regardless of who asked for it, if we
> remove the option, CSS will be incompliant.
> I think John is in agreement on this point; he's not agreeing with
> the importance of Unicode compliance because it's informative, and
> the definition is not good, if I understand correctly. It's first
> time in this discussion that someone is not agree on that point.
> What makes you think that way?

I'm completely baffled how you can make this statement.  In my
opinion, there is *no* compliance issue here.  UTR50 defines an
informative property and states *very* clearly that higher-level
protocols define actual usage.

In private communication with other members of the UTC, I don't think
that the UTC meant to impose on users of UTR50 that they exercise the
fallback of Tr. Reading over UTR50, I certainly don't see any such
normative requirement.  This sort of fallback is *possible* for Tr
codepoints but saying that it's normatively required by UTR50 is at
odds with the actual wording in UTR50.

The common practice used by fonts and layout engines supporting
vertical text layout has been to support the proper display of Tu and
Tr codepoints via the use of vertical alternates.  If we're going to
normatively require what is effectively OpenType feature fallback for
only Tr codepoints, we definitely need to justify that in terms of
actual use cases that it solves.  It seems far better to treat the
lack of vertical alternates for Tu and Tr codepoints as a font bug
rather than burden layout engines with complex fallback schemes.

Unless there's stronger justification for the optional fallback scheme
you've described, I think we should resolve to omit it entirely.
Omitting fallback in no way affects any form of compliance with

Current spec:

# For Tr characters, which are intended to be either transformed or
# rotated sideways, the UA may assume that appropriate glyphs for
# upright typesetting are given in the font and render them upright;
# alternately it may check for such glyphs first, and fall back to
# typesetting them sideways if the appropriate glyphs are missing. 

Revised wording:

# For Tr characters, the user agent should assume that appropriate
# glyphs for upright typesetting are given in the font and render them
# upright.


John Daggett
Received on Tuesday, 1 October 2013 02:09:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:51:02 UTC