develop an amendment for JLReq 2nd edition

[kidayasuo]

from 2020-01-30 TF meeting.

The current JLReq is intended to describe what has been done on print. Digital text has a different set of characteristics compared to the print process. Simply they have different architectures. As the result we are seeing issues when rules that had been cultivated on print is applied to digital. Notable differences are: • The layout on print assumes manual inspection and adjustments. The layout is completely automatic on digital. • On print the style is applied and fixed before it is published. On digital the style is applied when the data is displayed on receivers' screen. Each receiver can have a different text style.

Other than issues that stems from the differences in the architecture, there are features that can be simplified or can take other form on digital devices which has a different set of capabilities and limitations. Affinity to international standards and frameworks is important on digital. Consideration for accessibility is becoming more and more important. etc.

There is a clear need for developing the next generation of JLReq or a similar document. It takes time however. At the JLReq TF meeting on 2020-01-30 attendees found benefits of developing a simple intermediate document that adds comments on existing JLReq features regarding their limitations when they are applied to digital and recommendations. It stemmed from the gap analysis. Not only it will help existing standard developers and implementors it will serve as a good first step for the next generation document.

[xfq]

What would the form of the intermediate document be?

[kidayasuo]

amendment is the idea we came up, but as we are not familiar with practices in W3C, your suggestion would be very much appreciated.

[xfq]

amendment is the idea we came up, but as we are not familiar with practices in W3C, your suggestion would be very much appreciated.

I'm not aware of any W3C document that adds comments on sections of another document. The closet things that came into my mind were the Annotated XML Specification and the W3C Web Annotation technologies (like Hypothesis).

I don't quite understand the advantages of this approach, though (I didn't attend the jlreq TF meeting, so I might be missing something). I personally think that some information can be directly added to jlreq itself (as a note in the main text, or as an appendix), and some information can be discussed in the form of a GitHub issue.

[himorin]

I am actually not reaching to some clear idea, during the meeting nor as for now, I think our starting point was something similar to simple-ruby document, which discusses a possible implementation to limit features within ones fitting to digital publishing on one topic. As noted in kida-san's comment

• there is clear requirements to update 'Japanese Text Layout' requirements to follow natures of digital publishing, but going through the entire set of coverage is a huge work and could take much time
• there is some specific area which we already have idea(s) for new document, such as simple-ruby for starting point of replacing ruby section, and where we'd like to issue some note (or amendment) to update the current document

If we issue an updated version of whole JLReq note including such partly updated sections, such document with mixed conent could cause confusion to users (standard developers and implementors). So, it is quire welcome if some nice way exists...

[macnmm]

I want to think about this while at the same time thinking of how better to organize the document and add appropriate missing info for implementors. I think there is overlap in the needs of the automatic layout implementor and the non-expert in Japanese print implementor. My main concern with what goes into the amendment is for the de-emphasis of certain traditionally acceptable practices that no current digital implementation does, and so it has less value than when everything was photo-typeset. To the extent possible I would like for explanations to include an analysis of why a certain practice was done (e.g. the space between numerals and Japanese in metal type was due to limitations of how thin the thinnest space could be (?)) and not therefore desirable as a modern default.

[kidayasuo]

Yes, I very much agree that we want more background info.

As for your concern about de-emphasising traditionally acceptable practices, I think we can avoid misunderstandings by clearly explaining that these apply for reflowable digital text.

[xfq]

To the extent possible I would like for explanations to include an analysis of why a certain practice was done

I agree with that. We can even write a document similar to this, if possible: https://wiki.whatwg.org/wiki/Rationale