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

Steve, thank you for the response.

You described exactly the problem we're facing today. Some EPUB guys are embedding fonts just for U+2014 and U+2015, but that's not an option for Web today.

While U+2014 or U+2015 is a big issue, I'd like it be a separate issue from CSS. I think the root of the problem is that there were no EM DASH in East Asia; they use TWO-EM DASHES instead. But such code point were not assigned, so people tried not to break between the consecutive two EM DASHes to simulate TWO-EM DASHES. As far as I understand, there's a proposal to add TWO-EM DASHES to Unicode and I'm hoping it finally solves this issue.

Our problem is how to reliably display these glyphs as vertical bars in vertical flow.

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

Yeah. But I don't think every common users do this, so this could be a workaround for professional users, but I don't think this is a solution.

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

Hm. Isn't this contradicting the other? It's true that fonts created this problem, so the "environmental query" should be done against fonts, not to operating system. We don't know which type of fonts, for instance, Android bundles. Every Android has different fonts and different input systems.

Type 2 of font-dependent-orientation (vertical alternate glyph or sideways) is a proposal to query the font. I hope you understand now that it queries fonts to make consistent visuals, not to break.


Regards,
Koji

-----Original Message-----
From: Stephen Zilles [mailto:szilles@adobe.com] 
Sent: Thursday, September 29, 2011 7:51 AM
To: Koji Ishii; www-style@w3.org
Cc: Taro Yamamoto
Subject: 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 Thursday, 29 September 2011 06:59:06 UTC