RE: [css3-writing-modes] The original issues of font-dependent glyph orientation

I talked with Taro Yamamoto today and we found an interesting case for 2nd issue.

EM DASH has been a long issue for East Asians. Unicode defines two visually similar glyphs: U+2014 EM DASH and U+2015 HORIZONTAL BAR. I don't know how it was determined but EM DASH in Japanese and Korean legacy encodings are mapped to U+2015, not to U+2014. So if users enter EM DASH using Japanese input system on Windows, they get U+2015. MacOS X, on the other hand, decided to use U+2014 for EM DASH, so their input system emits U+2014.

If you look at font tables[1], they match to their input systems; MS Gothic, Meiryo, and Kozuka Gothic on Windows has vert feature for U+2015 but not for U+2014, while Hiragino on Mac has vert feature for U+2014 but not for U+2015.

So, if we set U for these code points, Windows and Mac users do not see consistent visual glyph orientations for these code points. If we set S, vertical alternate glyphs will not be used. "Vertical alternate or fallback to sideways" can solve this, but it's font-dependent.

What would be the best way to solve this issue?

[1] http://lists.w3.org/Archives/Public/www-archive/2011Aug/att-0017/vert.htm

Regards,
Koji

-----Original Message-----
From: www-style-request@w3.org [mailto:www-style-request@w3.org] On Behalf Of Koji Ishii
Sent: Wednesday, September 28, 2011 4:49 PM
To: www-style@w3.org
Subject: [css3-writing-modes] The original issues of font-dependent glyph orientation

It took a while, but I'm going to explain the original issues fantasia and I wanted to solve by font-dependent glyph orientation. The intention is that, since several people are against using font-dependent glyph orientation, I'd like to explain why we introduced the method, and hope someone to come up with alternate ways to solve the original issues.

There are two types of issues and therefore two types of font-dependent glyph orientation were proposed. I originally thought the two issues are the same, so the current spec covers only one of them and the other is not written out yet.

==========
1. Upright if the font is (or looks like) East Asian, otherwise sideways

This is a proposal to solve unified code points issue in Unicode, explained in another thread[1]. In short, some code points in some blocks are expected to set upright in common sense and existing text data assumes such behavior, but they're distributed across Unicode blocks due to unification process in Unicode.

It's a very long standing issue. I would very appreciate if someone can come up with how to solve this.

Here're ideas I've seen so far (I hope I didn't miss anything):
1. Make all of them upright.
2. Make all of them sideways.
3. Use font information to switch (the current spec) 4. Use lang attribute to switch.
5. Use contextual information to switch.
None of them can perfectly solve this issue. I wonder, there's no perfect solution and it's a matter of trade-offs.


==========
2. Use vertical alternate if exists, otherwise sideways

This method is not in the current spec, but we discussed in this ML a little ago. Fantasai and I started discussing on this to make visual consistency, and I hope everyone agrees with that the visual consistency is one of important features we would like to achieve.

This issue occurs when a font designer wants the glyph to be displayed sideways, but would also like the glyph or its position optimized for vertical flow. Examples are:

U+2014 EM DASH
U+2026 HORIZONTAL ELLIPSIS
U+25xx Box Drawing
U+3008-301F LEFT ANGLE BRACKET-

If they're set U, most East Asian fonts have vertical alternate glyphs for these code points, so users see them in sideways and the layout looks good for East Asians. However, users without East Asian fonts will see them in upright.

If they're set S, the glyph orientation is consistent, but vertical alternate glyphs are not used and therefore the result is not optimal for East Asian users.

As long as I tested, many software doesn't solve this issue at all; they just set U and disregard visual consistency for whom without East Asian fonts. Since "text-orientation: upright-right" is the value for East Asian documents, that's one way to solve this issue if we can agree.

Note that this may not be an issue for UTR#50 as the issue does not come up if you don't think about optimal layout and vertical alternate glyphs, both of which may not be the scope of Unicode, I'm not sure.


[1] http://lists.w3.org/Archives/Public/www-style/2011Sep/0472.html

Regards,
Koji

Received on Wednesday, 28 September 2011 18:22:37 UTC