L2/03-248 Subject: Cumulative comments on Public Review Issues Date: August 12, 2003 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Date/Time: Tue Jun 24 17:48:55 EDT 2003 Contact: phoffman@imc.org Report Type: Public Review Issue In Public Review Issue #10, you suggest re-classifying three characters from being Control Characters. In RFC 3454, we list these as Control Characters. The IETF did not expect TUC to re-classify these. If this proposal goes through, we will be forced to re-issue RFC 3454 with a new description in section 5.2. This is not fun. -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Date/Time: Fri Jun 27 17:15:04 EDT 2003 Contact: verdy_p@wanadoo.fr Report Type: Public Review Issue > Issue #11 Soft Dotted Property Interesting issue for the Latin Small "ij" Ligature (U+0133): Normally the Soft_Dotted issupposed to make disappear one dot when there's and additional diacritic above, but many applications may keep these two dots above, fitting the diacritic in the middle. This proposal would mean that this become illegal, and it promote the use of an additional intermediate dot-above diacritic if the dot must be kept. What would be the interpretation of this dot added on top of the ligature? Should it be still a single dot centered above the "ij" digraph, requiring two dots to be encoded if both "i" and "j" must have their own dot above? or would this require using a diaeresis instead centered above the digraph? This "ij" ligature (or digraph) requires a more complete specification in the proposal... For the modifier letter j or Greek letter yot, this is less ambiguous. The proposal however is fine for the mathematical variants of i and j, (including the double struck italic, for unification reasons) -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Date/Time: Sat Jul 26 08:04:52 EDT 2003 Contact: peter.r.kirk@ntlworld.com Report Type: Public Review Issue My response to Public Review Issue #12 Terminal Punctuation Characters I was surprised to see U+05C3 # HEBREW PUNCTUATION SOF PASUQ listed as neither Terminal_Punctuation nor Sentence_Terminal. A major use of this character is to indicate the end of a verse in the Hebrew Bible (although it is missing from the end of a few verses). It is also used as the equivalent of a full stop in other Hebrew writings such as prayer books. It is certainly used only at the end of a word, and so should surely be classed as Terminal_Punctuation. Within the Hebrew Bible text, which does not use full stop or any other sentence terminating punctuation, the only real analogue of a sentence is a verse. When U+05C3 is used in other contexts it is equivalent to a full stop. So it would be sensible to class U+05C3 also as Sentence_Terminal. U+05C0 # HEBREW PUNCTUATION PASEQ is also used only at the ends of words, although it does not mark a major break. It should probably be classed as Terminal_Punctuation. U+05BE # HEBREW PUNCTUATION MAQAF is also often considered to be a word divider and so might also be classed as Terminal_Punctuation. Its usage is analogous to that of hyphen, which I was surprised to see not listed as any kind of punctuation. U+05BE should also be listed in UAX#14 as a "break opportunity after" along with U+2010, as line breaks commonly occur after U+05BE in printed pointed Hebrew texts. -- Peter Kirk peter.r.kirk@ntlworld.com http://web.onetel.net.uk/~peterkirk/ -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Date/Time: Mon Aug 11 16:33:48 EDT 2003 Contact: duerst@w3.org Report Type: Public Review Issue This is a comment on behalf of the W3C I18N Working Group (Core Task Force) regarding public review issue 9, Bengali Reph and Ya-Phalaa. We have looked at this proposal and have found no objection to this proposal. Regards, Martin. -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Date/Time: Mon Aug 11 16:38:53 EDT 2003 Contact: duerst@w3.org Report Type: Public Review Issue This is a comment on behalf of the W3C I18N Working Group (Core Task Force) regarding public review issue 10, Interlinear Annotation Characters. We have looked at this issue. We note that for the Web (HTML, XML, XHTML,...), markup instead of such characters should be used, so that we are only marginally concerned about this issue. On balance, we think that it is better to not allow these codepoints to be totally ignored, because this can lead to complete inversion of the meaning of some text. There should be no fixed convention as to how to display these characters; displaying them as boxes or question marks similar to other unknown characters should be enough. Regards, Martin. -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Date/Time: Mon Aug 11 16:39:53 EDT 2003 Contact: duerst@w3.org Report Type: Public Review Issue This is a comment on behalf of the W3C I18N Working Group (Core Task Force) regarding public review issue 11, Soft-Dotted Property. We have looked at this proposal and have found no objection to this proposal. Regards, Martin. -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --