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

For the text-orientation part, if I understand correctly, the differences between yours and current spec are:
1. Whether to say "'vert' feature" or "vertical font metrics".
2. Whether to put that in section 5.1 or in Appendix.
3. How to render SB characters.
Is this correct understanding?

Regarding item 1, I prefer not relying on OpenType table name here but it's not strong. Does "vertical font metrics such as 'vert' feature in OpenType" helps to solve your concern?

Regarding item 2, I'm okay to put either way, but putting everything in 5.1 makes it very long. Your sentences are not so long, but I think we need to have two perspectives in the spec; one for UA developers and another for authors. This is especially important for some glyphs where UA renders upright and font system rotates them to sideways, so such code points are upright for UA developers and sideways for authors.

Due to such differences, maybe it's better to split this into two separate sections, one for UA developers and another for authors, since audiences are unlikely to overlap?

Probably the item 3 is where John and fantasai/I think differently. This requires a long discussion and so I'm postponing for now.

> 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'll ask this to i18n WG.

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

I agree we should try our best, and I think we're doing as you said. But right now, UTR#50 is very slow to incorporate our feedbacks, so I think it's fine to suspend removal of our definitions at least until it's done.


Regards,
Koji

-----Original Message-----
From: John Daggett [mailto:jdaggett@mozilla.com] 
Sent: Monday, January 16, 2012 3:52 PM
To: www-style
Subject: [css3-writing-modes] comments on text-orientation

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 Tuesday, 17 January 2012 03:48:58 UTC