- From: Yasuo Kida （木田泰夫） via GitHub <sysbot+gh@w3.org>
- Date: Thu, 29 Oct 2020 13:04:56 +0000
- To: public-i18n-archive@w3.org
Eric, thank you very much for your proposal. I have several comments / questions regarding your proposal. I would greatly appreciate it if you could clarify. >grapheme cluster vs grapheme cluster occurence What is a difference between A and A occurence in this context? (may be this is simply a novice English question) >it distinguishes the class used in horizontal and in vertical texts What is the benefit of having different classes between horizontal and vertical? I would appreciate it if you could elaborate here a bit. >The locale method has the downside that authors are not always tagging their text appropriately (either not at all, or not carefully on punctuation). I could not figure out what “not carefully on punctuation” means… > but it also means that one can specify different glues for e.g. ideographic/inseparable_emDash and ideographic/inseparable_twoDotLeader, or specify different glues for inseparable_emDash/inseparable_twoDotLeader and inseparable_emDash/inseparable_ellipsis. I can see why separating each inseparable makes sense, because that way you can construct a state machine. Regarding your second reasoning, i.e. ability to define different glues, do you have concrete examples of why such ability is a good thing? > As noted earlier, markup should always be available to influence the determination of the glue. Thus there is no need for such a Unicode property to be perfect; it does however need to be easily accessible and fairly stable. I am not sure if I understood the discussion here. There will be systems / applications where such markup is not possible (due to limitation of the underlaying engine, or limitation of the UI), and if so, existence of a markup could not be the reason why the property does not need to be perfect. I am not necessarily saying it needs to be perfect, as it can’t be. >The classes are only one part of the final visual appearance: the glue settings also come into play, so it is worth discussing those a bit, as they may influence the design of the classes. Do you have examples of the glue design giving influence on the design of the character classes? >I think the best way forward is to recommend that for paragraphs using the spacing model discussed here, that glue be controlled by the spacing model (i.e. the mojikumi tables) and that text-indent be set to 0. Do you suggest that there will be a part of text where this model is applied and another part of text where it is not applied, instead of defining everything in one spacing model? If you have multiple models, especially in one document, it would become harder to for example set an uniform style, e.g. indentation. >Columns: I have not yet carefully looked at the character class assignments you proposed but how did you handle JLReq classes that are dependent on the layout, such as ruby base (cl-20, 21, 22, 23, 24, 25, 28, 29, 30)? >0x000021 | R | H | westernChar >0x000080 | R | H | V | unknown Is it correct to interpret that code points between 0x000021 and 0x000080 follow properties specified by 0x000021? Lastly it would be great if you could provide a cross reference between JLReq classes and classes in your proposal. Thank you! -- GitHub Notification of comment by kidayasuo Please view or discuss this issue at https://github.com/w3c/jlreq/issues/242#issuecomment-718738998 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 29 October 2020 13:04:59 UTC