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

I'm not sure if I understand what your root concern is. If your concern is
how Unicode defines Tr value, please send your feedback to Unicode. The
PRI was over, but you can report your concerns to the reporting form[1]
anytime. I'm happy to be a liaison for UTC here, but it's not appropriate
to discuss whether a value definition in Unicode is right or not in
www-style.

If your concern is about implementations, in not-so-far future, it's quite
possible that operating systems and underlying rendering engines support
UTR#50 natively, including the behavior of Tr. When that happens, without
the sentence, UAs must tweak a few code points to behave differently if
they want to be compliant with CSS. This effort makes things more complex,
and makes no sense.

I understand it's not easy to implement without changing harfbuzz today if
you're relying on harfbuzz. I'm very happy to allow such UA to be
compliant with CSS too.

If we like simplicity and want to allow implementers to use either
architecture, we need both sentences. Isn't this the most appropriate and
the simplest way to go?

[1] http://www.unicode.org/reporting.html

/koji

On 9/24/13 1:57 PM, "John Daggett" <jdaggett@mozilla.com> wrote:

Koji Ishii wrote:

> First of all, the inconsistency you mentioned is, as you also
> mentioned, very subtle. They are hardly, or oftentimes not at all,
> noticeable.

Um, if the behavior only affects one or two codepoints for most fonts
in actual usage, then allowing variations in implementations doesn't
make sense from a spec perspective.

Character properties are the domain of Unicode.  In this context, the
'Tr' value of the "Vertical Orientation" character property is fine,
since it describes a visual distinction that can be made between 'Tu'
and 'Tr' codepoints.  In the 'Tu' case, a different alternate design
is required, in the 'Tr' case a simple rotation will suffice.  But how
text layout is done with actual fonts on the web is really the domain
of CSS, not of Unicode.

In the case of text orientation, CSS should be defining consistent,
normative behavior for text display, the display of 'Tu' and 'Tr'
codepoints should be consistent and not vary across user agents. For
the very small number of 'Tr' codepoints that lack vertical alternates
in fonts, it doesn't make sense to have optional behavior since for a
given piece of content only one behavior will be considered "correct"
by an author.  Optional behavior makes sense in areas like
justification or hyphenation where user agents can improve on baseline
behavior that is already "correct". That's simply not the case for
text orientation.

> 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.

But the main problem is that you're introducing unnecessary complexity
with a performance impact that only aids in rendering a *very* small
number of characters.  For these cases it's just simpler if authors
explicitly declare the text orientation by setting 'text-orientation'
appropriately.  Authors are going to need to do this already to deal
with codepoints for which the UTR50 classification differs from their
content (e.g. the copyright sign within rotated Latin text runs, since
the copyright sign is classified as 'U', upright).

> I also heard from one shaping engine implementer wishing to
> implement Tr as UTR#50 defines. If underlying engine follows the
> UTR#50 definition, it'd be even more troublesome to ignore UTR#50
> and follow CSS.

I'm various curious to understand *why* an implementer would feel this
way, I think you need to explain the "why" of this case.  If fonts
generally support vertical alternates for nearly all the 'Tr'
codepoints, why is it necessary to add conditional logic to handle the
handful of codepoints that lack these alternates?  In the context of
the web platform where support of advanced font technologies is
standard and fonts contain vertical alternates accessed via features,
it doesn't seem to make much sense.

> Lastly, we didn't have this text in old versions of our spec, but
> some members of UTC raised a concern on this specific part and this
> text was added in response to that.

I understand the concern but I think that needs to be tempered by
actual real-world usage.  Given that OpenType support of vertical
alternates is standard behavior in modern CJK fonts, I don't think
explicit fallback is required.

I should also add here that I think eventually we'll need a rule that
allows authors to override the default orientation.  This will allow
authors to define explicit defaults for characters based on the existing
expectations within their content:

  @vertical-text-orientation {
    /* modifications to UTR50 defaults */
    upright: u+20:24f;            /* Latin upright by default */
    upright: u+370:3FF;           /* Greek upright by default
    rotated: u+3030;              /* always rotate the wavy dash */
  }

This allows, for example, existing JIS-based workflows to smoothly
integrate with CSS without the need to use markup to explicitly set
text-orientation depending upon content.  This isn't something for
this level obviously but I think this is a better, long-term solution
to dealing with orientation problems.

Regards,

John Daggett

Received on Wednesday, 25 September 2013 04:08:42 UTC