This page is a compilation of formal public feedback received so far. See Feedback for further information on this issue, how to discuss it, and how to provide feedback.
Date/Time: Thu April 10 10:08:48 CDT 2025
ReportID: ID20250410100848
Name: Peter Constable
Report Type: Public Review Issue
Opt Subject: 510
The title of the document is "East Asian Spacing", not "East Asian Spacing Property", which is fitting because the document includes definition of that property as well as of an algorithm that uses it. However, the text in certain parts of the document is worded in a way that seems to assume the one property is the only thing the entire document describes. For example, section 2, Conformance, begins, "The property defined in this report is informative." It doesn't explicitly mention the algorithm. Also, section 4, Data File, begins, "This property..." Again, that seems to imply that the entire document is about a single property. Potentially, in the future, the document could be extended such that more than one property is defined. The wording "this property" occurs in three places in the document: - In section 3, in a review note: that doesn't need to be changed. - In section 3.3, paragraph 2: "This property doesn't define the exact amount". That should probably say, "This algorithm..." - In section 4, first paragraph: I'd change "This property" to "The East_Asian_Spacing property". There's at least one use of "the property" that should probably change: I think the section heading "Scope of the Property" should be "Scope of the Algorithm". A couple of other organizational changes I'd suggest for the doc: - The algorithm is defined in section 3.3, which is a subsection of 3 The East_Asian_Spacing Property. I'd move discussion of the algorithm in 3.3 and 3.4 into a separate level 1 section. - Section 4, Data File, contains a description of how property values are derived. That should be moved into section 3, the description of the East_Asian_Spacing property. Section 4 should be limited to describing the file---the name of the file, location, format ... See the Data File(s) section in several other UTSes/UAXes for comparison.
Feedback above this line has already been reviewed during UTC #183 in April, 2025.
Date/Time: Wed June 04 17:14:21 PDT 2025
ReportID: ID20250614171421
Name: Allen Watkins Smith
Report Type: Public Review Issue
Opt Subject: Proposed Draft UTR #59, East Asian Spacing
1: A paragraph like the one at the end of section 1 in UAX #11 (East Asian Width), noting that the new property almost certainly does not preserve canonical equivalence (due to the use of East_Asian_Width in deriving property values for it), is probably needed. (I don't know how being "informative" versus East_Asian_Width's "normative" will affect the necessity for this.) 3.4.3: 3rd paragraph: Does typography professionally used for East Asian scripts use parentheses to highlight - as in to emphasize or make stand out from the rest of the text - words? If so, "parentheses do." → "parentheses do in typographic practice for East Asian scripts." or "parentheses do in typographic practice for some East Asian scripts." If not, then "parentheses do" → "underlining or bold-facing does". (Please add or substitute any common or otherwise well-known means of emphasis used in practice with East Asian scripts. There is at least one interlinear annotation method used for emphasis in Japanese writing, if I recall correctly, and I've seen underlining - and, at least with hand-drawn characters, what might be called bold-facing - used with East Asian scripts, but I have no idea how common, well-known, or formally acceptable any particular method is.) 3.4.4: Unless I completely misunderstand it, Tr would not cause a character to be displayed upright (as in similar to or in the same way as in horizontal text). If Tr being treated in the auto-spacing algorithm as if displayed upright is what is meant, why? 4.1.1: "scripts." → "scripts, or if all Script_Extensions scripts are East Asian scripts." (Some characters have a Script of Common or Inherited but a geographically or otherwise restricted set of Script_Extensions scripts listed, being customarily used only in those scripts.) 4.2.1A: From the examples given, other characters frequently found around numbers should also be included; for instance, one example is "$20", but $ has a General_Category property of "Currency_Symbol (Sc)", not "Other_Punctuation (Po)". I suggest adding a rule of '"Include if the Line_Break property is "Postfix_Numeric (PO)" or "Prefix_Numeric (PR)".' As well as some other number-associated code points, this will take in all currency symbols - unless excluded by a later rule (such as for East_Asian_Width) - including the entire Currency_Symbols block. Copyediting (I may do some more later if it's needed/wanted): 3.4.2: 2nd paragraph: "such as plain text files" → "such as in plain text files" 4th paragraph: "the code point to where the algorithm doesn't insert" → "this code point where the algorithm fails to insert" 5th paragraph: "SPACE to where the algorithm inserts" → "SPACE where the algorithm mistakenly inserts" 3.4.3: 1st paragraph: "characters insert" → "characters cause the insertion of" 2nd paragraph: "to both sides of them, considering that not doing so look unbalanced." → "to both sides of the word, from the viewpoint that not doing so looks unbalanced." 3rd paragraph: "and numeral digits, rather" → "and digits, rather"