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

On 01/15/2012 10:51 PM, John Daggett wrote:
> 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've done this, insofar as possible given the current state of UTR50. :/
   http://dev.w3.org/csswg/css3-writing-modes/#text-orientation

As Koji notes, we feel it's important that an author can read the
definitions and have an idea of what they do. So I've kept some
text that summarizes what's going on; however the normative definition
points to UTR50 as its implementation.

> I think it's also important to point out when features for vertical
> alternates are enabled and when they aren't:

I've pulled this out of the value definitions and defined it in its
own subsection:
   http://dev.w3.org/csswg/css3-writing-modes/#vertical-font-features

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

I've reworded this bit so that whether the text is rotated or upright
is deferred to UTR50. Let me know if this is enough, or if you still
want this called out as an issue.

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

Ok, we've removed the orientation-related bits of Appendix B.
It still lists the vertical scripts, because that's needed for
text-combine.

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

Done. Also added a link to the PRI207 forum.

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

I don't know that issues are exactly normative either, but ok.

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

Ok, updated.

~fantasai

Received on Saturday, 21 April 2012 06:26:28 UTC