W3C home > Mailing lists > Public > www-style@w3.org > November 2014

Re: [css-ruby] spanning of ruby annotations across excess bases

From: Koji Ishii <kojiishi@gmail.com>
Date: Thu, 13 Nov 2014 15:24:17 +0900
Message-ID: <CAN9ydbUMRN0QQNurS4D0We9mpVVRi=M_5Gr2fvi7Kai-T9DYEQ@mail.gmail.com>
To: Xidorn Quan <quanxunzhen@gmail.com>
Cc: fantasai <fantasai.lists@inkedblade.net>, kawabata taichi <kawabata.taichi@gmail.com>, "L. David Baron" <dbaron@dbaron.org>, "www-style@w3.org" <www-style@w3.org>
On Thu, Nov 13, 2014 at 5:53 AM, Xidorn Quan <quanxunzhen@gmail.com> wrote:

> I have another suggestion. I found that in all use cases I had seen in
> JLREQ and specs, spanning is never directly connected with any previous
> separate-paired annotation. Is that make sense to only have span when an
> annotation is the only child of a <rtc>? I think that could significantly
> reduce the complexity on width calculation (which is the hardest part in my
> opinion) and line breaking. In addition, even if we drop spanning
> completely, we have to process this level of complexity to support
> ruby-merge anyway.

I don't understand what you meant by "connected", but do you mean to allow
spanning only when there is only one <rt> child for a <rtc>? If that's the
case, I think it's reasonable. If I misunderstood what you meant, can you
clarify a bit more?

> Another note regarding JLREQ is that, it was said repeatedly so most
>> people here might know but, in the policy h of 1.3[2], JLREQ states that
>> its coverage is limited to "common books". The term "common books" is not
>> clearly defined, but you could read it as "novels". In such "common books",
>> not only spanning but also double sided ruby is really really rare, but in
>> other markets such as educational materials, double sided ruby is a
>> required feature. Another example is use of double quotes; JLREQ states one
>> way and the other way is completely wrong and rare, while that the other
>> way is the rule for other markets such as closed captions or often used in
>> magazines.
>> What I wanted to say here is that, when you want to determine if a
>> feature is common or rare, you should think about which markets you want to
>> target to, and depends on that, sometimes JLREQ may not help to determine
>> that. The primary purpose of JLREQ is to define rules used in Japanese
>> "common books", not to provide data of how common a feature is used in the
>> whole Japanese documents.
> Thanks for the explanation. I'm sorry that I didn't notice that
> limitation. I wonder if there could be more materials about cases other
> than "common books". Could you provide some?

Unfortunately, no, as far as I'm aware of. JLREQ derived from the most
major editor school, but authors for non-common books tend to be
professional and far fewer than common books to establish such schools.

Received on Friday, 14 November 2014 08:40:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:51:49 UTC