Re: Ruby: Requirements and prioritization

On 26/02/2013 01:16, fantasai wrote:
>   董福興 Bobby Tung <bobbytung@wanderer.tw> wrote:
...

>> I've made a Bopomofo ruby sample as attachment for testing.

Murata-san, do we have that?

I have a page describing bopomofo ruby requirements that is not 
completely finished but that has enough information to be useful here. 
Please see http://rishida.net/blog/?p=494

>> Bopomofo is used in education area, usually for pre-school
>> and primary school. So It should be displayed accurately
>> as print textbook for adoption. Practically, neither browsers
>> nor reading system support Bopomofo ruby well. I'll list
>> reasons below:
>>
>> 1, Ruby-position: inter-character
>> Bopomofo should be all displayed vertically along the right
>> side of the glyph. In vertical writing, it performs well but
>> need letter-spacing fine tuned by reading system. In
>> horizontal writing, none of browsers support
>> ruby-position: inter-character attribution.
>
> I believe an appropriate workaround for this can be
>
>    rt { display: inline; writing-mode: vertical-rl; }
>
> This will turn the annotation into an inline-block with
> vertical writing mode, which will place it inline.
>
> However, I suspect ruby layout is currently hard-coded
> to the markup in the layout engines that support it, so
> this probably only works in theory.


I have tried to make the case several times before that the writing-mode 
approach doesn't address the problem, not least because the correct 
positioning of tone marks is important, and is not addressed by that 
approach.

That's why I introduced the inter-character value for the ruby-position 
property (which I originally wanted to call 'bopomofo') - that provides 
a very simple way for authors to specifically tell the browser that it 
should lay out the ruby as needed for vertical-right-sided bopomofo.

>
>> 2, Tone markings
>> Bopomofo has 4 tone marking: ˙ˊˇˋ.
>> First one ˙should be positioned top in ruby text area,
>> so that's ok in practice. But others should be along
>> the right side of ruby text area（二重構造になります）.
>> This structure is not in Ruby Module Draft. That
>> results Bopomofo display unable to fulfill educational
>> requirement, and hard to practice well.
>
> This is not a problem with Ruby, but with the display
> of Bopomofo in general. If you are writing in Bopomofo,
> even if you are not annotating a character, you will
> have the same problem. Therefore this should be solved
> by the text rendering system, not by Ruby. We want this
> tone mark positioning behavior in all contexts, right?
> Not just when Bopomofo is used with Ruby.
>
> Please correct me if I am wrong.


No, not correct.  See my page of examples.

And note, btw, that the tone marks are NOT combining characters in 
Unicode, but will need to be placed by the layout mechanism. (Just 
trying to head off a repetition of the typical suggestion that is made 
wrt tone positioning.)


>> 3, Ruby-align: center
>> Bopomofo usually combines with 1~3 characters.
>> And as mentioned in tone markings, one of them
>> should be placed in the top. To maximum 4 characters
>> for each glyph. In educational usage, all glyph
>> should be with their Bopomofo. So as W3C
>> draft, when ruby-align: center , narrow-cell
>> glyph ruby behavior have to be implied by
>> reading system to reach practical level.
>
> I will keep this in mind as we review the CSS Ruby drafts.
>
>> Hope reasons listed above able to let you
>> figure out Bopomofo ruby in practice. The
>> most critical problem is position of tone
>> markings. Once solved, with browsers'
>> and reading systems' implement and tool
>> to add characters and tone marking to
>> every glyph. It will be sufficient to use
>> EPUB 3 in language learning in Taiwan.
>
> If I understand the problem correctly, I think this critical
> problem needs to be solved outside W3C, as we do not control
> the text rendering engines.

Well not entirely. The CSS3 Ruby Module needs to allow the author to 
tell the browser to apply the layout necessary for bopomofo ruby support 
(and maybe the box model diagrams need some attention in that respect?).

What would *really* help, however, is a convincing request from the 
user community of bopomofo ruby to persuade browser implementers of the 
need to support that feature.  The request has to have persuasive 
representation from the community that uses bopomofo ruby, *and* should 
be accompanied by a set of requirements that explains how to do it.

(As a W3C person I can help with that, but I don't carry the influence 
of a user community.)

By the way, we produced a set of requirements for Japanese at 
http://www.w3.org/TR/jlreq/ and I'm currently working with some Korean 
experts to produce something similar for hangul.  I have heard about an 
initiative to produce a similar document for Chinese, but I'm not sure 
about its current status. Perhaps the bopomofo ruby requirements could 
be added to that, or perhaps they could be developed in isolation. 
Bobby or Murata-san, do you know of a group of typographic experts who 
would be interested in producing such a document?  I'm sure the 
Internationalization WG at the W3C would be happy to publish it as a W3C 
Note alongside our other documents.

RI

-- 
Richard Ishida
W3C
http://rishida.net/

Received on Tuesday, 26 February 2013 16:39:24 UTC