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

Koji,
  I am a bit confused by your description below as it applies to the Web. On the Web, content may be prepared on a Windows machine, on a Unix machine or on a Mac. Similarly, it may be viewed (when on a webpage) on any of those machines. Therefore, I do not understand the significance of the input method part of your discussion. Secondly, you seem to be assuming that Mac's will only have Mac fonts and Windows machines only Windows fonts. But, font downloading would allow the author to specify the font he wanted to use (which could match the character he chose). That is, font downloading would make the problem go away.

But, how to solve the problem if font downloading is not possible? 

One way would be to not pursue any further solution to the problem and hope that font downloading will be common enough that the edge cases that are left will be rare.

Another way would be to define tow "text-transform"s that maps the two characters to a single character, U+2015 in one case and U+2014 in the other case. Then, have a environmental query (on operating system) to determine which text-transform to use in your stylesheet.

Since fonts have created this problems (and several others), I do not think that trying to solve the problem using fonts is either good or reliable.

Also, it is really the case that all the participants (MacOSs, WindowsOSs, Unix and the various authors in the East Asian countries) agree that there should be no distinction between the two characters as used in East Asia?  The fact that they look different (which is part of the problem) makes me wonder if they really are "interchangeable".

Steve Zilles


> -----Original Message-----
> From: www-style-request@w3.org [mailto:www-style-request@w3.org] On Behalf
> Of Koji Ishii
> Sent: Wednesday, September 28, 2011 11:23 AM
> To: www-style@w3.org
> Cc: Taro Yamamoto
> Subject: 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 22:52:13 UTC