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

Re: [css-ruby] The default value of ruby-align is undesirable for bopomofo

From: Bobby Tung <bobbytung@wanderer.tw>
Date: Wed, 11 Feb 2015 09:15:54 +0800
Cc: Koji Ishii <kojiishi@gmail.com>, fantasai <fantasai.lists@inkedblade.net>, "www-style@w3.org" <www-style@w3.org>, CJK discussion <public-i18n-cjk@w3.org>
Message-Id: <C1CA71DE-3792-4ACF-ACEF-FF6C637F9778@wanderer.tw>
To: Xidorn Quan <quanxunzhen@gmail.com>
> I discussed this with Bobby on Twitter, and he thought bopomofo should be justified like ideographic characters in theory. [1] But I don't know. I'm fine with either way. 

Inline? Theoretically, Bopomofo as an inline element should not be separated by line-break, and "semantically" no justification opportunity. Behave as two emdash(——) and two ellipsis (⋯⋯).

But there's no rule about justification in Chinese layout. In my opinion, when justified, the space should be inserted into every letter spaces in the line. The principle is more important than justification opportunities.

Sent from my iPhone.

> Xidorn Quan <quanxunzhen@gmail.com> 於 2015年2月11日 上午8:55 寫道:
>> On Wed, Feb 11, 2015 at 1:29 AM, Koji Ishii <kojiishi@gmail.com> wrote:
>> > On 01/14/2015 09:12 PM, Xidorn Quan wrote:
>> >
>> > There are justification opportunities between bopomofo characters, just
>> > like other Chinese/Japanese characters. But if we have
>> > "ruby-align: space-around" on them, we will get an undesirable result,
>> > because bopomofo is generally centered when in annotations.
>> Just want to confirm, are you sure there should be justification
>> opportunities between Bopomofo characters, or are you saying so
>> because current impls do so?
> Maybe we should check with Unicode folks about whether bopomofo should behave like ideographic characters in this case.
> [1] https://twitter.com/bobtung/status/555534386901184512
> - Xidorn

Received on Wednesday, 11 February 2015 01:16:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:52:01 UTC