This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Locales: Use CLDR matching thousands separator
- From: Marko Myllynen <myllynen at redhat dot com>
- To: Carlos O'Donell <carlos at redhat dot com>, Florian Weimer <fw at deneb dot enyo dot de>
- Cc: Rafal Luzynski <digitalfreak at lingonborough dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Tue, 9 Oct 2018 11:38:52 +0300
- Subject: Re: [PATCH] Locales: Use CLDR matching thousands separator
- References: <eb1814b5-cae3-8472-ece6-44bec12d570b@redhat.com> <a2a29fbe-6872-c123-d4d0-2b8664825e72@redhat.com> <1786676151.161483.1534532463077@poczta.nazwa.pl> <9848a4de-2b6e-895b-d601-1358b79ef9f9@redhat.com> <414408229.228264.1534887501434@poczta.nazwa.pl> <349a70bd-92ba-e32f-e396-e4e595994029@redhat.com> <8736tgz2yb.fsf@mid.deneb.enyo.de> <1b30c4b8-6abe-df7c-07eb-2493e6759376@redhat.com>
- Reply-to: Marko Myllynen <myllynen at redhat dot com>
Hi,
On 2018-10-08 21:55, Carlos O'Donell wrote:
> On 10/8/18 2:51 PM, Florian Weimer wrote:
>> * Marko Myllynen:
>>
>>> One perhaps related thing I noticed recently was that neither U+00A0 or
>>> U+202F are classified as whitespace characters. locales/i18n_ctype has
>>> this definition (based on ISO/IEC 30112, see
>>> http://www.open-std.org/jtc1/sc35/wg5/docs/30112d10.pdf document page 30):
>>>
>>> space /
>>> <U0009>..<U000D>;<U0020>;<U1680>;<U2000>..<U2006>;<U2008>..<U200A>;/
>>> <U2028>..<U2029>;<U205F>;<U3000>
>>>
>>> Looking at pages about whitespace characters
>>> (https://en.wikipedia.org/wiki/Whitespace_character) and Unicode spaces
>>> (http://jkorpela.fi/chars/spaces.html) it seems that a couple of other
>>> Unicode space characters are also omitted from that list.
>>>
>>> Does anyone know is there a particular reason to omit U+00A0 and U+202F
>>> and few others from the above classification?
>>
>> I think it is deliberate to get the right behavior from line-breaking
>> algorithms.
>
> I forgot we implement unicode_utils.py...
>
> 317 def is_space(code_point):
> 318 '''Checks whether the character with this code point is a space'''
> 319 # Don’t make U+00A0 a space. Non-breaking space means that all programs
> 320 # should treat it like a punctuation character, not like a space.
>
> And the properties support this:
>
> DerivedCoreProperties.txt:00A0 ; Grapheme_Base # Zs NO-BREAK SPACE
> EastAsianWidth.txt:00A0;N # Zs NO-BREAK SPACE
> PropList.txt:00A0 ; White_Space # Zs NO-BREAK SPACE
> UnicodeData.txt:00A0;NO-BREAK SPACE;Zs;0;CS;<noBreak> 0020;;;;N;NON-BREAKING SPACE;;;;
> UnicodeData.txt:100A0;LINEAR B IDEOGRAM B151 HORN;Lo;0;L;;;;;N;;;;;
Thanks, so the above conforms to ISO/IEC 30112 and is deliberately
omitting no-break spaces, at least for line-breaking algorithms.
I wonder would it make sense to consider an addition to provide a
function that would recognize non-breaking spaces, to allow applications
to detect something like "123 456" as a single number, regardless of the
exact variant of no-break space used in between.
I'm not sure on what level such an addition should ideally be done
(standards, GNU/glibc, a higher-level library, perhaps something else),
so I won't start championing such a change further.
Thanks,
--
Marko Myllynen