W3C home > Mailing lists > Public > public-i18n-cjk@w3.org > January to March 2013

Ruby: Requirements and prioritization

From: MURATA Makoto <eb2m-mrt@asahi-net.or.jp>
Date: Fri, 22 Feb 2013 17:12:16 +0900
Message-ID: <CALvn5EBQMhayWTbaEAe1YAazENBY7PSdDbUawHYkjKWxLxd5AQ@mail.gmail.com>
To: "CJK discussion (public-i18n-cjk@w3.org)" <public-i18n-cjk@w3.org>
Cc: 董福興 <bobbytung@wanderer.tw>
Dear colleagues,

I would like to thank those who are very interested in
HTML5 Ruby.  They help CJK users a lot.  But I would
like to request more study of requirements and

First, Bopomofo ruby of Taiwan is not supported well.  More
about this, see the attached mail from Bobby Tung.

Second, in a workshop "eBooks: Great Expectations
for Web Standards", the CSS WG chair pointed out
an issue with CSS Ruby(WD), from which EPUB3
borrows a feature (-epub-ruby-position).    But this
working draft is old and is not being developed by any
member of the CSS WG.  IDPF is aware that this
feature is mandatory for the support of Bopomofo
ruby for horizontal writing.

Third, the Electronic Book Publishers Association of Japan
conducted a survey of requirements last year.  Twenty
features are about Ruby.  All features except the distinction
of mono/group/jukugo ruby are ruby formatting.  Double-side
ruby is not mentioned.

http://www.ebpaj.jp/images/youbou.pdf (in Japanese)

Fourth, a number of pages in JLREQ are devoted to Ruby.
Again, they are about the distinction of mono/group/jukugo
ruby as well as ruby formatting.  Only two sentences are
devoted to double-side ruby, and it is described as
"very rare."


Fifth, some of you remember that I am against HTML
double-side ruby.  My mails did not change anything, but
they are available at:


Makoto (lead of the Enhanced Global Language Support sub-group of the

---------- Forwarded message ----------
From: 董福興 Bobby Tung <bobbytung@wanderer.tw>
Date: 2013/2/21
Subject: RE: Bopomofo ruby in EPUB3: -epub-rub-position
To: eb2mmrt@gmail.com
Cc: Markus Gylling <markus.gylling@gmail.com>, 龐 文真

Mr. Murata

I'm Bobby Tung from Wanderer Digital Publishing Inc. in Taiwan.
Sophie Pang forward this letter to me. If possible, please forward
to members in mail-list and let me follow the discussion.

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

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-charater attribution.

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.

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.

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.


Bobby Tung

WANDERER Digital Publishing Inc.
Bobby Tung
Received on Friday, 22 February 2013 08:12:50 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:10:24 UTC