W3C home > Mailing lists > Public > www-style@w3.org > January 2015

Re: [css-ruby] Tone mark of bopomofo in ruby

From: Richard Ishida <ishida@w3.org>
Date: Fri, 30 Jan 2015 17:43:23 +0000
Message-ID: <54CBC2BB.8060908@w3.org>
To: Xidorn Quan <quanxunzhen@gmail.com>, Koji Ishii <kojiishi@gmail.com>
CC: Bobby Tung <bobbytung@wanderer.tw>, www-style list <www-style@w3.org>, CJK discussion <public-i18n-cjk@w3.org>
On 29/01/2015 23:30, Xidorn Quan wrote:
> On Fri, Jan 30, 2015 at 4:47 AM, Koji Ishii <kojiishi@gmail.com
> <mailto:kojiishi@gmail.com>> wrote:
>
>     After reading Richard's new blog post[1], especially its Questions
>     section[2], and with some conversation with him, I'm started to be
>     convinced that doing this in inter-character might make more sense.
>     Doing it in fonts still look good if it works, but if Richard's
>     analysis is right about it can't be done with existing features,
>     adding an OpenType feature for Bopomofo might be harder.
>
>
> I'm still not convinced. I don't see any analysis in this article about
> why positioning tone mark cannot be done by font with existing features.
> From the question "Can tone positioning be done using font metrics?", if
> I read correctly, he pointed out three difficulties:
>
> (1) There are too many characters in Chinese font, which makes it hard
> to mark every character with annotation.
> (2) There are fonts with annotation marked, but they are suffered from
> heteronyms.
> (3) Reordering of code points is usually done by layout engine instead
> of fonts.
>
> Please tell me if I missed something important.
>
> The first two points don't make sense to me. We don't hope characters to
> be marked with the whole annotation. We simply hope fonts have special
> values for positioning tone marks to be besides bopomofo. There are only
> less than 40 bopomofo characters, and 4 tone marks. Hence there are no
> more than 160 combinations (even less, because the 20+ consonants won't
> be combined with tone marks, and light tone is not combined besides
> bopomofo, hence actually only about 50). I'm not familiar with OpenType
> features, hence I don't know if it is feasible to handle this with
> features like GPOS (I suspect it is), but it doesn't seem to be harder
> than positioning requirements of scripts like Arabic. In addition, given
> the small number of combinations, I guess it could at least be handled
> with GSUB.

Thanks for this comment. I think you may be right. I had been coming at 
the problem after thinking of the fonts out there that encode the actual 
bopomofo needed for each character within the font. But I think you're 
right that that's not what we need here.

The bopomofo to be associated with a character is spelled out by the 
ruby markup.  I guess all that's needed is a way to render the tone 
marks in relation to the bopomofo characters.

In that case, actually, I suppose it would even be possible, as a stop 
gap, to speed up the process of adoption by creating small fonts that 
just do bopomofo and using font-family to apply those to the ruby 
annotations. Such fonts may be relatively easy to produce and 
distribute, and especially if they are free to use they could therefore 
allow people to start using bopomofo ruby sooner rather than later.

ri

> The last point might be an actual problem. But we may not need to
> consider this problem, because Bobby said that in their discussion, it
> has been agreed to put light tone mark before the bopomofo in content by
> authors. And in most cases, it is not likely for authors to write the
> ruby markup directly themselves. (Isn't typing the <rt> mark between
> characters annoying enough?) They will usually use tools like moedict
> bopomofo generator [1] to generate those markups. Even if we need to
> consider, I suspect it might be easier to implement than positioning
> other tone marks in a separate column.
>
...
> [1] https://www.moedict.tw/lab/ruby/
>
> - Xidorn
Received on Friday, 30 January 2015 17:43:35 UTC

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