- From: Xidorn Quan <quanxunzhen@gmail.com>
- Date: Fri, 30 Jan 2015 10:30:53 +1100
- 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>
- Message-ID: <CAMdq69_VJVUyQoXTUHfqBgnngfsH_+9x2UL+Eiyo+ovUSK7Rhw@mail.gmail.com>
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 Thursday, 29 January 2015 23:32:05 UTC