> We're being presented with actual use-cases Actually, I’d say we’re being presented with incomplete use cases.
Peter From: Unicode <[email protected]> On Behalf Of Mark E. Shoulson via Unicode Sent: Thursday, April 10, 2025 4:59 PM To: [email protected] Subject: Re: Proposing new arrow characters with Bidi_Mirrored=Yes 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 <[email protected]><mailto:[email protected]> 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 MULTIMAP https://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.
