JLReq TF meeting notes 2023-2-28

JLReq TF meeting notes 2023-2-28

attendee: atsuda, atsushi, kida, murata, nat, shinyu, tahara, tajima, tatsuo, toshi, yamahige

Introduction & demo of a JavaScript library that supports web forms in Vertical direction (by Murata-san)
Currently browsers do not support web forms in vertical direction well. Murata-san introduced and showed the demo of the vertical web forms implemented in Javascript. It can be useful especially in the education market.


Will we develop a JLreq-d document formatted in vertical direction? (Yamaguchi)
The question triggered interesting discussions. In sum: We will not commit on producing such a document due to anticipated challenges and the workload. Experimenting producing it, however, would lead to findings that would be by themselves valuable. We’ll keep the discussion alive.

discussions:
The text data needs to be altered depending on the direction. Examples are punctuation, the number format and list labels (Bin-sensei). It means you need two separate text data for vertical and horizontal. Is it truly necessary considering the downside? (kida)
Being compatible to both directions is a desired feature for accessibility. It does not need to be perfect at all (Murata)
There will be many challenges, esp. modifying respec will be a big project by itself. Such project would not be this group’s interest. (Shimono)
It would be more fruitful if the goal is not the document itself but to find out issues in order to find out issues and possibly develop a set of guidelines for making html that are compatible to both directions (kida)
Let’s keep the discussion alive for a future possibility. We would need to understand the importance / positioning of vertical writing in Japanese language, e.g. if it is worth maintaining this additional cost for the future. (Kobayashi)
How about adding a section in JLreq-d about creating data that are compatible for both directions.
Does it cause a conflict with the interleaved format currently JLReq use? (Shimono) We’ll not use the interleaved data structure, I will strongly oppose to the current format unless we have confirmed we can display it without interleaving to its users. (kida)
As a related topic, is it possible to make vertical text examples that are now graphics in JLReq a real vertical text and make them interactive? (kida) - will be difficult considering it would depend on browser’s ability, and we often need to illustrate features that they do not yet support. Could be considered for case by case (Bin-sensei).


Re: a proposal by fantasai to extend the font-kerning property (Murakami)
(related to a mailing list thread “CJKフォントのpalt（詰め組）とkernの関係”)

The problem
If you turn the kerning on, which is on by default, it also turns on palt, kerning for Japanese characters, which should be off by default. Most Japanese fonts do have the palt table and it results in unexpected character width.

The proposal
Create a new property ‘kern-non-cjk’ and make it the default.

The benefits
It achieves beta-gumi, fullwidth character width, that is right now broken on browsers. Also, it will create a proper way to achieve tsume-gumi, kerning between Japanese characters, on html.

Remaining issues
How it determines if the character is CJK? The proposal is based on Unicode EAW. Is it ok? Depending on fonts certain symbols and characters can be either fullwidth or proportional (e.g. greek and math symbols)
Is it compatible with Japanese fonts that are natively proportional?
The only known proportional Japanese fonts that can be affected is MS-Mincho. Are there others? Other known proportional Japanese fonts such as Kazuragi are based on a ligature table and will not be affected.
We should update OpenType documents. Nat said he can propose it from Adobe to MS. Also, Murata-san can propose it through ISO. It would be a good idea to take both approaches.

todo
Kida to call a meeting to discuss necessary updates to the OpenType spec, with CITPC members.

Ruby issues
Need to fix the English term to describe its “opaque ruby box” in the simple-ruby document.
Murata-san is fine with the current translation
We might need to discuss how to handle cases where spacing characters come before or after ruby.
Should we also discuss regarding the proposal to make ruby foldable? We need to find out a way to reduce the complexity to compute the line break opportunities.
Let’s have a separate meeting to discuss these ruby issues (kida)
todo
Kida to call a meeting to discuss remaining ruby issues

An update to the spacing_property document
Adding a character class that covers non-fullwidth spacing characters
PR is ready by Shimono-san
Kida to review
miscel. todo
Kida to setup a meeting with clreq re:default direction of web form elements in vertical text

The next meeting is 4/4 (was moved to 4/11)

//