> Well my first feeling was that U+202F should work all the time, but I
> found cases where this is not always the case. So this must be bugs in
> those renderers.
>
I think we can attribute these bugs to the fact that this character is
insufficiently known, and not even accessible in most input
On Tue, Jul 9, 2019 at 10:43 PM Philippe Verdy wrote:
>
> Well my first feeling was that U+202F should work all the time, but I found
> cases where this is not always the case. So this must be bugs in those
> renderers.
Could you share some concrete examples?
Well my first feeling was that U+202F should work all the time, but I found
cases where this is not always the case. So this must be bugs in those
renderers.
And using Bidi controls (LRI/BDI) is absolutely not an option. These
controls are only intended to be used in pure plain-text files that
Hi Philippe,
What do you mean U+202F doesn't work fo you?
Whereas the logical string "hebrew 123456 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
> Date: Tue, 9 Jul 2019 20:59:15 +0200
> From: Philippe Verdy via Unicode
>
> 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
>
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
6 matches
Mail list logo
