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

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

From: Xidorn Quan <quanxunzhen@gmail.com>
Date: Fri, 30 Jan 2015 10:30:53 +1100
Message-ID: <CAMdq69_VJVUyQoXTUHfqBgnngfsH_+9x2UL+Eiyo+ovUSK7Rhw@mail.gmail.com>
To: 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 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
(3) Reordering of code points is usually done by layout engine instead of

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 Thursday, 29 January 2015 23:32:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:51:57 UTC