Proposing new arrow characters with Bidi_Mirrored=Yes

[Mark E. Shoulson]

These really are two separate issues, and maybe it were best not to 
conflate or confuse them.

The "proposed solution", as I see it, is there is some character that 
attaches to the previous character (or probably the previous base 
character or grapheme cluster, if it comes to that), and flags it as 
subject to BiDi mirroring.  I imagine this wouldn't necessarily be 
available for EVERY SINGLE CHARACTER in Unicode; we don't need to make 
sure it's possible to write a mirror-reversed ネ or @ or whatever (I 
mean, unless we do need those), but presumably some selected list of 
characters, mainly arrows and things like directional math operators and 
possibly some directional emoji. This might be a good idea?  I don't 
know all the possible ramifications.  And I'm not even sure that 
considering it like a variation selector would be wrong.  If it isn't 
honored, what's the damage?  Possibly huge, since assigning אחת←שתיים is 
drastically different from אחת→שתיים (and אחת, not אחד, to at least be 
consistent, right?) but maybe that's acceptable anyway, if the author 
understands that going in.

I'm hearing a lot of knee-jerk opposition to this whole notion, and I 
don't think that's warranted.  We're being presented with actual 
use-cases and why this would be helpful.  Still "it would be nice if," 
but things that are nice enough graduate beyond that.

"Characters that look the same but act different are bad" is a point... 
but then "(" and ")" look the same (when one is mirrored), so we're 
already playing that game; that's what BiDi *does*.  The question is, is 
this a good thing that it's doing and should it be doing it to more 
things?  Now, "()" are *always* BiDi-sensitive, and we're talking about 
making it possible for a character to be only sometimes 
BiDi-sensitive... but we already have that, too, since we can flip 
directionality with embeddings and isolates.

To be sure, there are legitimate objections being brought up too.  
Characters that look the same and act different really *are* bad news, 
and that bad news should be considered also.  And other objections also 
make sense.  It just feels like there's some reflex opposition to any 
change.

The other issue, the thing about fonts being able to ligature -> and <- 
into → and ←, is, I think, mostly kind of confusing things.  It's a 
thing fonts can do, and it's cool when they can do it, but it doesn't 
answer the underlying question either way.  It does point out that BiDi 
already does handle the ASCII-art arrows -> and <- because BiDi flips 
the order of the characters and reverses the point on the angle.  It's 
an example of how this is *used* and *works* for developers and for 
internationalization, and why being able to make an arrow do the same 
thing would work for them too.

~mark

On 4/10/25 6:04 PM, Nitai Sasson via Unicode wrote:
>
> On Friday, 11 April 2025 at 00:27, Doug Ewell via Unicode<unicode at corp.unicode.org> wrote:
>
>> OK, so just to be clear, you’re talking about a mechanism where the user enters:
>>
>> U+05D0 HEBREW LETTER ALEF
>> U+0020 SPACE
>> U+002D HYPHEN-MINUS
>> U+002D HYPHEN-MINUS
>> U+003E GREATER-THAN SIGN
>> U+05D1 HEBREW LETTER BET
>>
>> (where the entire sequence --> is mirrored to look like <-- when surrounded by strong RTL characters) and have it replaced by:
>>
>>
>> U+2192 RIGHTWARDS ARROW
>>
>> except that the arrow is visually mirrored depending on the directionality of the surrounding characters.
>>
>>  From my casual reading, it feels like two separate topics are being discussed — glyph mirroring, and replacement of Basic Latin fallback input with true arrow characters — and I want to make sure I understand the use case.
> That is 100% correct. Including the bit about these being two topics.
>
> The replacement of Basic Latin fallback input with true arrow characters is an example use case of the proposed solution.
>
> Here is another example use case: a string template "%s → %s" where the input strings are of unknown directionality, and the intention is for the arrow to point "forwards" from the first argument to the second argument. For the sake of argument, both strings are guaranteed to have the same directionality throughout.
>
> Glyph mirroring is the solution to these example use cases, and already works for other characters.
>
> For example, the template: "%s ⊸ %s" will always have the line next to the first string and the dot next to the second string. The operator character is U+22B8 MULTIMAPhttps://util.unicode.org/UnicodeJsps/character.jsp?a=22B8
>
> Demonstration:
>
> one ⊸ two
> אחד ⊸ שתיים
>
> Results may depend on your system, but on my screen the operator points in opposite directions between these two lines.
>
> The discussion is about making this behavior available for arrow characters.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://corp.unicode.org/pipermail/unicode/attachments/20250410/49d9f89b/attachment-0001.htm>