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

Koji Ishii wrote:

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

No, because metrics and substitution features like 'vert' are
completely separate, independent data items in a font.

The spec you're writing ultimately has to define what a user agent is
implementing.  Imprecise use of terms like "vertical font metrics" and
not describing when vertical alternates are to be used or not used is
a problem for folks working on implementations, it's a problem for
type designers working on fonts intended for use with vertical text
layouts and it's a problem for authors who can't clearly understand
what the intended model is.

The spec doesn't need to *rely* on OpenType but it does need to define
what will happen in terms of how OpenType fonts work, since that's the
99.99999% (+/- 0.000005%) use case in current implementations.

Even if we disagree on the specifics of how this all works, you need
to describe carefully how you propose that this works so that we can
discuss the differences.

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

What you propose for the behavior of text-orientation values
directly affects the authoring model.  In this respect, an author
needs to understand what the expected behavior is, given that an
OpenType font might have vertical alternates or an author might use a
font with only vertical glyphs in it, there needs to be a mode for
text-orientation that really assures that glyphs are shown upright. 
So how the OpenType model works needs to be described in a simple way
that authors can understand.  Specifying this such that each value of
text-orientation has it's own special automagical per-character mapping
is a recipe for author confusion.

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

The issues I've listed are completely orthogonal to whether SB is
treated as sideways or upright by default.

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

The immediate problem with this is that the wording doesn't reflect
your current view of how layout should work.  Define the
wording in terms of the East Asian Orientation property and simply
list clearly where you differ from a specific proposal on the Unicode
side.  Currently, the spec refers to things like Sv and Sh categories
which are not in the UTR50 proposal and you haven't yet proposed them
as feedback in a public forum, either on www-style or in any of the
public forums for feedback on UTR50.

Looking at the wiki page [1], it looks like you have a long laundry
list of issues and customizations for different situations.  I think
if you want to talk about customizations the spec should have a way
of specifying an explicit customization.

Regards,

John Daggett

[1] http://wiki.csswg.org/spec/utr50

Received on Thursday, 19 January 2012 05:11:21 UTC