RE: [css3-writing-modes] use case for font-dependent default orientation

Thank you for the reply and your help as always, John.

> Here's what I would propose:
> 
> Define an additional category to Eric's propsed Unicode property:
> 
> UL : upright (language-dependent)
> 
> Then define certain codepoints such as the ones in the General
> Punctuation block as upright when the language of an element is
> Japanese (or Chinese, Korean, etc.).  For all other languages these
> would be treated as sideways.  It seems to me we could solve the
> important use cases with something like this without introducing undue
> complexity.
> 
> Right now I think the best approach to moving this along is to look at
> the specific use cases you're trying to solve with your "use font"
> category.  Do fonts have alternates in these ranges?  Do
> implementations treat these as upright or sideways?  Then summarize
> this data and we can try and figure out the best way to come up with
> simple rules to solve these cases.

So, if I understand this correctly, you agree that there are ambiguous code points where we need other information than just code points to determine glyph orientation?

Steve also proposed using language tags to switch behaviors at Seattle. While I understand it can be one of workable solutions, I think it has a few issues:

1. Ambiguous glyph orientation isn't a language dependent behavior; the lang tag should be used for when it's really switching languages.
2. It's about styling, but it'd require authors to change content markups if we go this way.
3. lang tag has too much side-effects because it changes languages. Spell-checkers may get confused (well, no spec-check for punctuation but grammar checker could be), TTS may switch voice, default font can be changed by browsers, underlines rendered in wrong side, etc., so it should be used only when the content is really switch languages.

It looks to me that, if we need more information than code points, relying on fonts is better choice for this purpose.


> > Can I ask which one you're talking about? "Upright if the font has
> > vertical settings" or "Alternate glyph or fallback to sideways", or
> > both?
> 
> The "Alternate glyph or fallback to sideways" rule.

Ok, I have to admit that I went too far. I should summarize issues first, then ask you guys for how to solve. I'll do that.

Let's focus on per-font switch v.s. lang tag for now.


> We should be not be mimicing the behavior of products aimed
> exclusively at Japanese users, we should be looking what is important
> to Japanese users and trying to generalize the solution so that it
> works in a clear and consistent way across locales.

The vertical flow of the two products aim at East Asians, not exclusively at Japanese users, and MS Excel aims at more. There should be something we can learn from.

When you say "across locales", does that include non-East Asian locales? If so, maybe that's one of where we see this issue differently. Please see the following comments.


> > > For example, if a designer uses a vertical writing mode to get
> > > rotated table headings in a non-CJK language they would be confused
> > > as to why their double quotes appeared upright (due to the fact that
> > > the double quote character was pulled from a Japanese font via font
> > > fallback).
> >
> > Non-CJK case should be separated because we have separate values in
> > text-orientation. The "upright-right" should be a good value for East
> > Asian scripts, while "sideways-*" and "upright" should be designed for
> > other scripts as well, and we're discussing on "upright-right" here,
> > right?
> 
> I'm concerned about the default case which is 'upright-right'.  An
> author doing simple vertical table headings shouldn't need to fathom
> some complex set of font-dependent rules that may or may not happen
> depending upon the vaguries of font fallback.

So you want "upright-right" to take care of non-East Asian scripts as well because it is the default value?

I'm already told that the current definition of the spec is a little too far from East Asians' common usage, while you think it's too East Asian centric.

This could be a wild idea, but what do you think about making the default value of text-orientation to "auto", which switches between "upright-right" or "sideways" depending on language? Does that solve your concern while allowing "upright-right" taking care of more needs for East Asians? I feel good to use lang tag this way, as it really indicates content language, and authors can set once at the document level.


> > I do understand font fallback can cause troubles though. I had a
> > discussion with a few folks in Japan about this. Murakami-san raised
> > that, if we go with the current spec, and if a Japanese font is
> > missing U+2030 PER MILLE SIGN for instance, the glyph orientation can
> > change.
> 
> This was precisely my point, the orientation will depend on font
> fallback.
> 
> > The conclusion from our discussion was that it's not an issue for
> > two reasons. One is it's very unlikely that a Japanese font is
> > missing such an important code point for Japanese text. The other
> > is, technically speaking, font vendors can put sideways glyphs into
> > vertical alternate, so UA can control how it renders, but the final
> > visual orientation is really up to the fonts. That said, we have to
> > trust fonts to have somewhat consistent behavior and doing the right
> > thing anyway.
> 
> It *is* a problem because font fallback does not guarantee you hit a
> Japanese font, you could just as easily hit a non-Japanese font with a
> glyph for this character.  The distinction between Japanese vs.
> non-Japanese fonts makes the behavior appear somewhat random to users
> and that's not a good thing.

True, but if UA hits non-East Asian fonts unintentionally, it means the glyph tastes differently and the pitch is broken. The pitch is more important in vertical text flow than in horizontal text flow, so authors consider that the document styling is already broken. It's a matter of whether the document has one issue or two. Clearly one is better than two, I agree that it's nice if we can fix that too, but I'd put more priority on doing better in common cases if the two can't stand together.

As far as I understand, there's no perfect solution to this issue as we came too far from when punctuation were unified and we can't revise that. I agree that it is a problem, but I'm saying that it is less problematic than, say, U+2030 PER MILLE SIGN cannot set upright without additional markups.


> I think the best solution is to align the spec with a property that
> will be defined, revised and maintained by Unicode.  The rule-based
> approach in Appendix C is an interesting attempt but I don't think it
> solves the problem very well and it introduces a lot of complexity.
> Rather than adding more rules to an already complex set of rules that
> are awkward to implement and difficult for authors to fathom, I think
> we should be trying to understand what's important for orienting
> characters in vertical text correctly and use that understanding to
> influence the structure of the proposed Unicode property.
> 
> If defaults really are so variable across locales, then we should define
> an @-rule to allow the defaults to be changed:
> 
> Example:
> 
> @default-orientation {
>   upright: U+2000:206F;
>   sideways: U+2100:21FF;
> }
> 
> But Elika has said repeatedly that this is too much work for the first
> version of this spec.

I agree with you both; such an @-rule is necessary, but it's a bit too advanced for version 1 of vertical flow, and it must take additional months at least to make a stable spec for such feature. Most I talked in Japan agreed with me, making progress faster has the priority than @-rule customizations. But their assumption is that there's one good default value good for common usage. Currently, as we're discussing, the positioning of the "upright-right" looks like a little fragile to me. If the value can't be a good value for East Asians vertical flow, I'm in trouble.


> > One thing to add; I talked with a guy in Toppan Printing Co., Ltd.,
> > one of the biggest printing company in Japan. He told me that they
> > have a table of "default glyph orientation" to apply when author did
> > not specify. I asked him to provide it to us, so we might be able to
> > get it soon.
> 
> This is exactly what we should be doing, trying to understand existing
> usage patterns and use these to discern workable solutions.

Thanks. I'll ask him to get it as early as possible.


Regards,
Koji

Received on Tuesday, 13 September 2011 17:03:34 UTC