Re: Ebook requirements for Ruby markup

Hi Robin,

Thanks for the quick response, I made email introductions separately for
you to the Taiwan folks who had previously pinged me about it.

Re: use of Ruby presently in eBooks, the Japanese publishing industry has
developed a profile of EPUB 3 that in my understanding is significantly
adopted already there for both reflowable and fixed-layout content. It
references Ruby in some detai. As the profile as a whole is EPUB 3
compatible and EPUB 3 normatively references HTML5 that would imply this
usage is XHTML5-based. But Ruby also in my understanding has
styling-related aspects (see:
http://www.idpf.org/epub/30/spec/epub30-contentdocs.html#sec-css-ruby-position)
so I think this involves CSS spec(s) as well as HTML5 spec, perhaps.
Anyway the Japan profile has been translated to English and is publicly
available - see:
http://idpf.org/news/electronic-book-publishers-assoc-of-japan-publishes-epub-3-file-creationfor
background and link.

Cheers,

--Bill

---------- Forwarded message ----------
From: Robin Berjon <robin@w3.org>
Date: Thu, Sep 5, 2013 at 8:27 AM
Subject: Re: Ebook requirements for Ruby markup
To: Bill McCoy <whmccoy@gmail.com>
Cc: public-digipub@w3.org


Hi Bill,


On 05/09/2013 16:51 , Bill McCoy wrote:

> I noted that the informative references don't appear to include anything
> specific to the Traditional Chinese application of "Bopomofo Ruby". This
> is apparently of quite critical concern to publishers in Taiwan,
> particularly education publishers but also in some other segments. So I
> attach a document recently circulated to my attention and would urge
> that you or someone involved double check that requirements listed there
> are understood and ideally addressed.
>

My understanding, which may be entirely wrong or missing something, is that
Bopomofo is actually supported by the markup model we have but that most of
the issues are at the rendering layer (i.e. either stuff missing from CSS,
or poorly implemented).

That said, looking at the example on the slides (very useful, thanks) I
wonder if we adequately capture the case of tone marks being set aside
right. I *presume* that they are logically part of the bopomofo annotation
and so the decision to place them right in that way can be made entirely at
the rendering layer (in which case no change is required). But my
experience with I18N is that presuming anything is usually a pretty bad
idea, so I'd love to hear confirmation here.


 I would be happy to connect you
> with stakeholders there if they are not already part of this list, as
> IDPF has many members from the Taiwan publishing industry (and I will
> visit there later this Fall).
>

If that were possible, I'd be very interested in hearing from them yes.
Thanks.


 If for some reasons all requirements inc. Bopomofo can't be addressed
> directly in the base spec then it could be considered whether a
> publishing-specific extension could be made, perhaps only in EPUB
> context, but I'd rather have the Open Web Platform be suitable "out of
> the box" and move in the direction of convergence.
>

Having a publishing-specific extension is something that I would dearly
want to avoid; people need to publish with ruby on the Web, and we need to
get it right.


 A separate item that I presume needs to be investigated is implications
> of your proposed changes in markup and processing model for backwards
> compatibility of existing uses of ruby inc. in EPUB. Should this perhaps
> be listed as one of the issues?
>

That's a very good point. Support for ruby on the OWP in general is pretty
poor (to say the least) so backwards compatibility has not been one of the
foremost concerns. But I would be very interested in hearing about what is
being used currently in EPUB. What *do* people use for ruby in ebooks? I
can think of (at least) three options:

  - The HTML5 model, presumably as XHTML5.
  - The XHTML model, which is significantly different (
http://www.w3.org/TR/ruby/) and quite complex to manipulate as markup.
  - Something proprietary.

Knowing what is used, and how much, could certainly be a deciding factor.


-- 
Robin Berjon - http://berjon.com/ - @robinberjon