The Case For Descriptive Ruby Markup

Authors:
Elika J. Etemad (fantasai)
Florian Rivoal
Translations:
English (This version)
日本語

Table of Contents

  1. Purpose
  2. Rationale
  3. Sample Public Statement
  4. Examples

Purpose

Ruby support in key EPUB and Web layout engines remains inadequate for proper support of Japanese despite development of the appropriate standards at W3C. We suggest that key actors of the Japanese publishing industry reach out to their contacts at Apple and Google about this issue and also put forward and sign a public statement aimed at making the Web platform community aware of the interest in ruby being supported properly. We hope that this will motivate layout engines developers (particularly Google and Apple) to work on supporting this feature, encourage the latest HTML standard to be updated, and most importantly, to make it so that the ruby can finally be used reliably across the Web and in EPUB.

Rationale

To make ruby work in e-books and on the Web, two technologies are needed: HTML to describe the content, the annotation, and their relationship; and CSS to specify the details of the layout.

If this is set up properly, we can achieve very flexible results: documents with ruby that are fully reflowable, with ruby annotations looking correct both in the middle of the line, and if there is a line break in the middle. We can also achieve personalizable content, when the readers can choose based on their preferences, disabilities, and reading proficiencies, if they want to annotate all characters or only some, and what kind of ruby layout they want, all from a single file, without any need to prepare different books for different people. This is useful for general readers, people with special needs, and school children…

The Japanese publishing industry, the Japanese Government, and various individual experts, have helped tremendously over the years in understanding the needs and supporting the writing of specifications.

While CSS standardization has been making good progress, the group responsible for the HTML specification is reluctant to accept the improvements developed with the W3C community, because not enough browsers vendors have expressed strong support. So far, the technology we're advocating for is largely supported in Firefox, and partly supported in Amazon Kindle. Google Chrome and Apple Safari/iBooks are behind, and only support an insufficient legacy ruby model. Since dedicated EPUB readers are often based on these engines, this problem limits what can be done for ebooks. In order to let the browser vendors know that this should be a higher priority, we would like to encourage publishing companies to express public support for this particular technologies.

Sample Public Statement

Here is a suggestion for a possible text to that effect:

Correct ruby layout is intrinsic and important to Japanese text layout. It is found in almost all publications targeted at children and teenagers, and in a significant amount of publications aimed at adults as well. Furthermore, ruby is an accessibility feature, and its markup needs to support those needs as well as rendering correctly.

Ruby as implemented in Blink and WebKit today does not support Japanese properly. Our publishing industry finds it inadequate. It enables a limited subset of the expected functionality, but does not support correctly-formatted reflowable content and responsive design, nor allows varying presentations tailored to users with different needs. Searching, copy-paste, and other operations also don't work sensibly.

For proper support of Japanese, we would need the following to be implemented:

The model followed by Firefox and Kindle, and specified by the CSSWG and former HTMLWG, shows how ruby can be marked up and rendered correctly. However, it has been many years that this is still not working correctly for Japan: it is not implemented in other engines, and is no longer included in the HTML standard. This is frustrating to the Japanese community, and undermines good-faith participation in worldwide consensus standards.

We request that the rest of the Web platform, its specifications, and rendering engines used for the web and for EPUB follow their lead so that electronic Japanese publications can finally be represented correctly in HTML+CSS.

The examples below can be attached as well in order to show clearly what our problems and expectations are.

Examples

Here are some examples illustrating the problems and limitations of the legacy implementations and the desired behavior and rendering of Japanese ruby.

Ruby Annotation Layout

Ruby layout over a compound word (jukugo) can be laid out in different styles.

“mono ruby” style: each character and its annotation are visually separated from the neighboring ones, even if this introduces space among the base characters
The Japanese word for “Kyoto city”, with phonetic annotations over each sillable. As the first one being wider than the character it's over, it pushes the next base character away slightly.
“group ruby” style: annotations forcibly share space regardless of length or font size
The Japanese word for “Kyoto city”, with phonetic annotations over the whole word. No attempt is made to match annotations to individual bases, and the text of the annotation is evenly spread over the whole word.
“jukugo ruby” style (at different font sizes): annotations within the compound word can share space if needed to avoid introducing space in the base text
The Japanese word for “Kyoto city”, with phonetic annotations over each sillable. As the font size of the annotation is small, all annoations are narrower than the chacter they are associated with. The Japanese word for “Kyoto city”, with phonetic annotations over each sillable. As the font size of the annotation is intermediate, the first annotation is wider than the character is is associated with, and is allowed to intrude over the second character, pusshing that second annotation slightly to the right, but not beyond the edge of the second base character. The third one and its annotation remain undisturbed. The Japanese word for “Kyoto city”, with phonetic annotations over each sillable. As the font size of the annotation is somewhat large, the first annotation is wider than the character is is associated with, but the first and second annotations together do no fit over the first two characters either, so all three annotation share space together.

Line breaking of compound words needs to be allowed and to preserve the correct pairing between base characters and their annotations.

Line-breaking of Jukugo ruby
Correct pairing between base characters and their annotation The Japanese word 京都, broken over two lines, with 京 at the end of the first and 都 at the start of the second, respectively annotated with きょう and と.
Incorrect pairing The Japanese word 京都, broken over two lines, with 京 at the end of the first and 都 at the start of the second. The first one should be annotated with a 3 character annotation but as that does not fit, the last of the three gets pushed to the next line suggesting an incorrect reading of each character.
Line breaking prevented inside words The Japanese word 京都, unbroken, despite appearing at the edge of a line. Half of it could fit on the first line and half on the second, but instead, the first line is undefilled and the whole word, with its annotations is on the second line.

This requires that the markup both expresses the paring between each base and its annotation, as well as groups them by word.

Ruby Annotation Structure

The underlying structure of the ruby markup also matters. The markup pattern supported by Blink and WebKit could be used to present compound words if the layout model was changed; but even in that case, because it breaks the compound word into pieces interleaved with the annotation, inlined presentation, search, copy-paste, and speech synthesis work poorly.

Legacy markup causes issues with search, copy & paste, and speech synthesis
An annotated Japanese word, visible in the text of a web page, is not found despite searching for identical text
An annotated Japanese word, visible in the text of a web page, is found after the user searches for oddly crafted string, alternating between syllables of the word with their respective annotations.
Recommended markup enables natural search, as well as copy & paste, and speech synthesis
A annotated Japanese word, visible in a web page, found by searching for its text.
Presenting ruby as parenthesized text inline with the base text is used both as a fallback in legacy systems and also when text is too small to be reduced further for ruby layout. In this case the compound word should be annotated with a single parenthesized unit, not syllable by syllable, which is harder to read and understand.
The word 京都, with small phonetic annotations displayed over it. The word 京都 with inline phonetic annotations, shown twice. In one case, the reading is correctly shown between parentheses after the word; in the other case, a parenthetical with the reading information is interleaved into the word after each syllable.

Ruby Alternate Presentations

Japanese books and educational materials need to support variations appropriate for different ages, school grades, reading preferences, and disabilities. It should be possible to produce all of these variations from a single source.

Variations appropriate for different ages, school grades, preferences, or disabilities, can be presented from the same source when using the recommended markup.
“mono” ruby (individual space) presentation Clear correspondance between annotation and base, but introduces unnecessary space in the base text The word 昆虫記 with each character distinctly annotated with its respective reading (こん, ちゅう, and き). A wide annotation over the central character push the surrounding ones apart.
“jukugo” ruby (shared space) presentation Muddles correspondance between annotations and base characters, but avoids unnecessary space in the base text The word 昆虫記 annotated as a whole with its reading: こんちゅうき.
hiding phonetic annotations for “easy” kanji Hiding annotations kept available in the markup allows for pedagogical choice in educational material and for accommodating reader preference (for example, some people with dyslexia find ruby distracting and prefer to hide it where non-essential). The word 昆虫記, with its first and last, but not middle, characters annotated
hiding phonetic annotations for all common kanji The word 昆虫記 with no annotation.
replacing kanji (base text) with kana (annotations) Kana-only texts can be more comfortable for readers who can't read kanji. The word こんちゅうき in phonetic characters only (hiragana).
providing annotation as full-sized parenthesized text Fallback rendering for engines without support for ruby, but can also be used as a deliberate choice for readability at small font sizes or to avoid needing large inter-line gaps. The word 昆虫記 followed by its reading in phonetic characters (hiragana) between parentheses.
mixed-mode presentation Inlined phonetics for hard kanji, hidden annotation for easy kanji, phonetic ruby for at-level kanji. The word 昆虫記 with its first character replaced by its reading in phonetic characters, and the last one annotated with its reading.
Inlined phonetics for hard kanji, hidden annotation for easy kanji. The word 昆虫記 with its first and last characters replaced by their reading in phonetic characters.
Changing the rendering between normal kana and full-size Kana, as is sometimes done at small font sizes to increase their visibility, without affecting search, copy & paste, or speech synthesis.
The word 今日 shown twice: once with its normal reading shown as an annotation once annotated with the same sting except the middle character ょ has been replaced with the larger よ.

Double-sided Ruby

Although less commonly used, double-sided ruby exists, and should eventually be addressed also. A typical use case would be to provide a familiar loanword alongside a native but somewhat obscure or ambiguous Japanese word that also needs to be annotated for pronunciation.

Double-sided ruby, with meaning and pronunciation. Here, the ambiguous word 計算機 can mean either “computer” or “calculator”, and is annotated below to clarify its meaning as “computer” while annotated above to give its pronunciation.