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

> 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