L2/16-176 Title: Suggested Disposition of Further Beta Feedback in PRI #297 Author: Ken Whistler, Chair, Editorial Committee Date: June 15, 2016 Status: For Consideration by the UTC Background I was assigned action item 143-A064 to analyze Asmus Freytag's feedback of May 4, 2015 on PRI #297 (and come up with actionable suggestions). Asmus' feedback was a series of quick suggestions based on review of the voluminous feedback by Marcel Schneider on PRI #297. Instead of just culling what I think might be a few actionable suggestions, in this document I walk through all of the feedback from Marcel Schneider in more detail, taking into account Asmus' suggestions, so we have a more complete record of disposition of that collection of feedback. For a few of the items I suggest further action by the editorial committee, which will be taken up separately. Note that the vast majority of the feedback by Marcel Schneider was not actually specific to the beta review of Unicode 8.0 itself. Most of it is general feedback on the code charts, names list, and/or core specification text or structure. As such, disposition of this feedback was not critically timed to the release of the Unicode 8.0 or 9.0 data files. In the listing below, I walk through the feedback, identifying each by its submission time stamp, and then giving lettered subsections in the case of feedback with multiple different topics in a single submission, so the topic in question can be given a quick summary and a corresponding recommended action (or no action, as the case may be). Disposition Summary ====================================================================== 1. 3/25 12:52 a. Problem with bidi_mirroring value of U+226D. This feedback has subsequently been separately submitted, and will be taken up again by the UTC. I have provided a separate extended analysis of the problem. b. Suggest display of bidi-mirrored glyphs in code charts. No. This is not feasible with the current tooling. Asmus has suggestion there is the possibility of introducing *some* limited display of alternative glyphs, including unusual bidi-mirrored forms, but IMO, this would be an inappropriate use of the code charts and should instead be addressed by a more focused document, if so desired. Separately, Asmus has suggested that one could consider adding notes at the block level regarding mirroring behavior for arrows and mathematical symbols. I will take that suggestion up with the editorial committee. ====================================================================== 2. 3/25 12:54 a. Suggested removal of "idle '@+" lines in names list. No. This reflected a misunderstanding of the relevant syntax usage by unibook for the names list. (Asmus concurs.) b. Suggested conversion of bullet notice_line's into comment_line's. No. This reflected a misunderstanding of the relevant syntax usage by unibook for the names list. (Asmus concurs.) ====================================================================== 3. 4/1 9:43 a. A series of suggestions for bookmarks for the code charts. No. This is not feasible with the current tooling. (Asmus concurs.) ====================================================================== 4. 4/11 9:09 a. Suggestion to use 3rd-level section numbering in the core specification. This has already been considered by the editorial committee. It definitely will not happen for Unicode 9.0. It might be considered again for later versions, but actually makes text maintenance for the standard *more* complicated than it already is. (Asmus wrote in favor of this suggestion.) b. Suggestion to make detailed section level cross-references in the names list to sections in the core specification, annexes, etc. No. This is a complicated maintenance issue for the names list, because none of this could be automatically maintained by the tooling. The potential for the introduction of stale cross references and other errors is too great. ====================================================================== 5. 4/13 10:05:09 a. Suggestion to introduce a complete set of bidi-mirrored code charts. No. This is not feasible with the current tooling. It is also completely unclear what the specification for this would be, or the target audience. It seems unnecessary over-engineering of an issue that could be addressed on a much more focused basis. ====================================================================== 6. 4/13 10:05:31 a. Suggestion to add an extended version of UnicodeData.txt. No. The function of this is covered by UCD in XML. (Asmus concurs.) b. Observation that although the UTC recommends against machine parsing of the NamesList.txt file for extracting data, that that is nevertheless done by "keyboard creating software", and that "often no notice is taken of the FormalAliases". Noted. If software parses the NamesList.txt file, despite warnings, and then neglects the formal aliases, which *are* listed in the NamesList.txt file, there is nothing much we can do about that. ====================================================================== 7. 4/13 10:07:22 a. Suggested text changes in Section 6.2 of core specification regarding apostrophe. These can be taken up by the editorial committee. ====================================================================== 8. 4/13 10:07:49 a. Suggested text changes in Section 6.2 of core specification regarding fraction slash. No. These text changes are an attempt to change the behavior of the fraction slash (to make it work with superscript and subscript digits), as well as to introduce input method behavior. Neither is editorial in nature. Anything along these lines would have to be taken up as a separate proposal to the UTC. ====================================================================== 9. 4/14 8:14:20 a. Suggested text change in Section 6.2 of core specification regarding quotation marks and brackets. This can be taken up by the editorial committee. ====================================================================== 10. 4/14 8:15:17 a. Suggested text changes in Section 6.2 of core specification regarding language-based usage of quotation marks. These can be taken up by the editorial committee. ====================================================================== 11. 4/14 8:17:32 a. Suggested annotation changes for U+0022 and U+0027 in names list. These particular annotation suggestions are attempting to deal with details that are more fully addressed in the core specification text about quotation marks. No changes to the names list are warranted here. ====================================================================== 12. 4/15 10:55:39 a. Suggested annotation changes for U+05F3 and U+05F4 in names list. These particular annotation suggestions are not needed in the names list at this point. A clarification in Section 9.1, Hebrew might be helpful, and could be taken up by the editorial committee. ====================================================================== 13. 4/17 11:45:39 a. Discussion about text regarding dashes and hyphens. There isn't specific-enough information here to act on for the core specification text. ====================================================================== 14. 4/17 12:16:45 a. Complaint about immutability of character names. Not actionable. b. Suggestion to overhaul the stability policy regarding character names. Not actionable. ====================================================================== 15. 4/20 03:02:12 a. Suggestion to replace "Spanish" with "Castilian" in annotation for U+00BF and U+00A1. No. This suggestion is incorrectly restrictive about the use of these punctuation marks. ====================================================================== 16. 4/20 03:08:15 a. Suggestions regarding case-related annotations for eth and d with stroke. The suggested fix for the case-pair annotation for 00F0/00D0 has already been implemented in the names list. The suggested addition of a case-pair annotation for 0110/0111 is not needed, as the pair is adjacent in the chart. ====================================================================== 17. 4/20 03:09:02 a. Suggestion to add a large number of formal aliases for characters which are bidi-mirrored and have "left" "right" in their names. Also for various quotation marks. Such suggestions would need to be made explicitly to the UTC in detail, but it is very unlikely that the UTC would be interested in upending the name conventions for brackets or quotation marks. b. Suggestion that annotation should be added that indicates if a formal alias exists, the name should be discarded and the formal alias be used, instead. Other suggestions regarding restructing the names list to switch code name and formal alias. Not actionable. ====================================================================== 18. 4/20 03:09:33 a. Suggested names list annotation changes for 002D. The specific suggestion regarding the alias line does not improve the names list or the identification of the character. The suggested addition of an annotation indicating preference for 2212 for minus sign may not be correct in many instances -- particularly in formal syntaxes. This is not parallel to the annotation of 0027, and is best handled instead by discursive text in the core specification. ====================================================================== 19. 4/20 03:10:12 a. Extensive suggestions for annotation changes and xrefs for characters that are used as numeric separators: 0027, 002C, 002E, 2019, etc. This level of annotation is inappropriate for these characters, which have many, many functions. This belongs instead in a dedicated discussion about formatting of numbers. b. Suggested additional text regarding numeric separators for Section 6.2 of the core specification. This can be taken up by the editorial committee ====================================================================== 20. 4/20 11:06:54 a. Suggestion to add formal aliases for 0598 ZARQA and 05AE ZINOR. This suggestion cannot be acted on editorially. In any case, it is unlikely that the UTC would approve a formal a proposal to this effect, as it would not materially improve the identification of the characters involved. The existing aliases and annotations suffice. ====================================================================== 21. 4/20 11:13:36 a. Suggestion that the names "SHARP S" for 00DF/1E9E are erroneous, and that formal aliases and other associated annotations be added. UTC action would be required to add formal aliases. In this case, formal aliases would not be helpful, and the annotation changes would then be moot. ====================================================================== 22. 4/20 11:15:57 a. Suggestion to replace the xrefs for 00FF / 0178 in the names list with explicit uppercase and lowercase annotations. This is a good suggestion that makes the casing annotations more consistent in the names list. It will be implemented in the 9.0 names list. ====================================================================== 23. 4/21 10:16:42 a. Suggestion to update version note on aliases for 00C6 / 00E6 from "1.0" to "1.1" This is a good suggestion, which correctly identifies the version of these "ligature" alias names from Unicode 1.1. It will be implemented in the 9.0 names list. ====================================================================== 24. 4/22 11:24:56 a. Suggestion to augment names list syntax by adding CODENAME_LINE to the formal syntax in NamesList.html. No. The intent of this addition is not clear or fully specified, although it apparently has to do with the suggestions about correcting bad character names with many additions of formal aliases. In any case, a suggestion for addition to the names list syntax is not actionable without complete buy in by the maintainer of the Unibook tooling. ====================================================================== 25. 4/22 11:26:44 a. A suggestion to add an annotation for 2044 FRACTION SLASH about its use for composition of fractions with superscripts and subscripts. No. See #8 above. ====================================================================== 26. 4/24 11:50:51 a. A general complaint about the Unicode Standard not being sufficiently "user-centered" and not being willing to correct problems in its character names. Not actionable. ====================================================================== 27. 4/24 11:52:43 a. Note about a typo in notice for U+2446 Will be corrected in the names list for 9.0. b. A suggestion that more formal aliases should be added here for 2446 and 2447, as part of general complaint that there are not enough formal aliases to correct problems in the names. See above responses re suggestions to add formal aliases. ====================================================================== 28. 4/24 12:51:50 a. General comment about the need to have translations of the Unicode Standard. Congratulations about adding the cheese wedge (as "unbloody, no-slaughter food"). Noted. No action. ====================================================================== 29. 4/27 01:06:24 a. Corrections to feedback of 2/20. Reiteration of concern about character names with "LEFT" and "RIGHT" in their names. Noted. No action. ====================================================================== 30. 4/27 01:07:36 a. Suggestion to add formal alias "ARABIC VOWEL SIGN SUPERSCRIPT ALEF" for U+0670. Request to change subhead in names list to include "(vowel)" in its wording. See above responses re suggestions to add formal aliases. In this particular case I don't think any such addition is needed for this character. There is an inconsistency in the subhead in the names list, however. Rather than change to match the Syriac code chart, the relevant section is the set of "points" in the range 064B..0652, whose subhead was earlier changed to "Tashkil", to match the core specification discussion. The subhead for 0670 will likewise be updated to match these. ====================================================================== 31. 4/27 01:18:22 a. Suggestions regarding formal aliases and other annotations for 047C and 047D. The suggestions for formal aliases in these cases (for "beautiful omega") are superfluous. Other suggestions for annotations are superseded by changes responsive to the expert feedback noted in L2/15-014. ====================================================================== 32. 4/27 01:09:11 a. Suggestions to add formal aliases for 309F HIRAGANA DIGRAPH YORI and 30FF KATAKANA DIGRAPH KOTO. See above responses re suggestions to add formal aliases. In this particular case I don't think such additions are needed for these characters. ====================================================================== 33. 4/27 01:10:17 a. Suggestion to add the Unicode 1.0 names as aliases for several spacing ASCII diacritics (005E, 0060), or to make then formal aliases. The decision to omit these particular Unicode 1.0 names in the names list was an editorial decision taken long ago, and does not need to be revisited. See above responses re suggestions to add formal aliases. ====================================================================== 34. 4/27 01:11:09 a. Suggestion that name of U+1D13A MUSICAL SYMBOL MULTI REST is a misnomer. Noted. No action. ====================================================================== 35. 4/27 01:11:42 a. Complaint about the spelling "LAMDA" used for many Greek characters in the standard, and request for multiple formal aliases. Noted. No action. ====================================================================== 36. 4/27 01:13:55 a. An extended proposal to change the syntax of CHAR_ENTRY in the names list to reorder the placement of formal aliases and character names. Detailed list of parts of the names list to be reordered, along with further suggested new formal aliases. This reordering of elements for the Unicode names list would be completely unacceptable to all parties, and very disruptive. See also the comments above to #24, regarding the absence of buy-in from the maintainer of the Unibook tooling. Furthermore, this proposal is basically more in service of an unnecessary highlighting of formal aliases in another attempt to address perceived problems in the character names. ====================================================================== 37. 4/27 09:30:46 a. Suggestion to make U+1F6D0 PLACE OF WORSHIP Bidi_Mirrored=Yes. Not actionable. This misunderstands the scope and function of bidi mirroring. See also #47 below. ====================================================================== 38. 4/27 09:32:25 a. Suggestion to change name of U+19B0 NEW TAI LUE VOWEL SIGN VOWEL SHORTENER to NEW TAI LUE VOWEL SHORTENER Not actionable. ====================================================================== 39. 4/27 09:34:24 a. Suggestion to add subhead "Sign" for U+11350 GRANTHA SIGN OM in names list. This was done in the 8.0 names list. ====================================================================== 40. 4/27 09:39:02 a. Another complaint about ISO requiring name stability and preventing the use of correct, accurate names, including those in cross-references to other characters in the names list. Noted. Not actionable. ====================================================================== 41. 4/27 09:45:20 a. Complaint about inconsistency in spelling of "center" and "centre", noting that the British "CENTRE" spelling is used in charcter names, but not in aliases and other annotations. The requirement for use of "CENTRE" in character names is a longstanding consensus agreement between the UTC and WG2. The requirements for hewing to British English spelling for some words in character names does not apply in general to other editorial content of the standard, including aliases and other annotations in the names list. ====================================================================== 42. 4/28 07:28:15 a. General comment about beta review feedback. Noted. Not actionable. ====================================================================== 43. 4/28 07:29:58 a. Suggestions for various possible name changes for Siddham section marks. Noted. Not actionable. ====================================================================== 44. 4/28 07:31:00 a. Suggestion to remove the default glyph icon for reserved code points in the names list section of the code charts and to change the hatching used for fill of reserved code points in the main charts. There is no consensus to remove these reserved glyph icons, which are of longstanding use in the names list. The Unibook tooling already has optimizations which remove redundant lists of long runs of reserved code points, by the way. As for the hatching design, it is possible that a different design might work, but this would require buy-in by the Unibook maintainer, and I see little benefit to be gained by changing it. ====================================================================== 45. 4/28 07:31:56 a. Suggestion to change the wording of the comment for U+A78F. This is a good editorial suggestion, and will be implemented in the 9.0 names list. b. Suggestion to correct "lower case" to "lowercase" in comment for U+A7B3. This is a good editorial suggestion, and will be implemented in the 9.0 names list. c. Suggestion to change the wording of notice at U+AB60. This suggestion does not improve the wording, in my opinion. No action. ====================================================================== 46. 4/28 07:32:39 a. Suggestion to add a cross-reference in the names list for half-titlo combining marks FE2E and FE2F. This is a good editorial suggestion, and will be implemented in the 9.0 names list. ====================================================================== 47. 4/28 12:31:42 a. Suggestion to make a large number of symbols and pictographs Bidi_Mirrored=Yes. Noted. Not actionable. This misunderstands the scope of bidi mirroring. ====================================================================== 48. 4/30 06:44:57 a. Further suggestions to correct "lower case" --> "lowercase" in annotations for 5 more characters. This is a good editorial suggestion, and will be implemented in the 9.0 names list. b. Suggestion to add formal alias for U+0F0A. See above responses re suggestions to add formal aliases. In this particular case I don't think any such addition is needed for this character. c. Suggestion that U+29A1 SPHERICAL ANGLE OPENING UP be changed to Bidi_Mirrored=No. This is indeed probably an error in the data, but would need to be separately taken up with the UTC with a proposal that would justify the need to change it. The change would have an impact on bidi behavior and tests. d. Suggestion to update UTN #27 with new name misnomers. This is not an issue for the UTC. I might review UTN #27, "Known Anomalies in Unicode Character Names" to see if any of these suggestions rise to the level to make it worth the effort to them to a new revision of UTN #27, but that review will need to wait until after the 9.0 release. e. Suggestion to update annotation for 00BC to note extended range of vulgar fractions encoded in the Number Forms block 2150..215E. This is a good editorial suggestion, and will be implemented in the 9.0 names list. f. Suggestion that note about the rendering of the fraction bar for vulgar fractions also be made for the fractions in the range 2150..215E. This is not necessary. The relevant information about rendering is covered in the core specification, and need not be duplicated here. However, there is a valid point about the replication of the annotation at 00BC..00BE, which could be cleaned up a bit. The annotations for 00BC..00BE will be modified for the 9.0 names list. g. Suggestion to add formal aliases without the word "VULGAR" for all the fraction characters. See above responses re suggestions to add formal aliases. In this particular case I don't think any such additions are needed for these characters. h. Revised suggestion to update names list with multiple new formal aliases added. And further discussion of suggested changes to names list syntax. Noted. Not actionable. ====================================================================== 49. 5/2 06:52:34 a. Corrected list of instances of "idle '@+'" lines in the names list. Noted. No action. See #2a above. ====================================================================== 50. 5/2 06:53:47 a. Suggested change to casing note for 026A. No. The suggested change is editorially unnecessary, and might even be misleading. ====================================================================== 51. 5/2 06:59:49 a. Suggested changes to case-related annotations for eth, d-bar, y-diaeresis, and sharp s. In my opinion, none of these particular suggestions is an improvement over the respective annotations already in the names list. No action. ====================================================================== 52. 5/2 07:03:05 a. Suggested addition of aliases involving alternate spelling of romanizations of Greek letters for lambda, mu, nu, and upsilon. No. These are not necessary for character identification here. Exhaustive listing of alternative romanizations is not editorially helpful in the names list. ====================================================================== 53. 5/2 07:10:09 a. Another suggestion to add a UnicodeXData.txt file with more property data in a comprehensive machine-readable format. No. This is redundant with UCD in XML. See #6a above. ====================================================================== 54. 5/4 07:53:08 a. Correction of suggestion for one character in an earlier piece of feedback. Noted. No action. ====================================================================== 55. 5/4 07:53:59 a. Suggestion, for consistency, to add a note about known misspelling of BSKA- in 0FD0. Noted. No action. In this case, the name defect is sufficiently addressed simply by have the formal alias directly listed as it is currently. b. Suggestion to add formal alias for romanization defect in 0A01. See above responses re suggestions to add formal aliases. In this particular case I don't think any such addition is needed for this character. c. Suggestion to add an annotation indicating that 0709 is a misnomer (in addition to the formal alias already present). This suggestion is o.k., and will be added to the 9.0 names list. d. Suggestion to add annotation that 0B83 is a misnomer. No. This is discussed in the core specification. A point annotation here might actually be problematical for this particular character. e. Suggested annotation updates for two Tibetan symbols used in Bhutan, 0F0A and 0FD0. These might make sense, but should be separated from the argumentation about formal aliases and misnomers, for separate consideration and feedback by experts on usage in Bhutan. No action for now. ====================================================================== 56. 5/4 07:54:57 a. Proposal for introducing a "Directionality Dynamics Property" to deal with the left/right facing of symbols and pictographs. This is out of scope for the beta feedback. The concern Marcel Schneider is raising here was later addressed in part in the discussion of a possible mechanism for controlling the facing direction of certain emoji. See PD-UTS #52, whose development has since been suspended. The more general part of this has to do with the facing direction for many non-emoji pictographs and for letters/syllables/logographs in pictographic and hieroglyphic scripts. That is generally treated as an issue for higher-level protocols and in this feedback is confused with bidi mirroring. In any case no action based specifically on this feedback. ====================================================================== 57. 5/5 05:10:30 a. A suggestion to redefine Formal Alias to exclude some of the types noted in NameAliases.txt. Not actionable. ====================================================================== 58. 5/6 08:03:04 a. After discovery of UCD in XML, a new set of suggestions to enhance the UCD by adding more attributes and values related to aliases and formal aliases. Not actionable. The current definition of the Name_Alias property is defined in the XML in Section 4.4.3 Name Aliass in UAX #42. Changes to that would require UTC decisions to modify and extend what the name aliases are for, and how they are documented. b. Suggestion to add for formal aliases for the Devanagari danda and double danda. See above responses re suggestions to add formal aliases. In this particular case I don't think any such additions are needed for these characters. ====================================================================== 59. 5/7 07:46:59 a. Revised suggestion to add for formal aliases for the Devanagari danda and double danda. See above responses re suggestions to add formal aliases. In this particular case I don't think any such additions are needed for these characters. b. Suggestions regarding revisions for casing of sharp s. Not actionable. c. Suggestion to enhance UCD in XML with character cross-references. Not actionable. This misunderstands the editorial nature of the cross-references. However, the documentation regarding the use of cross-reference will be improved in the Unicode 9.0 core specification. d. Request for an online version of the standard. Not actionable. e. Request to typeset character names in the standard in uppercase (instead of the current Minion smallcaps) to improve quotability. No. This is a longstanding convention used in the core specification for many years. ====================================================================== 60. 5/11 07:33:52 a. Note that some earlier feedback about GRANTHA OM was incorrect. Noted. No action. b. Discussion about reversed brackets and bidi mirroring. Noted. No action. c. Suggestion to possibly add a formal alias for U+002E FULL STOP See above responses re suggestions to add formal aliases. In this particular case I don't think any such addition is needed for this character. d. Retraction of part of earlier suggestion about changes to names list syntax. Noted. No action. e. Suggestion for alternate, general way to take account of "misnamed or ugly named characters". Noted. No action. f. Complaint about the font size inconsistency between digits and uppercase Latin letters in hex sequences used for code point in the code charts. Noted. No action. This is an idiosyncrasy of the particular font designs for fonts used in the code charts. g. Retraction of earlier suggestion for adding code points to PDF bookmarks. in the side pane. Noted. no action. h. Suggestion for a new UI for browsing the code charts by code points in the bookmarks side pane. Frankly, I don't understand what Marcel Schneider is requesting and suggesting here. And I don't see what value add there is over simply using the existing Code Charts index page. No action. ====================================================================== 61. 5/11 10:15:06 Duplicate of #59. No action. ====================================================================== 62. 5/11 10:17:07 Duplicate of #60. No action.