W3C home > Mailing lists > Public > www-style@w3.org > January 2012

[css3-writing-modes] comments on text-orientation

From: John Daggett <jdaggett@mozilla.com>
Date: Sun, 15 Jan 2012 22:51:50 -0800 (PST)
To: www-style <www-style@w3.org>
Message-ID: <46acc45f-8563-45e0-8359-2ff1554ab270@zimbra1.shared.sjc1.mozilla.com>
In general, the current editor's draft looks like it's much cleaner
and I appreciate the work that Elika and Koji have put into this.

However, looking over the current definition of 'text-orientation'
property values in section 5.1 and Appendix B & C, they are still
defined somewhat imprecisely. The current spec trys to define
orientation behavior in terms of vertical vs. horizontal scripts
(listed in Appendix B) and then points at Appendix C for the
definition of codepoints in common, inherited and unknown script
categories.  But some "vertical" scripts include codepoints that have
a default sideways orientation based on UTR50 (e.g. halfwidth
katakana), so this doesn't quite work.

I think it would be much simpler to define behavior in terms of the
underlying East Asian Orientation value for a given codepoint.  I
think it's also important to point out when features for vertical
alternates are enabled and when they aren't:

upright-right:

  Characters with intrinsic upright orientation (U, T) are drawn
  upright and the 'vert' feature is applied if the font is an OpenType
  font.  Characters with sideways orientation (S, SB) are rotated and
  the 'vert' feature is *not* applied.

upright:

  All characters are drawn upright and the 'vert' feature is applied.

sideways-right:

  All characters are drawn sideways right and the 'vert' feature is
  *not* applied.

sideways, sideways-left:

  Same pattern as sideways-right.

For 'upright' the spec currently states "Shaping characters from such
scripts are shaped in their isolated forms." This means that 'upright'
applied to Arabic in vertical text would break the shaping.  I'm
really not sure that this is the right behavior, I think this behavior
is why Microsoft was talking about making an alternate proposal for
UTR50.  I'd like this explicitly marked as an issue until the WG
explicitly resolves on what the correct behavior should be.

Appendix B is basically defining the same thing as the East Asian
Orientation property.  I don't think we should publish a CSS spec that
defines what are effectively overrides on a Unicode spec, I think we
should instead fight to make sure that the codepoints for scripts
defined as vertical in Appendix B are defined that way in Unicode. 
Unicode is a much better forum than the CSS group to resolve
Unicode character property issues.

Editorial notes:

Issue 4 is listed as "This section and UTR 50 need careful review.
Please send feedback and suggestions for improvement, particularly for
the U+2016–U+205F range."

That's not really a statement of an issue.  I think this should instead read:

  The exact determination of which codepoints are placed in which
  orientation category affects how text is rendered by default,
  particularly codepoints in punctuation and symbol ranges such as
  U+2016-205F.  This requires careful review and feedback is requested.

Issue 6 is contained within a note, I think it should be separate
since notes are informative by definition.

The text in Appendix C contains this note:

> For more subtle differences in glyph shape, such as variant brush
> strokes and alignment, it is suggested that OpenType define a glyph
> substitution feature for characters in the S classes, to be turned
> on when they are typeset (sideways) in vertical text. 

This is advocating a specific action so I really don't think it belongs in 
a spec.  This belongs on a mailing list as a proposed action on behalf
of the working group.  Given that the two primary developers of OpenType
belong to the group I think this would be simple to get traction on if it
makes sense.

  Issue: propose 'svrt' as an OpenType substitution feature applied to
  rotated horizontal text in vertical text runs.
Received on Monday, 16 January 2012 06:52:42 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:48 GMT