W3C home > Mailing lists > Public > www-style@w3.org > September 2014

Re: [css-ruby] ruby-position: inter-character

From: Yijun Chen <ethantw@me.com>
Date: Sat, 20 Sep 2014 17:59:47 +0800
Cc: Richard Ishida <ishida@w3.org>, Koji Ishii <kojiishi@gluesoft.co.jp>, David Hyatt <hyatt@apple.com>, www-style list <www-style@w3.org>, Xiaoqian Wu <xiaoqian@w3.org>, "font@but.tw" <font@but.tw>
Message-id: <276401EF-6AA4-478E-975C-4D1450B4571F@me.com>
To: Bobby Tung <bobbytung@wanderer.tw>

I think it’s the best if the OpenType fonts are able to adjust the tones themselves for the accurate and perfect positioning. But since none of them so far supports this advanced feature, maybe it could *fallback* onto the browser to decide the positioning. 

There are *only* three situations for Zhuyin tone positioning, listed below:

- Neutral tone (輕聲) positioned on top of the symbols.
- Checked tones (入聲, for Chinese dialects) positioned on the right-below side of the final (韻母).
- Other tones positioned on the right-top side of the final. 

It is not difficult for browsers to identify those tone symbols. If we nest the tones, it would be too much trouble for editors and the DOM structure would be in-semantic as well. I suggest that Zhuyin remain mono. 

The ruby for Zhuyin polyfill I authored[1] requests the tones to remain un-nested and leaves the *uglifying-job* for JavaScript so that we have DOM strong-enough for CSS to style. Hope it can be an example for Dave's implementation. :) 

[1]: http://css.hanzi.co/demo/ruby.html <http://css.hanzi.co/demo/ruby.html>

Chen Yijun (@ethantw)

> Bobby Tung <bobbytung@wanderer.tw <mailto:bobbytung@wanderer.tw>> 於 2014年9月20日 01:48 寫道:
> Richard Ishida <ishida@w3.org <mailto:ishida@w3.org>> 於 2014年9月20日 上午12:28 寫道:
>> I guess two things worry me about the nested approach:
>> [1] it's quite a long of markup - must be a pain for authors
>> [2] it's not clear to me how the tone mark would end up in the right place, since it's not supposed to be centred, nor is it supposed to be aligned to the edge of the box according to http://www.edu.tw/files/site_content/M0001/juyin/jb99.htm?open.aul <http://www.edu.tw/files/site_content/M0001/juyin/jb99.htm?open.aul>
>> If it's achievable using things like CSS margins/padding, it again must be a little complicated for authors to get it right.
>> I'm inclined to think that all this should be really simple for the content author. They should just say 'make this work like bopomofo ruby' and use a minimum of markup and CSS.
> Yes, Yunji noticed me about semantic issue with nested ruby. I'm a little hash to want everything done with padding/margin adjust.
> In last year workshop in Keio University, I also talked about tool to add bopomofo ruby to characters. I'd like to send proposal to Moedict team ask for help. Before that, I have to figure out how to mark it up. Maybe simple as mono-ruby is the best way.  
>> I see your point about inline bopomofo also positioning tone marks in a way that looks a little like ruby, but I suspect we have the same issue in terms of positioning the tone mark correctly(?). (In fact, it may be more of an issue because the glyphs are bigger.)
>> I also can't help feeling that it's not actually ruby, and so we ought not to use ruby markup for it.
> It is a Chinese poem text-book and very rare. Maybe an image with alt-text will be better for that.
>> There's also one other aspect related to bopomofo ruby that I'm not clear about.
>> The light tone appears at the top of the vertical stack, but there seems to be some debate about where the character U+02D9 should appear in relation to the other zhuyin letters.
>> I believe that nominally you'd expect it to follow the characters in the zhuyin syllable, even though it is displayed before them. (It would be interesting actually, Bobby, if you have any examples of non-ruby bopomofo like the ones you just showed us that use the light tone - so we could see where it's placed - especially horizontal examples.)  I noticed that https://www.moedict.tw/%E5%AD%90 <https://www.moedict.tw/%E5%AD%90> stores the light tone before the zhuyin letters, though I don't know if that's just to simplify things(?).
> That also confused me. But I think the light tone (U+02D9) should be placed before other zhuyin letters. Some reasons for that.
> 1,  MOE's handbook shows Bopomofo in horizontal writing [1], light tone should be put first of all.
> 2,  When you pronounce a character with Bopomofo, light tone should be considered before combine other zhuyin letters. And other tone mark after, so they are put aside.
> The only reason against is all Bopomofo input method used tone mark as last determinant [2], but it's the same when hand writing Bopomofo.
> It's quite hard to find samples in horizontal writing, because in Mandarin education, generally in vertically writing, here's the sample [3].
> <ruby>呀<rt>˙ㄧㄚ</rt></ruby> might more accurate in usage than <ruby>呀<rt>ㄧㄚ˙</rt></ruby> 
>> I suppose it's possible and maybe even probable that content authors would naturally type it before the syllable for ruby even if they typed it after for non-ruby zhuyin. Maybe it's not necessary to be overly purist about it. [1]
>> (One snag may occur, I guess, if you wanted to simply replace the hanzi with the bopomofo, as you may sometimes want to do for kanji+hiragana ruby, for kids/accessibility, etc.  On the other hand, I've heard that where this occurs, the bopomofo tends to still be vertical, even in horizontal text - though i'm not sure that's always the case.)
> Yes, in education context, Bopomofo always in vertical [4].
>> ri
> [1]: http://www.edu.tw/files/site_content/M0001/juyin/images/p222.jpg <http://www.edu.tw/files/site_content/M0001/juyin/images/p222.jpg>
> [2]: https://www.dropbox.com/s/clddiy51bejb5rg/bopomofoime.png?dl=0 <https://www.dropbox.com/s/clddiy51bejb5rg/bopomofoime.png?dl=0>
> [3]: https://www.dropbox.com/s/7c4ea94dwk466fs/bopomofo.jpg?dl=0 <https://www.dropbox.com/s/7c4ea94dwk466fs/bopomofo.jpg?dl=0>
> [4]: http://www.mdnkids.com/BoPoMo/ <http://www.mdnkids.com/BoPoMo/>

Received on Saturday, 20 September 2014 10:01:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:46 UTC