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

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

From: Koji Ishii <kojiishi@gmail.com>
Date: Fri, 30 Jan 2015 15:03:04 +0900
Message-ID: <CAN9ydbWrFgfp=94ER-oW1RJm+1R+HT0epRp8Gp-1DoiLKsJP=Q@mail.gmail.com>
To: Xidorn Quan <quanxunzhen@gmail.com>
Cc: Bobby Tung <bobbytung@wanderer.tw>, www-style list <www-style@w3.org>, CJK discussion <public-i18n-cjk@w3.org>
GPOS can probably handle tone marks other than the light tone marks if
my understanding of Bopomofo is correct, but it cannot handle the
light tone marks. That was what I figured out after talking to
Richard, and what changed my opinion on this.

> Bobby said that in their discussion, it has been agreed to put light tone mark before the bopomofo in content by authors.

Oh, I didn't know that. How widely was that agreed? If the light tone
marks is no longer an issue, well, that's a big change in the
requirements. Is IME going to follow the change?

> And in most cases, it is not likely for authors to write the ruby markup directly themselves.

I agree, but re-ordering characters in the source to make the correct
visual looks a different thing to me.

But anyway, I understand where we differ. You think the light tone
marks re-ordering not necessary. That's a big difference in the
assumptions to do further discussion, don't know how to clarify that
though...Richard?

/koji

On Fri, Jan 30, 2015 at 8:30 AM, Xidorn Quan <quanxunzhen@gmail.com> wrote:
> On Fri, Jan 30, 2015 at 4:47 AM, Koji Ishii <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.
>
> 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.
>
>>
>> The first point Xidorn made is right, but if I understand right, the
>> vast majority of Bopomofo is for ruby, right? Start from ruby might
>> make more sense if so.
>
>
> Yes, and the majority of ruby in Japan doesn't have span, right? They are
> rare, but may not be that rare, either. Especially given that bopomofo in
> ruby are almost only used in educational text and dictionaries, while inline
> bopomofo is sometimes used in normal text, it is hard to give the real
> proportion of bopomofo not in ruby.
>
> Actually my point was not limited to the inline bopomofo. I also mentioned
> vertical ruby, because before we collapse ruby-position values, when writing
> mode is vertical, the rubies are actually not using 'inter-character' but
> 'right'. This is no longer a problem now, but if we later wants to extend
> ruby-position to use pair syntax again, it will again become a problem. (In
> fact, one of the motivations I proposed to collapse the syntax is that
> 'inter-character' as a single value seems to make more sense for bopomofo)
>
>>
>> The second point is a spec issue. The forthcoming CLREQ could help,
>> editor resource maybe an issue but there could be contributors. I
>> think more important question is whether impl are interested in or
>> not.
>>
>> I heard that CLREQ is going to be published sometime this spring. If
>> specs can be done somehow, will you be interested in?
>
>
> I hope we can have a perfect bopomofo support. But I'm not convinced that it
> should be implemented in layout engine. I still think it should be done by
> fonts, and in the mean time, use dynamic polyfill.
>
> [1] https://www.moedict.tw/lab/ruby/
>
> - Xidorn
Received on Friday, 30 January 2015 06:03:32 UTC

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