- From: Koji Ishii <kojiishi@gmail.com>
- Date: Fri, 30 Jan 2015 15:03:04 +0900
- 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:40 UTC