> Users just type what gives them the correct appearance. > Even then, the problem with encoding duplicate characters based on layout > properties is that "users just type what gives them the correct appearance" > at the time they enter the character. The only context a user has is the text > being typed. If that happens to give the correct direction, a user wouldn't > know to shift to a different character, just in case the context might change.
> wouldn't whoever enters the arrow just use the right^wcorrect one? Does text > get converted from LTR to RTL? If so, isn't that part of the translator's > responsibility? You guys are mostly right: in a context of users typing in text and manually choosing to insert an arrow, they would choose the arrow that looks correct, and it doesn't matter if they use a mirroring or non-mirroring arrow. This is not the issue I mean to solve. > The question then is "what software processes are unavoidable and known to > interfere with this user choice" for arrows in a bidirectional context? The issue is with software that programmatically inserts arrows in text that comes from unpredictable sources. Developers usually never think of this case, causing the arrow to point in the wrong direction. Real world examples: 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! Obviously I don't expect developers to suddenly know to switch to the mirroring arrows overnight, if they are added. But I would love to be able to tell them "all you have to do to fix it is replace this character with that one". > If replacing "->" by an arrow character can change its direction, isn't it up > to the autocorrect software to analyze the bidi context and select the > correct arrow? The rule should be to select whatever substitution gives the > same appearance (direction) as what the user would see for the string they > typed. The problem is this replacement is done (as far as I know) outside of any rendering context, when the text is just a sequence of character codes. It's not reasonable to know which direction the text goes. Sometimes it's completely impossible, if the text direction depends on context that isn't available at the time of replacement. > Here's a possibly disastrous idea: arrows mirror when they are within the > domain of a Directional Override character (U+202D, U+202E). Let's say this was implemented... Would it help solve the issues linked above in some way? > A similar[ly bad] idea might be to have markup-type characters, something > like <MIRRORED SELECTOR> or some such, to indicate that an attached character > should be mirrored (or a pair of them that indicate direction). I actually love that idea! It would solve the issue for all arrows (and any other glyphs in ExtraMirroring.txt), while only introducing one or two new code point. Maybe also <NON MIRRORED SELECTOR> to disable mirroring even on character with Bidi_Mirroring=Yes. > I don't even want to know about handling this in TTB contexts... What is TTB? Couldn't quickly find it.
