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

On Thu, Nov 13, 2014 at 1:34 AM, Koji Ishii <kojiishi@gmail.com> wrote:

>
> Sorry I guess I was a bit late to respond, but there are use cases for
> spanning; it's not for an error handling. How often/rare is hard to
> explain, less often than normal ruby, but probably more than one might
> imagine.
>
> One thing that may help this discussion is that, spanning and line
> breaking within a ruby element (mostly for light novels[1]) are for
> different use cases, and they're almost never used together, so it's ok to
> disable line breaking when spanning occurs. Does that help complexity?
>
> If not, well, it's apparently better to have Ruby without spanning than
> not to have, or than to wait for months to years, but it'd be the best if
> we could find a way to help complexities without losing spanning.
>

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.

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?

- Xidorn