[jlreq] JLReq TF meeting notes 2023-5-2 (#362)

kidayasuo has just created a new issue for https://github.com/w3c/jlreq:

== JLReq TF meeting notes 2023-5-2 ==
# JLReq TF meeting notes 2023-5-2
### attendees
  atsuda, atsushi, kida, makoto, nat, shinyu, tajima, takeru, tlk, toshi

## simple-ruby updates
  - Status so far: The group have agreed on the term and the translation for the “ruby layout processing in two separate steps” as “two-level”. There are a few remaining PRs that need review.
  - Do we want Richard to review changes in a piecemeal fashion or the whole at once? (better to ask him)
    - Kida usually checks English text using grammarly.com before sending or submitting. He recommends it to everybody. It is a good thing - even native speakers use it.
  - Kida wants clarification from Bin-sensei on how the ruby and the base text will be aligned (simple-ruby #67)
    - Bin-sensei: The most common method is to fully justify the shorter of the two, leaving a small, a half amount, space at the start and the end. Other methods include justification without the surrounding space, simple centering without justification, or ragged right, although he rarely sees the last one.
    - Shimono: The justification can be done by following the spacing rules described in the spacing-property document. Other languages can follow their standard justification method.
    - **Todo**: Kida to draft the text and propose.
    - Bin-sensei: The method can get complicated with ruby overhang because when the overhang happens only on one of the sides, the text can become visibly out of the centre while it should be. You can see such examples in InDesign. **Todo**: Bin-sensei to send the example to Nat. It is out of the scope of the simple-ruby document because it does not adopt ruby overhanging.
  - There are a few remaining PRs. **Todo**: Shimono and Kida will get together to complete the review (5/8 @ Shinagawa).
  - Shimono proposed to proceed with the document update process after resolving the PRs, without bringing it up again at the JLReq TF meeting. The team agrees.

## Discussed the possibility of developing a guideline to create web pages that are compatible with both horizontal and vertical directions
  - Knowing requirements come first
    - We can’t set the scope without knowing the requirements. For example, do charts need to be made vertically, or does such a guideline concern layouts? What are target customers and critical scenarios?
    - What are the requirements?
      - Murata: The important requirements come from accessibility. Some people can’t read when text is vertical, or vice versa. The majority of issues are with the vertical text. Quality is not a priority for accessibility.
      - User preference, especially with ebooks.
      - **Agreement**: Let’s make accessibility and ebooks the target requirements.
    - Other discussions
      - Bin-sensei: Traditionally, all text is in the vertical direction. As words written in Latin characters and Arabic numbers increased, more books and documents became horizontal. Nowadays, the majority of them are horizontal. Literature books are typically vertical still. Also, printed newspapers are vertical.
      - Shimono: Law might be another example. They currently default to vertical, but there is a growing need to lay them horizontally. The government’s website allows downloading the law in PDF in both directions. (pdf!)
      - Murata: I have a strong concern that the guideline, by setting the bar higher, could work negatively, discouraging the development of ebooks allowing both directions because of the cost.
      - Kida: we can indicate in the guideline that allowing direction flipping is much more critical for accessibility than improving it by following the guideline.
      - Bin-sensei: Kanbun is hard to make horizontal. → Not important anymore.
  - Guidelines for the plain text
    - Such guideline is a planned part of JLReq-d
    - Areas involved include Number format, list headings, use of punctuation, and selection of words and characters that point to text or images in the same document, e.g. right/left and above/below.
    - Bin-sensei: Numbers except ones used in names and idiomatic expressions can now all be in Arabic numerals regardless of directions. This way, they are compatible with both directions.
    - Bin-sensei: I drafted a note somewhere in GitHub. Also, there is an article by Mr. Hasegawa. **Todo**: dig them up and send a link to the list (done).
    - **Todo**: Kobayashi-san volunteered to write up the first shot.
  - Guidelines for web pages
    - What issues involve? Examples are list headings and tags that use physical direction, e.f. margin-left vs margin-start. Are there others?
    - Murata: Developed epub samples that are compatible with both directions. There are no documents on how it was achieved. *1 *2
    - Murakami: Some epub readers allow flipping regardless of whether the book supports it. We could learn from how they do it. The ones I know are Kinoppy (developed by Infocity inc), honto (Morikawa), BookLive (Toppan), and Cocoro Books (sharp?).
    - Shinono: Some websites that let users read literature have similar features. Tajima: I heard an engineer at Line was talking about similar issues.
    - Murakami-san and Tajima-san can contact the developers/engineers with their connections or through EPUB-related mailing lists. Kobayashi-san can also contact them if they are members of CITPC (such as Toppan).
    - **Todo**: Shimono-san will draft a questionnaire for the developers/engineers.
    *1 https://github.com/Japan-Daisy-Consortium/samples/tree/main/%E7%B8%A6%E6%9B%B8%E3%81%8D%E3%83%BB%E6%A8%AA%E6%9B%B8%E3%81%8D%E5%88%87%E6%9B%BF%E5%8F%AF%E8%83%BD%E3%81%AAEPUB(alternate%20style%20tags)/epub_with_a11y_metadata
    *2 https://github.com/Japan-Daisy-Consortium/samples/tree/main/aozora
  - Timeline?
    - The original discussion was developing such document after we’ve done JLReq-d by converting it to vertical.
    - Can it be done earlier?
    - No conclusion.

## Functional analysis of layout features on print and digital (brainstorming)
  Kobayashi-san came up with a note titled 「機能論的アプローチへのメモ (a memorandum for functional approach) 」 and sent it out to the list.
  - Kobayashi: The writing system changes when the base technologies change. While the metal type is the foundation of JLReq, JLReq-d stands on a completely different model; they are dynamic contents on scrollable media. Trying to copy everything we had on paper to digital is nonsense. Instead, we should analyse the function of each layout feature and think/propose how digital text can achieve them.
  - Bin-sensei: I understand the motivation very well, but telling what we can throw away and what needs to stay is challenging. It is easy to spot things that could change, but it is not easy to tell how.
  - Kida: Agreed from my own experience.
  - Bin-sensei: I want shocking examples (of things that change from print to digital), but I have yet to find any. The kihon-hangmen (the base framework for measurement and placement of characters) will disappear, but what is the thing that would replace it? We can throw away two-sided ruby, but it does not significantly impact. Assumptions and dependency on fullwidth-ness might go away. Etc.
  - Suzuki: We still do not know what the proportional Japanese characters mean, i.e. the impact of making them proportional.
  - Bin-sensei: I want people to think more about readability. We can easily make long lines containing 50-60 characters, but the readability of such lines is low. The length of a line, the distance between lines, and the spacing would be keys for readability. Can they be controlled automatically?
  - Kobayashi: There should be a section discussing such transition of models.
  - Kida: Agreed. There would be things that change inevitably, and also something that could change; new possibilities.
  - **Todo**: Kobayashi to revise his note for further discussions.

## Impacts of EPUB 3.3?
  Are there any possible impacts?  As Murata-san had to leave early let’s discuss at the next meeting when he is in the meeting.

## Other updates (kida)
  - progress, meter & input=range elements
    - However I proposed a meeting, I think discussing on GitHub is better than having one shot call. I will talk to xfq (communication done. Kida to add comments on the github clreq/#500)
  - ‘palt’ OT spec
    - Discussing with Ishi-san and CITPC. Will get back to JLReq TF for approval when we have tentative agreements.

## The next meeting will be on 5/30 Tuesday


Please view or discuss this issue at https://github.com/w3c/jlreq/issues/362 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 5 May 2023 13:12:15 UTC