Re: 0027, 02BC, 2019, or a new character?

For the root zone may be, but not formally rejected by IDN, and the Kazakh
zone could accept it without problem. It also has the advantage of allowing
cleaner collation and contextual text extraction, and it also allows better
placement of the combining character with its base in some dedicated pairs
that will be suitable for Kazakh.
But technically it would have been preferable to use the acute accent.

Note that the acute accent is also looking much as apostrophes in Greek
with capitals, and still it is not rejected ! (of course in IDN, case does
not matter and there's a visual distinction in lowercase: but what would
prohibit Kazakh pairs to have similar dictinctions at least for lowercase
letters?).

I don't understand the rationale: a combining accent (acute above, comma
above, or comma above right) will always be better than the proposed reuse
of punctuation apostrophes, and its intended semantic for Kazakh is
certainly not a punctuation or elision mark, which will also occur in
borrowed foreign names really using elision apostrophes or trigrams, and
also not a separate modifier letter).

Sometimes I think we should also discuss about the Breton trigram "c'h"
which is not well represented with the legacy apostrophe, and a combining
acute above or comma above or above right would be better : Breton
keyboards or input methods can be improved to select the correct character
to encode).

2018-01-19 21:10 GMT+01:00 Asmus Freytag (c) <asmusf_at_ix.netcom.com>:

> On 1/19/2018 5:42 AM, Philippe Verdy wrote:
>
> Hmmm.... that character exists already at 0+0315 (a combining comma above
> right). It would work for the new Kazah orthographic system, including for
> collation purpose. I don't think IDN rejects this combining version.
>
>
> This is also ineligible for the Root Zone.
> A./
>
>
>
> 2018-01-19 14:37 GMT+01:00 Philippe Verdy <verdy_p_at_wanadoo.fr>:
>
>> May be the IDN could accept a new combining diacritic (sort of right-side
>> acute accent). After all the Kazakh intent is not to define a new separate
>> character but a modification of base letter to create a single letter in
>> their alphabet.
>> So a proposal for COMBINING APOSTROPHE (whose spacing non-combining
>> version is 02BC), so that SPACE+COMBINING APOSTROPHE will render exactly
>> like 02BC
>>
>> 2018-01-18 19:51 GMT+01:00 Asmus Freytag via Unicode <unicode_at_unicode.org
>> >:
>>
>>> Top level IDN domain names can not contain 02BC, nor 0027 or 2019.
>>>
>>> (RFC 6912 gives the rationale and RZ-LGR the implementation, see MSR-3
>>> <https://www.icann.org/public-comments/msr-3-2018-01-17-en>)
>>>
>>> A./
>>>
>>>
>>> On 1/18/2018 3:00 AM, Andre Schappo via Unicode wrote:
>>>
>>>
>>>
>>> On 18 Jan 2018, at 08:21, Andre Schappo via Unicode <unicode_at_unicode.org>
>>> wrote:
>>>
>>>
>>>
>>> On 16 Jan 2018, at 08:00, Richard Wordingham via Unicode <
>>> unicode_at_unicode.org> wrote:
>>>
>>> On Mon, 15 Jan 2018 20:16:21 -0800
>>> James Kass via Unicode <unicode_at_unicode.org> wrote:
>>>
>>> It will probably be the ASCII apostrophe. The stated intent favors
>>> the apostrophe over diacritics or special characters to ensure that
>>> the language can be input to computers with standard keyboards.
>>>
>>>
>>> Typing U+0027 into a word processor takes planning. Of the three, it
>>> should obviously be the modifier letter U+02BC, but I think what gets
>>> stored will be U+0027 or the single quotation mark U+2019.
>>>
>>> However, we shouldn't overlook the diacritic mark U+0315 COMBINING COMMA
>>> ABOVE RIGHT.
>>>
>>> Richard.
>>>
>>>
>>> I have just tested twitter hashtags and as one would expect, U+02BC does
>>> not break hashtags. See twitter.com/andreschappo/s
>>> tatus/953903964722024448
>>>
>>>
>>> ...and, just in case twitter.com/andreschappo/status/953944089896083456
>>> <https://twitter.com/andreschappo/status/953944089896083456>
>>>
>>> André Schappo
>>>
>>>
>>>
>>
>
>
Received on Fri Jan 19 2018 - 18:42:44 CST