As you know, the document Requirements for Japanese Text Layout (JLREQ) was last published in April 2012, as the result of some years of activity by a group of typographic experts in Japan. ||| Although many of the requirements arose originally from book publishing use cases, the majority of the requirements are still very relevant to Web pages, and especially to ebook and other paged formats on the Web. ||| It has been a very useful source of requirements for W3C standards, and for Web and ebook developers.
Because it is technology agnostic, JLREQ provides a useful base for assessing the state of the Web platform in terms of meeting Japanese publication needs, and is likely to continue to be useful far into the future. ||| Recently, the JLREQ documents (English and Japanese) were ported to the respec format and added to a repository in GitHub, in readiness for any future work, and to make it easier to capture and manage issues with the document.
Once we have a good description of the requirements, the next step is to use those requirements to assess the gaps in feature sets for specific technologies. ||| This is most often done in an adhoc way by implementers of browsers or ebook readers, or by specification developers. But in other cases, a more coordinated approach has been adopted.
For example, a workshop was held in Tokyo in 2013 entitled eBooks & i18n: Richer Internationalization for eBooks, where the audience was largely Japanese, and the list of prioritised issues in the report signalled that the top two concerns for workshop participants were support for vertical text and ruby. ||| Other high scoring topics were the development of other requirements, similar to JLREQ, for other scripts, and better support for line-breaking rules, nakiwakare, and tate chu yoko.
Work is currently ongoing on other script requirements, and similar documents to the flagship JLREQ document are being developed for Chinese, Korean, Indic, Ethiopic, Arabic, Tibetan, Latin and Hebrew scripts.
Work has also been proceeding on standardisation of vertical text and ruby in CSS since that time, and there has been some encouraging pickup of those features in browsers, though there needs to be more. ||| The CSS Writing Modes Level 3 spec is currently in CR, and it and other specs, such as CSS Text Module Level 3, CSS Ruby Layout Module Level 1, and others, have drawn significant benefit from the information in JLREQ.
In January of this year, representatives of several Japanese organisations sent a Member Submission to the W3C titled Current Status of Japanese Typography Using Web Technologies that studied whether or not CSS and HTML are sufficient for the layout of paginated documents in Japan. Specifically, they studied requirements in two documents: W3C's JLREQ and EPUB3's Petition of Japanese typesetting from EBPAJ. ||| The submission shows which requirements are covered by which CSS specification and supported by major browsers. It concluded that CSS as of now is quite good for Japanese paginated documents and that it will become even better if a few more modules (most notably Paged Media) are fully developed and implemented.
The findings just mentioned are very useful to obtain a high level view of the situation, but will be more useful when maintained over time and combined with additional work such as feature prioritisation and detailed research. ||| Some of recent developments at the W3C can help.
On 13 March of this year the W3C Internationalization WG published an article titled, Styling vertical Chinese, Japanese, Korean and Mongolian text. ||| The article helps content authors use CSS to create vertical text for Chinese, Japanese, Korean and Mongolian. However, it also describes in detail what currently works and doesn’t work in major browsers, and provides tests you can run in your own browser. ||| This provides a useful next step to establish the current status of vertical text support in browsers from a user perspective, but in fact compiling the early material for the article also influenced the development of the CSS Writing Modes spec.
I will now list a number of other recent developments arising from the work of the W3C Internationalization Working Group that also support deployment of features related to Japanese typography.
The article Ruby Markup was also recently published by the i18n WG and tells content authors how to code markup for ruby text. Like the article on vertical text previously mentioned, it comes with examples that readers can use to test the behaviour on their browser, and also like that article, work on this article influenced the development of the CSS specification.
A similar article, Ruby Styling, is in preparation to cover positional aspects of ruby, per the CSS Ruby specification. Like the article on vertical text, this will also provide detailed information about which browsers support which features, and will have links to test files.
Work has also been done to develop a wider set of tests which are contributed to the Web Platform Test Repository. The tests are also hosted as part of the Internationalization test suite, which, in addition to the links to tests, displays actual results for the major browsers. Relevant tests include:
The Internationalization WG has just published a FPWD of the document International text layout and typography index. This document points browser implementers and specification developers to information about how to support typographic features of scripts or writing systems from around the world, and also points to relevant information in specifications, to tests, and to useful articles and papers. ||| CSS specifications will in future link to this document so that implementers can find detailed information about how scripts work. It is expected that the index will be constantly updated.
The document not only helps people find information about the requirements of scripts such as those used for Japanese, but it also points to currently open questions about how scripts work (for providers of script requirements), to requests for implementation of features in specs and browsers (for spec and browser implementers). ||| For example, it currently points to a thread asking how text-decoration-skip:ink should be used for ideographic/CJK scripts and another asking how emphasis marks should behave in relation to auto-hidden ruby. ||| This provides, for the first time, a way of tracking currently open questions about how a particular script works, and also the status of implementation requests for that script.
The typography index just mentioned also points to the index for the brand new type-samples GitHub repository. This repo collects images of typographic usage that can be used for examples, tests, or illustrations. ||| For example, there is already an image illustrating Japanese list and counter-style features, and another illustrating warichu.
The aforementioned materials and indexes have been useful recently for new standardisation work other than CSS and HTML, that involves features related to Japanese typography. ||| Last year the i18n WG reviewed the WebVTT specification, and we are currently in the middle of discussions with the creators of TTML2 (Timed Text). Both of these specifications attempt to support vertical text and ruby for the Japanese market, but need assistance to ensure that the features specified meet the actual requirements of the Japanese users.
We expect other specifications to need similar advice in the future, and the i18n WG is currently considering defining a content model for ruby markup that will bridge the differences between the Ruby Annotation spec and the HTML ruby content model.
The work on support for vertical text, ruby, and other features of Japanese has been moving forward, but there are still features that need a commitment from browser vendors to complete the support needed. ||| For example, although vertical text is mostly there, the upright value of text-orientation is a must for good vertical text in Japanese, but doesn't have good browser support. ||| Likewise, support for the digits value of text-combine-upright (tate chu yoko) would also make life much simpler for content authors, but is still not widely supported in browsers. ||| Double-sided ruby support for most browsers currently requires use of HTML5's nested ruby syntax, rather than the more straightforward and extensible tabular model of ruby content, and ruby-position needs better support, not to mention more advanced techniques for aligning ruby text, handling overlap, etc. ||| And so on for other features.
Note, however, that a major barrier at the moment is that implementers of browsers/readers have plenty to keep them occupied, and need to be convinced of the need to fill gaps of this kind. ||| The best, and often only way, to persuade them is for user communities from an affected community to make a strong case for the implementation. Logical arguments alone are not sufficient. ||| Implementers need to be convinced that lack of support for these features is actually causing noticeable difficulties for use of their applications.
I therefore recommend that we continue to analyse where the gaps are in Japanese feature support, but do so at a more detailed level; ||| that we then prioritise and make the case for addressing those gaps, and do so at a more granular level than before; ||| and that we find some way to show where the pain points are for users, content authors and developers, so that implementers are persuaded to incorporate missing but needed features in browsers and ereaders.
Typography experts in Japan may also consider re-forming the Japanese Layout Task Force under the W3C I18n IG (we now have a standard framework for such groups), in order to work on various editorial, errata and possibly substantive adaptations of JLREQ.
There is also value in coordinating with the Chinese (and possibly Korean, if there are active experts) layout work to clarify the wider picture of how things such as vertical text, ruby, line-breaking, text-decoration, etc. should work. There are small differences that need to be balanced out in the standardisation approach.