JLReq TF meeting notes 2020 January 30th

JLReq TF meeting notes 2020 January 30th

Attendee
–––––––––––––––––––––
Kobayashi, Tatsuo
Kobayashi, Toshi (Bin-sensei)
Murata, Makoto
Murakami, Shinyu
Shimono, Atsushi
Tajima, Jun
Kida, Yasuo

Notes
–––––––––––––––––––––

JLReq talk on Page 2020 (2/7)
Kida will talk re:jlreq updates at Page 2020 on 2/7. Attendees are not necessarily technical. Tajima-san recommended to talk about features that are not available yet and their draft CSS specs to watch. Kida to draft the presentation pages asap.

Ruby 
A question from Amazon (#158 <https://github.com/w3c/jlreq/issues/158>). Murata-san relayed comments from Bin-sensei (done).
Bin-sensei has a paper he wrote back in 2012 regarding ruby layout. He will forward the PDF to JLReq admin list (done). It has almost 150 pages!

Issue with using Github for everything 
GitHub is not necessarily a solution for every communication needs. The most serious issue is that it sets a high bar for people who are not necessarily technical. Also, as it is an issue tracking tool, it is not necessarily suitable for general free form discussions. Currently ad-hoc email threads is used to overcome the issue.
Kida to discuss the solution with Richard.

Gap Analysis: Reviewing JLReq 2nd round
We’ve done the first pass of reviewing JLReq. As we make progress we found we want to capture more data, such as separating issues between paged and non-paged media, if it is a readability issue, issues with JLReq itself, etc. We’ve begun the 2nd pass on a spread sheet document <https://www.icloud.com/numbers/08_s1eJdMxnqIMKfbjqtZJmMw#JLReq_TF_-_Gap_Analysis_Comparison> to capture these data / discussions on each section of JLReq. We want to generate GitHub issues as we identify ones that needs to be tracked.
 As we review priorities, we recognised features that are not realistic on digital document. One example is 3.1.3 "Exceptional Positioning of Ideographic Comma and Katakana Middle Dot”. It is not trivial to automatically detect if a middle dot is meant to indicate a decimal point. They are not just “low” priority but we want to un-recommend them for digital. Also there are issues that are unique to digital and therefore not mentioned in JLReq. As JLReq was developed to record what has been done on print, there are issues that people need to be aware when it is applied to digital. Attendees found benefits of developing an amendment (or a similar document) that adds comments on existing JLReq. Not only it will help existing standard developers and implementors it will serve as a good first step for the next generation document. Filed #162 <https://github.com/w3c/jlreq/issues/162>. (What is the process of proposing such a document?)
 Generated the following github issues. They are labeled with “amendment”. More to come.
 #164: 3.1.3: There is no simple way of achieving what's described in 3.1.3 amendment
 #165: 3.1.4: add note regarding the amount of space when two characters have different font size amendment
 #163: 3.2.6 d: Discussions regarding the amount of inter-character spacing between Kanji and alpha numeric characters amendment
 #161: 3.3.1: List and discourage use of characters that are intended only for a specific writing direction amendment
 We’ve reviewed up to the section 3.1.5.
//