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

Koji Ishii wrote:

> > What you seem to be describing (please correct me if I'm wrong) is:
> >
> >   For codepoints categorized as "use font", if a vertical
> >   alternate exists in the font used for a given character, set the
> >   character upright and use the vertical alternate, otherwise the
> >   character as having a sideways orientation and render rotated.
> >
> > Is that closer to what you and fantasai are thinking/proposing?
> 
> Yes, and this is 4th category I'm thinking to add to solve a problem
> in the current spec, in addition to the current "upright",
> "sideways", and "use-font" categories. Fantasai told me that if we
> can merge this with "use-font", and I was thinking its possibility,
> but you pointed out that PER MILLE cannot be this definition and
> you're right, so I guess we need 4 categories.
> 
> U+2030 PER MILLE should be "use-font" as it is currently spec'ed;
> upright if the font is East-Asian and the decision is per-font, and
> that's what Word/InDesign does today, right? Dashes and parenthesis
> should be "use vertical alternate if exists, otherwise sideways".

Koji, I don't think we should be adding more font-dependent steps, we
should be removing them and instead we should be agreeing on a way of
dealing with orientation that is simple and doesn't rely on font data.
>From the algorithm you wrote in Appendix C, from what Murakami-san has
described as the AH Formatter algorithm and from how existing
implementations effectively define default orientation, it's clear
there are certain ranges (e.g. General Punctutation) for which some
characters are treated as upright in CJK text but sideways in non-CJK
text.  We should focus on the commonly used characters in these ranges
and work coming up with a simple solution for these.

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.

> > Normally, a run of vertical text would be separated into upright
> > runs and rotated runs, broken down into scripts, matched with
> > fonts, and the characters laid out by (1) looking up the default
> > glyphs in the character map (cmap) and (2) running through the
> > features in the font to do both glyph substitution and positioning.
> >
> > Your special case would effectively be at the *end* of the
> > substitution phase, in other words you'd have to trace back and
> > figure out whether a 'vert' substitution occurred in addition to
> > other substitutions for a given character. Simply dumping out
> > glyph substitutions for the 'vert' feature and backmapping that to
> > the underlying character would not be correct.  For these "use
> > font" codepoints you'd need to double check whether a new sideways
> > or upright run needed to be added. Not impossible, just
> > complicated and something that we should take pains to avoid
> > unless absolutely necessary.
> 
> 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.

> I'm not very familiar with browser rendering code, and I understand
> that font fallback makes browsers somewhat different from regular
> word processors. You explained to me that browsers splits text into
> runs, and try to match with fonts. I'm guessing--I'm sorry if I were
> wrong here but--during the matching with fonts phase, since some
> code points can fallback to different fonts, the run can be split
> further at the phase, right? Couldn't glyph orientation determined
> at that point?

The point I was making is that it adds a lot of complexity to add
font-dependent rules like this and it doesn't appear to really solve
the problem you appear to be trying to solve, mainly because font
support for vertical alternates varies and isn't easily inferred from
things like the existence of vertical metrics in the font.

> "How much it is necessary" is a difficult question. The former is
> required to solve unified punctuation issue in the similar way as
> Word/InDesign has solved (unless we can come up with other idea to
> solve the issue.) If CSS Text Level 3 can't solve the issue, I guess
> people might say it's still better than nothing. It was normal
> behavior of word processors in early '90s.
> 
> But I believe today's expectation is at the similar level as what
> Word 6.0 or later and InDesign provides. If you can agree with that,
> we need a solution for unified punctuation code points and PUA.

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.

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

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

> > I think if we can figure out a way to define orientation that is
> > not font dependent as it is in the current spec, then we'll be
> > very close to having a proposal that's good enough for a first
> > version of this spec.
> 
> It's true that the current spec has some issues and we need to
> revise that. But at least the current spec proposes one solution to
> the unified punctuation and PUA issues. I would like to hear, if
> we're going to go with orientation without font dependency, how it
> can solve the issue. Well, or to conclude "CSS not being able to
> solve the issue" is also an option, but I'd like to hear what you
> would say about this.

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.

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

Regards,

John

Received on Tuesday, 13 September 2011 02:49:40 UTC