On Wed, Jul 10, 2019 at 1:21 AM Philippe Verdy via Unicode <unicode@unicode.org> 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. > > I think we can attribute these bugs
What bugs? I asked for an example, you haven't provided, yet you blame others without even considering that you might be doing or expecting something wrong. So I'm asking again. Please show us an example along the lines of: "I'm using the FooBar software, version 1.2.3, this and that particular field. I enter a data, the hexdump of that data is included here. I expect it to render as 123, instead it renders as 321." I don't find it a nice attitude to blame others without having a thorough understanding of the situation, without having firm reasons to suspect the problem elsewhere rather than in your expectations. And if a renderer is incorrect (which is not impossible, but maybe a bit early to claim), you just have to ditch it and replace with a correct one. Or, well, maybe your goal is to locate a set of faulty renderers, locate and understand their exact bugs, and find a workaround, i.e. a Unicode representation of numbers in RTL context with narrow spaces which is immune to those bugs? Not sure if any of us here are eager to help with that, I'm not, sorry. Not sure if it's possible at all (if there are really such bugs), probably not, given your further constraints such as not using BiDi control chars. egmont