- From: Fuqiao Xue <xfq@w3.org>
- Date: Fri, 07 Apr 2023 09:23:42 +0800
- To: Martin J. Dürst <duerst@it.aoyama.ac.jp>
- Cc: 木田泰夫 <kida@mac.com>, JLReq TF 日本語 <public-i18n-japanese@w3.org>
Hi Martin, If my understanding is correct, it should be the library mentioned in this email: https://lists.w3.org/Archives/Public/public-i18n-japanese/2023JanMar/0022.html ~xfq On 2023-04-07 07:26, Martin J. Dürst wrote: > Many thanks for these very interesting minutes. > > It would be nice to have a pointer to the demo that Murata-san > introduced. > > Regards, Martin. > > On 2023-04-06 11:47, 木田泰夫 wrote: >> 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) >> >> // >> >>
Received on Friday, 7 April 2023 01:23:47 UTC