Proposing new arrow characters with Bidi_Mirrored=Yes

[Nitai Sasson]

On 09/04/2025 7:30, Peter Constable via Unicode wrote:
> If static UI resources, then rather than coming up with some abstracted representation or considering some convoluted control mechanism, why not just provide an annotation on the resource to explain the intent and requirement for the localizer?

In the scenarios I'm describing, "the localizer" *is the Unicode BiDi algorithm*. This annotation is exactly what I'm after.

> But in any case, as Markus stated, “Encoding characters that look the same but behave differently is a bad idea.”

Which is why I think this would be better served by control/modifier characters, as Mark suggested. The title of this thread is no longer accurate.

> In other words, simply saying, “This would be useful for internationalization” is overly simplifying, and more analysis of a scenario is needed to determine the best solution.

I think I've analyzed the scenario plenty, but please, go ahead and do so from your perspective. I'll repeat the links from before:

https://github.com/deevroman/better-osm-org/issues/241 - solved by bidi-isolating both sides of the arrow, and programmatically selecting the correct arrow based on the layout direction
https://github.com/OSMCha/osmcha-frontend/issues/765 - solved by bidi-isolating both sides of the arrow, and relying on the fact that the interface is always LTR
https://meta.discourse.org/t/wrong-arrow-direction-in-rtl-text-contexts/360760 - which I've already mentioned, **no simple way to solve it** without mirroring arrows!

On 09/04/2025 1:30, Markus Scherer via Unicode wrote:
> On Tue, Apr 8, 2025 at 3:05 PM Nitai Sasson via Unicode <unicode at corp.unicode.org> wrote:
> > I just had a thought. Would it make sense to prescribe the Variation Selectors to do this?
>
> I think that would be absolutely terrible.
Variation selectors are a "pretty please" request to select a specific glyph, if that's available.
> So you get an arrow pointing one way on a system that has a ligature-type mapping in its font, and an arrow pointing the opposite way on a system that doesn't.

Okay. If Variation Selectors are a bad fit for this kind of behavior modifier, then it's a bad idea. I think that email is still useful in that it lists the potential new control characters being proposed, just replace "VS7" with "New Control Character 1" etc.

> I think the right way to deal with this in something like directions ("go from A --> B") is to use a placeholder for the arrow, as well as for the A and B, and populate the arrow placeholder with the one that points "forward" according to the directionality of the text box = the directionality of the UI language.

The needed direction for the arrow in these cases can only be determined by the Unicode BiDi algorithm, and is impossible to determine ahead of time. In many environments - I dare say, most - the BiDi algorithm only runs after the string has left the programmer's hands, just before rendering. It's not technically feasible to make the substitution at this time.

Or phrased another way: the best mechanism to make the correct substitution is the BiDi algorithm, using the exact same logic as used for Greater Than ">". You haven't given a reason why this mechanism is appropriate for > but inappropriate for →.

- Nitai
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://corp.unicode.org/pipermail/unicode/attachments/20250409/6442a45b/attachment-0001.htm>