- From: Eric Muller <emuller@amazon.com>
- Date: Fri, 30 Oct 2020 16:09:27 -0700
- To: <public-jlreq-admin@w3.org>
- CC: Stanton Marcum <stantonm@amazon.com>
Done. Thanks for considering the contribution and helping with the translation. Eric. On 10/29/20 6:08 AM, 木田泰夫 wrote: > Hello Eric, > > Thank you very much (again) for sending the proposal. Finally I am > done translating it and sent it to the Japanese list. I also created a > github issue to track discussions. > https://github.com/w3c/jlreq/issues/242 > <https://github.com/w3c/jlreq/issues/242> > > I put my comments and questions to the github issue. I would > appreciate if it you could look at it. In case you do not have an > immediate access to w3c github, I pasted the same text below. > > Thank you! > > - kida > >> 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. >>
Received on Friday, 30 October 2020 23:09:51 UTC