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

About light tone position, Richard may forward my opinion here. We do not have conclusion right now, but respect dictionaries' layout and the guidebook by MOE, even authors input character by this order: 

ㄇㄧㄠ˙ 喵

Ruby tag should be 

<ruby>喵<rt>˙ㄇㄧㄠ</rt></ruby>

by a generator or tools like Apple's Pages on Mac.

And about Layout Engine / OpenType. My opinion: there are four major render engine: gecko, trident, WebKit and blink. But a lot of font foundries and fonts. 

If we have consensus it's not a layout engine issue. I'll try to talk with font foundries to support the feature, but take longer.

And the tone marks are in Latin extension I remember. So we may face fallback issue. 


WANDERER Bobby Tung
Sent from my iPhone.

> Koji Ishii <kojiishi@gmail.com> 於 2015年1月30日 下午2:03 寫道：
> 
> 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 12:10:00 UTC