Hi Philippe, What do you mean U+202F doesn't work fo you?
Whereas the logical string "hebrew 123<space>456 hebrew" indeed shows the number incorrectly as "456 123", it's not the case with U+202F instead of space, then the number shows up as "123 456" as expected. I think you need to pick a character whose BiDi class is "Common Number Separator", see e.g. https://www.compart.com/en/unicode/bidiclass/CS for a list of such characters including U+00A0 no-break space and U+202F narrow no-break space. This suggests to me that U+202F is a correct choice if you need the look of a narrow space. Another possibility is to embed the number in a LRI...PDI block, as e.g. https://unicode.org/cldr/utility/bidic.jsp does with the "1–3%" fragment of its default example. cheers, egmont On Tue, Jul 9, 2019 at 9:01 PM Philippe Verdy via Unicode <unicode@unicode.org> wrote: > > Is there a narrow space usable as a numeric group separator, and that also > has the same bidi property as digits (i.e. neutral outside the span of digits > and separators, but inheriting the implied directionality of the previous > digit) ? > > I can't find a way to use narrow spaces instead of punctuation signs (dot or > comma) for example in Arabic/Hebrew, for example to present tabular numeric > data in a really language-neutral way. In Arabic/Hebrew we need to use > punctuations as group separators because spaces don't work (not even the > narrow non-breaking space U+202F used in French and recommended in ISO), but > then these punctuation separators are interpreted differently (notably > between French and English where the interpretation dot and comma are swapped) > > Note that: > - the "figure space" is not suitable (as it has the same width as digits and > is used as a "filler" in tabular data; but it also does not have the correct > bidi behavior, as it does not have the same bidi properties as digits). > - the "thin space" is not suitable (it is breakable) > - the "narrow non-breaking space" U+202F (used in French and currently in > ISO) is not suitable, or may be I'm wrong and its presence is still neutral > between groups of digits where it inherits the properties of the previous > digit, but still does not enforces the bidi direction of the whole span of > digits. > > Can you point me if U+202F is really suitable ? I made some tests with > various text renderers, and some of them "break" the group of digits by > reordering these groups, changing completely the rendered value (units become > thousands or more, and thousands become units...). But may be these are bugs > in renderers. >
