- From: Bobby Tung <bobbytung@wanderer.tw>
- Date: Wed, 11 Feb 2015 23:59:28 +0800
- To: Koji Ishii <kojiishi@gmail.com>
- Cc: Richard Ishida <ishida@w3.org>, "Martin J. Dürst" <duerst@it.aoyama.ac.jp>, Xidorn Quan <quanxunzhen@gmail.com>, www-style list <www-style@w3.org>, CJK discussion <public-i18n-cjk@w3.org>
- Message-Id: <E8EC292F-0866-4AE6-ACF8-369CDA4BB949@wanderer.tw>
> Koji Ishii <kojiishi@gmail.com> 於 2015年2月11日 下午11:00 寫道: > > On Wed, Feb 11, 2015 at 11:44 PM, Richard Ishida <ishida@w3.org <mailto:ishida@w3.org>> wrote: >> On 11/02/2015 13:28, Koji Ishii wrote: >>> >>> But I'm still unable to figure out whether the reordering is the right >>> thing to do or not. Bobby and Xidorn say it's not. Word does (thank >>> you Richard again for the investigation and updating the blog[2] as >>> always.) So, is Word doing what Taiwanese do not want? I have to admit >>> that it's quite possible;) but I consider this question is still not >>> fully resolved yet. >> >> >> hi Koji, >> >> To be clear: Word reorders the position of the light tone by changing the >> character order after you input the whole syllable. It doesn't reorder the >> glyph position using the font. >> >> The order of characters you end up with in zhuying annotations in Word >> matches that found in a number of dictionary implementations. It also >> matches the visual position of the light tone in all vertical text I've >> seen. >> >> From what I've seen so far, therefore, I'm inclined to think that putting >> the light tone mark code point at the start of the syllable has to be >> regarded as a viable, and probably actually the default, practice. >> >> The outstanding question appears to be, rather, whether placing the light >> tone code point after the bopmofo letter code points (usually only found in >> non-ruby instances) is actually a true use case, or whether this is just >> something that happens because people haven't bothered to change the output >> of IMEs. > > Hm, but all IMEs doing so indicates me that there were some reasonable > reasons for IMEs to output that order. Do we know why? In which order > does people write by hand? Maybe IMEs follow that? Yes, I think so. When writing Bopomofo by hand, usually Bopomofo characters first, then tone mark. IME follows the way. (e.g. ㄌㄜ˙) And tone mark as a selector to choose the character they want to input. But it’s also a sender-receiver issue. When people read Bopomofo, they are intended to pronounce the character. They will: 1, if there’s no light tone mark, combine the consonant and vowel(s). 2, check the tone mark, determine how to pronounce the character. 3, if there’s light tone mark, should pronounce lightly or there’s a tone change. tone change, here’s an example: 哥哥=Brother, 哥 only have one pronunciation (ㄍㄜ). But when you say 哥哥, it will be marked as (ㄍㄜ ˙ㄍㄜ)[1], later one should be short and light. This rule is like Japanese いい、ねね(姉さん)、にに(兄さん). And more rules. > If IMEs have some reasonable reasons, another question came up in mind > is that, should it be responsible for authoring software, or rendering > software. If it's a feature like AutoCorrect or SmartQuotes, then the > responsibility is on the authoring tools, not on the rendering > engines. Maybe that's the reason why Bobby thinks the rendering > engines should not be bothered? I think input Bopomofo by IME is not easy and effective, here’s a video [2] . Microsoft Word’s workflow is reasonable: input Hanzi -> add Bopomofo -> edit, if the character in alternative pronunciation -> mark up -> export HTML with ruby/rt tag. The MOEdict Bopomofo ruby tool[3] follows same flow. So it should be authoring tool / IME’s matter. Rendering engine do nothing to reorder will force people/tools to put light tone before Bopomofo character(s). That’s my thoughts. And one more additional information, CNS11643 search by Bopomofo [4] also ask user to input light tone mark before Bopomofo character(s). [1]: https://www.moedict.tw/哥 [2]: https://www.dropbox.com/s/mjx3y1ixlq5zg4y/input_bopomofo_by_IME.mov?dl=0 [3]: https://www.moedict.tw/lab/ruby/ [4]: http://www.cns11643.gov.tw/AIDB/query_general.do?active=1 > /koji
Received on Wednesday, 11 February 2015 16:00:12 UTC