Kenneth Whistler wrote: > I do not feel that this is an *encoding* issue at all. Nor is it even > an issue for the Unicode Collation Algorithm to define such a usage. Strictly speaking, this may be true. But the catch 22 of it is that Unicode 'rules' will prevent such characters from being defined until they are proven to be in use. But then again, nobody can use them, unless their behavior is defined...
> > What you are looking for is something that could be agreed upon by > the programming language communities as: > > 1. a symbol, from among the vast collection already encoded in > Unicode, that would be agreed to by the programming language > communities as acceptable in identifiers, as is "_". Of course there is a variety of definitions of which characters are allowed for identifiers. Some may restrict identifiers to alpha characters found in 7 bit ASCII, and there is nothing that can be squeezed in there. I believe that it would suffice if this character would be an alpha character, treated same as any 'letter' of any script. And yes, this makes my previous suggestion of having such a character in the General Punctuation block a bad idea. With identifiers, I meant a generic identifier, including uses like user names, file names and so on. For filenames (which, generally, already accept even most of punctuation) no further agreement or acceptance would be needed. If collation ensures that a character is sorted last, it can be used as such immediately. > > 2. when using a simple, single-level ordering (e.g., for > sorting menu-items), would be given a primary weight above > all alphas, as "_" would be given a primary weight below > all alphas. > > 3. when using a multi-level, sophisticated ordering according > to the UCA, would also be given a primary weight above all > alphas, as "_" would be given a primary weight below all > alphas, so as to preserve the expected behavior, while allowing > all the sophistication of language-specific ordering behavior > for sorting lists. Not just above all alphas, also above (/after) all other characters/codepoints (including punctuation and undefined codepoints. If the latter have a primary weight of FF80, then the proposed character(s) would need to have a primary weight higher than that. FFFF seems in order, though a slightly lower value (FFF0?) would allow some room if something arises in the future. > > In either case, whether doing simple sorting or complex, multi-level > sorting, you are talking about some tailored behavior here. You > can't just sort on code point order, and you cannot simply use the > Unicode Collation Algorithm without tailoring to get the effects you > want. My original proposal of adding a new character as codepoint U+FFF0 was intended to give this character a very good sorting behavior even when based on code point order. This would meet the requirements only if a codepoint in the Specials block can be defined to be an alpha character. U+10FFF0 (or U+10FFFC) would behave even better, but maybe other benefits of having it as U+FFF0 would override the slight advantage that U+10FFFx would have in raw sort order. I understand that underscore does not meet the requirements as the "last character"'s counterpart. Another new character (the "first character") would complicate things further, since a codepoint that would sort well in "raw sort mode" is not available. Which however does not mean that a "first character" (for example with codepoint U+FFF1) would be useless. Oh well, again, I need to change my proposal, to: U+FFF4 - "first character" [sorted _second_] U+FFF5 - "last character" [default primary weight FFF7?] U+FFF6 - "application specific first character" [sorted _first_] U+FFF7 - "application specific last character" [default primary weight FFF7?] U+FFF8 (still unassigned). Only U+FFF4 and U+FFF5 need a rendering, while U+FFF6 and U+FFF7 might be zero-width non-breaking spaces. U+FFF4 - rendered as top left corner (U+231C) U+FFF5 - rendered as bottom left corner (U+231E) Perhaps rather as full size, not quarter size. Which however does NOT mean that those symbols would be given this role. There is controversy as to what application's internal use is. For example, a database could use these characters for its internal use, meaning, they would no longer be available for "internal use" of a developer using this database. Perhaps database should use U+10FFFF, developer (API user) should use U+FFF7 and end user would use U+FFF5. > > By the way, my suggestion for an appropriate, already encoded symbol > to meet your requirements would be U+221E INFINITY. ;-) Or how about > U+261F WHITE DOWN POINTING INDEX, if you want something more iconic? IMHO, changing the collation order of any existing codepoint, especially if it appears in a larger group, is not a good idea. I understand why experienced unicoders feel very strongly about proposals for new characters. But then again, if no character had this specific role before, why would one get it now? A role that has never existed before should in my opinion be assigned a new codepoint. I see its rendering as secondary and it is not the rendering that justifies a new codepoint, it is the role. Lars Kristan
