[jlreq] JLReq TF meeting notes 2023-4-11 (#361)

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

== JLReq TF meeting notes 2023-4-11 ==
# JLReq TF Meeting Notes 2023-4-11

### Atendees
atsuda, atsushi, kida, makoto, shinyu, suzuki, tahara, tajima, tlk, toshi


## CJK kerning - Improving the OpenType spec for clarification.
The ‘palt’ is a feature that turns fullwidth CJK glyphs proportional. The description of the ‘palt’ feature in the OpenType specification is misleading regarding its interaction with the ‘kern’ feature. The intention is that “for CJK glyphs”, ‘palt’ should be turned on when ‘kern’ is turned on. The “for CJK glyphs” is missing from the spec description. All known fonts follow the intention correctly, most likely because they directly or indirectly follow additional specs from Adobe. Different implementations, however, could exist which intend to apply ‘kern’ without applying ‘palt’, i.e. without making them proportional.

Implementations on the application side are known to be inconsistent, presumably because depending on how they interpret the spec, it can result in undesired results. Fantasai [proposed to extend the font-kerning property ](https://github.com/w3c/csswg-drafts/issues/6723#issuecomment-1411487571) to allow authors to control them independently. Also, Ishii-san [proposed to clarify this in the OpenType specification](https://github.com/w3c/csswg-drafts/issues/6723#issuecomment-1420204843). CITPC plans to submit a change request to the Open Font Format specification managed by ISO SC29 through the Japan mirror of the SC29 committee.

Discussions (including follow-up emails) and actions:
1. All agree that the specification needs to be clarified. However, there has yet to be an agreement between JLReq TF members on how it should be clarified. The disagreement seems to be mainly between the following two approaches:
A: The specification should be clarified according to the intention.
B: The specification should be formulated, including an alternative implementation that might exist.
2. The ‘intended’ font implementation is that they design the ‘kern’ table with CJK glyphs proportionalised by the ‘palt’ table. All known fonts follow this implementation. The alternative implementation designs the ‘kern’ table with fullwidth CJK glyphs while still having the ‘palt’ table.
2. As a new feature, Ishii-san desires to make kerning of fullwidth CJK glyphs possible with all Japanese fonts. An example he provided is that he knows a designer who wants to kern between ‘す’ and ‘。’ without making them proportional.
3. CITPC pinged ISO SC29 for a possible proposal for improving the ‘palt’ spec description.
4. Kida is discussing with Ishii-san and CITPC for industry-wide research on the font implementation regarding the ‘palt’ and ‘krern’ interaction.

## Simple-ruby document - improving the description of the two level processing
Shimono-san led the discussion and devised a proposal for the revised text. Bin-sensei would like to improve it further to consider surrounding space characters. Bin-sensei was to come up with the text.

Actions:
- Bin-sensei to come up with a proposal (done). Shimon-san to update text, submit for review and merge the change (done).
- We would like to agree on the update of the WD at the next meeting on 5/2. To this end, we would like to process all PRs by that time.

Other discussions
- The simple-ruby does not do ‘ruby overhang’. On the other hand, actual implementations on Safari / Chrome does. Are there thoughts on this? (Murakami) As the simple-ruby defines the minimal requirements, doing more is OK (Kida). JLreq describes a more advanced method. Also, its appendix has an even more refined technique (Bin-sensei). Let’s put both levels in JLReq-d (Kida). With print, you want to minimize the use of paper, so overhanging had its merit. Bin-sensei is unsure if it still has benefits on digital (Bin-sensei). Let’s add such a discussion as an informative text in JLReq-d (kida. jlreq-d #28)
- 1/4 overhang at a glance does not look overhanging because the overhang is mainly on the space between characters.  There is a style that allows such a small and consistent overhang on all characters, including Kanji (Bin-sensei)


## Folding long ruby
Long ruby can cause layout issues such as very short lines because line breaking is prohibited within.
On print, human eyes and proofreading resolved the layout issues.
Such human eyes, however, do not exist with digital text, where everything has to be automatic.
Kida came up with a proposal to make long ruby foldable for JLReq-d.
However, finding possible break opportunities within a ruby block can be computationally expensive for most applications. An alternative approach is necessary. Bin-sensei proposed to process them as a general annotation.

No actions at this meeting. Kida needs more time to think, and revise the proposal.


## Revised draft of JLReq-d TOC
Kida updated the first section of the draft TOC and sent it to the list on 4/11. The first section covers the basics for content creators and implementors who do not necessarily have prior knowledge of the Japanese language.
Discussions / Possible addional topics to cover
1. General
- Differences between print and digital where appropriate.
- Guidelines for text data, e.g. how to use proportional and fullwidth parenthesis, if a space should be added before and after words in Latin characters, etc.
- Possible roles of input methods, e.g. for punctuation
- The first section is to cover basics. If there are topics that are beyond ‘basic’ but shold be covered for content creators, we might want to create a separate section that are specifically dedicated for conent like we will have sections that cover details for implimentors.
2. Characters
- Joyo Kanji is sufficient for the day by day use, exept for proper nouns. (what is the purpose of mentioning this? kida to check with Bin-sensei)
- Cover characters that are unique to digital such as fullwidth / halfwidth characters, and similar punctuations between Latin / Japanese.
- Differences between Chinese / Korean Kanji.
3. Typefaces
- Readability on screen. Considerations for accessibility.
- Use of different typefaces for Kanji and Kana and Latin. Examples are small and large versions of Kana, and “antique” Kana typeface that was used in conbination with sans-serif Kanji (Bin-sensei)
- Typefaces for the main body text and titles or display typeface (Tajima).
4. Layout basics
- Rythm between Kanji and Kana
5. Layout with the baseline system
- Math and other non-Japanese elements (which are out of scope)
6. Vertical text
- Guidelines for creating text data that are compatible to both directions
7. Annotations
- Annotation methods on print assumes fixed pages; they do not necessarily work well on reflowable digital media (Tajima). Variety of new methods such as popup and link are possible with digital. It would be one of the most affected area by the transition to digital.
- Wikipedia has different form of annotation UIs between the desktop and mobile. Currently however there is no good way in HTML/css to consistently markup annotations while optimizing the UI depending on the clients’ device (Suzuki).


## Guidelines for creating web pages that are compatible to both orientations?
Following the previous meeting: there is a discussion regarding creating some guidelines for creating web pages that are compatible with both directions. Shimono-san sent a mail on 3/22 with the title “縦横切替想定時のCSSのbest practices”. Let’s discuss this on this mail thread and at the next meeting.


## Optimal baseline position and adjustments
Shimono-san pointed out a pending discussion in css WG that needs input from JLReq TF.
Kida to discuss this with him and follow up.


## New and pending todos
- Kida to setup a meeting with clreq to discuss re:default direction (up or down) of web form elements in vertical text direction.
- Murata-san to update ruby-t2s-reqs document.
- Kida to follow up with Shimono-san re:Optimal baseline position and adjustments.
- At (or by) the next meeting on 5/2 the group would:
  - Find a resolution on the ‘palt’ spec discussion.
  - Decide if we are ready to publish the next revision of the simple-ruby WD.
  - Discuss if/what we want to do with guidelines for creating web pages that are compatible to both orientations, and the baseline issue.


## Next meeting is on 5/2
Shimono-san to send out new URL to the group (done).


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


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

Received on Sunday, 23 April 2023 12:20:25 UTC