<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>These really are two separate issues, and maybe it were best not
to conflate or confuse them.</p>
<p>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.<br>
</p>
<p>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.</p>
<p>"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.</p>
<p>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.</p>
<p>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.</p>
<p>~mark<br>
</p>
<div class="moz-cite-prefix">On 4/10/25 6:04 PM, Nitai Sasson via
Unicode wrote:<span style="white-space: pre-wrap">
</span></div>
<blockquote type="cite"
cite="mid:174432267189.7.4230793307129938805.673340273@sl.neatnit.net">
<pre wrap="" class="moz-quote-pre">
On Friday, 11 April 2025 at 00:27, Doug Ewell via Unicode <a class="moz-txt-link-rfc2396E" href="mailto:unicode@corp.unicode.org"><unicode@corp.unicode.org></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">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.
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">
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 MULTIMAP <a class="moz-txt-link-freetext" href="https://util.unicode.org/UnicodeJsps/character.jsp?a=22B8">https://util.unicode.org/UnicodeJsps/character.jsp?a=22B8</a>
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.
</pre>
</blockquote>
</body>
</html>