Marcel Schneider (charupdate@orange.fr)
r7: 2018-01-18
While general bidirectional layout is supported by the UBA, and mathematical notation in right-to-left writing systems is accurately rendered by dedicated engines and supported by other high-end software using notably the OpenType™ font technology, the legibility of such notation is compromised in plain text and average HTML display. Consequently, RTL script user communities are disadvantaged on the internet and deprived of mathematical notation in plain text, including UnicodeMath.
The Unicode Consortium is jointly responsible of this politically incorrect situation, by backing the file containing the Bidi Mirrored Glyph property values, whose assignation principles have been flawed on the road, perhaps in an attempt to develop a questionable synergy between Unicode and OpenType™, in contradiction to what that property was designed to perform.
This feedback aims at making plain text and HTML usable for bidirectional math notations, by reviewing and eventually correcting both Bidi Mirroring Glyph and Bidi Mirrored values for the whole set of mathematical symbols without a vertical axis of symmetry and whose glyph semantics is mirroring sensitive, and by suggesting to complete the UCS so as to ensure that glyph-exchange bidi-mirroring — a feature originally called “character-based” (or “character-level”) bidi-mirroring — reaches its initial goal of maintaining legibility across writing directions.
First remedials include enhancement of the framework by disunifying the bidi-mirrored pairs lists, and adding a new normative property called Bidi Mirroring Type, whose values partly result from both Bidi Mirrored and Bidi Mirroring Glyph properties, the comments in BidiMirroring.txt, the checked presence of the substring ‘ARROW’ (or ‘HARPOON’) in the name, and the General Category. The role of these changes is to ensure accuracy and machine-readability of the property values, enhance user information, facilitate implementation, and make for a unified cross-application understanding of the Unicode Standard.
Bona fide: The Unicode Consortium is known for having “done an excellent work defining the pairs of mirrored symbols.” The quoted paper, found on the internet, is dated 2013-05-14 and thus reflects the actual state of the art. As shown below, the Unicode Standard does not meet this reputation. The recommended action to be taken is to quickly and noiselessly fix the issues so that the Unicode Standard even surpasses its reputation. Implementers of the Unicode Standard are expected to be cooperative, and RTL user communities may wish to upgrade tools and practice, fonts and files if appreciating this additional effort. Please note, too, that I did not e-mail this topic to the Unicode Public Mailing List, despite of being subscribed since 2015 (and having sent to the List a total of avg 300 e-mails).
Personalia: Despite of many items in the Unicode Standard being signed by authors and contributors, users of the Unicode Standard should not be deemed to look for advice provided by single individuals under their own responsibility, instead of looking up the Unicode Standard. Either informative or normative, files in the UCD are considered collective work, no matter whether they are signed, such as BidiMirroring.txt, or unsigned such as UnicodeData.txt. Please do not see any personal concern in the discussions along these remedials.
No backing: Although I experience that RTL users are glad to see these issues fixed, and that high quality implementers are waiting for it, this document is not backed specifically by user communities in the intersection of RTL writing systems and mathematics. Given that I refrained from using public mailing lists for this particular topic, gathering much feedback would be hard, and additionally Iʼm neither a mathematician, nor do I use RTL scripts beyond some basic knowledge of Hebrew along with Ancient Greek, and a simple conception of Arabic language and script.
Commitment: Although this topic is not what Iʼm basically expected to work on, there is a strong reason not to dismiss this task. After Western decision makers used the Unicode Standard improperly so that low-end display is needlessly malfunctioning in RTL, it isnʼt obviously up to RTL communities to work out and submit proposals and advocate changes to get things fixed for them. Honestly I’d say that this is up to the one LTR user who occasionally got aware on his own and already submitted a feedback item about the topic (see section 0: Feedback history). And it is unsustainable to see small players who are respectful of their users and of the Unicode Standard, stand alone in front of powerful corporations that do not. The end of the story would be that they cannot help downgrading. This is why we must also try to convince the big companies to conform to the full extent of the Unicode Standard.
Any effort to localize the Unicode Standard is welcomed by the Consortium and brings the opportunity to make character names or descriptors conformant to the original design principles of the Universal Character Set as they were drawn by the founding engineers. Bidi-mirroring as an important feature should be taken into account when designing character names or descriptors, and was so in the 1.0 version.
After a long history of keyboard standardization in France and at ISO/IEC level (ISO/IEC 9995 as a precondition for national standards), results both old and new are about to be brought to the attention of the general public. That brings the need to document the available characters in a suitable manner, by using names or descriptors implementing a maximum level of political correctness. A top priority for character names and main descriptors is to accommodate both left-to-right and right-to-left writing directions, in order to be true and usable whatever script is being considered, without any ethnocentrism.
Since the goal of universality impacts a number of name choices, the underlying bidi-mirroring algorithm is to be documented along whith the character repertoire, so that non-obvious names and descriptors can be understood. To make bidi-mirroring a visible experience, UX design includes clickable table cells with and without leading U+202E (and trailing U+202C, although this is not mandatory in that case), displaying alternatively to simulate change of writing direction. That in turn brings the need to clearly state which characters can be mirrored on a glyph exchange basis between paired or otherwise related characters, and which ones are mirrored only if a dedicated RTL glyph is provided by the font and supported by the rendering engine, or generated by special software.
Surprisingly that effort, fueled by practical requirements of Unicode education directed towards left-to-right script user communities, brought up certain issues that potentially are impacting right-to-left script user communities outside of specialized math rendering engines, e.g. when using as-is the nearly plain text mathematical notation UnicodeMath developed by Murray Sargent of Microsoft. Therefore, when a first feedback item was discussed by the UTC at meeting #153 on 2017-10-25, Roozbeh Pournader and Murray Sargent were directed to check BidiMirroring.txt for other possible pair mappings.
After the short formal feedback discussed at the abovementioned UTC meeting, a more detailed feedback item was first submitted on 2017-12-31, posted as L2/17-438 on 2018-01-02, and updated with revision 4 on 2018-01-04 [revisions]. Due to additional information, revision 5 was tackled prior to being intended some days to stand alone as a differently designed document. This is now merged into the posted feedback as an update.
Thanks to Murray Sargent for sharing Directionality in Math Zones and linked resources.
A spreadsheet folder used as survey tool, and revisions of this feedback, eventually including further development, are available here.
The main point that is assumed to be understood along this feedback is that unlike some legacy encodings, and except arrows, Unicode does encode characters with stable semantics, not glyphs whose semantics is writing direction sensitive. For example, the glyph “(” is used to open a parenthetical in a left-to-right directional run, and it is used to close a parenthetical in a right-to-left directional run. Unicode does not provide a code point for that glyph. Instead, it considers the glyph “(” as representative of a character called OPENING PARENTHESIS, provides a code point for this character, and specifies that in a right-to-left directional run, that glyph is associated with another character, called CLOSING PARENTHESIS. Consequently, Unicode never suggested to handle code points of left and right parentheses any longer. Unfortunately other standards bodies not focussing on handling bidirectional layout did not follow up.
In a bidirectional context, a given character may come into the benefit of mirroring either thanks to the rendering engine grabbing a special glyph designed for right-to-left display, or giving away the LTR glyph to replace it with the LTR glyph of another character mapped for that purpose, or thanks to the user who deletes an arrow character to put another arrow character in its place. (Readers familiar with bidi-mirroring are welcome to skip the rest of this subsection.)
Basically, as stated in Unicode Support for Mathematics, in subsection 4.2: Bidirectional Layout of Mathematical Text, “any character with the mirrored property will need two mirrored glyphs[.]” The high-end way of bidi-mirroring uses dedicated right-to-left glyphs to ensure accurate display of those characters whose mirror glyph is not an exact mirror image of the left-to-right glyph, and of those that require an exact mirror but do not have any counterpart in the Unicode Standard whose LTR glyph meets this requirement.
To streamline implementations without compromising the legibility of the semantics conveyed by the characters, the Unicode Standard also suggests a low-end way of bidi-mirroring. An informative list available as BidiMirroring.txt shows how a rendering engine can move glyphs around between matching characters to ensure a basic extent of bidi-mirroring for the purpose of maintaining legibility across writing directions. To render a pair of bidi-mirrored characters, their glyphs are exchanged, or swapped, while characters are used with stable semantics thanks to keeping using the opening and closing characters accordingly. (For the attributes “opening” and “closing” that have been removed from the character names for the merger with ISO/IEC 10646, see BidiBrackets.txt and UnicodeData.txt.) That allows to avoid disadvantaging right-to-left writing systems, since a set of shared characters that defaults to LTR, including paired punctuations and mathematical symbols whose glyphs have writing direction sensitive semantics, can be correctly displayed in an RTL run — eventually in a legible approximation — without imposing technical requirements that usually are met only by high-end publishing programs.
A third type of bidi-mirroring, by extension, is used for arrows. Since arrows with absolute semantics and arrows with inline semantics have been unified (see The Unicode Standard, version 10.0, chapter 22, section 5, page 811), the semantics of arrows is context dependent and needs human control, so that bidi-mirroring as an automated feature has been disabled for these symbols. However, inline semantics of arrows is so common that a change of writing direction brings the need to almost systematically replace horizontal arrows by their mirrored counterpart, among which 21 have been added for that purpose (see subsection 2.0: State of the art of section 2: Mathematical arrow symbols). According to the Unicode specification, that is done by replacing characters with other characters that in LTR have opposite semantics. This is why there is some concern with arrows, to be considered in section 2: Mathematical arrow symbols, although handling arrows manually is not properly referred to as bidi-mirroring.
In a less formal approach, revision 4 has brought up that the common discourse about “character-level mirroring” and “glyph-level mirroring” (or “character-based” vs “glyph-based”) is misconception-prone. We will look at the wording of one main implementation, track the induced errors, and suggest fixes for documentation and implementation.
To date, the OpenType™ specification is available in version 1.8.2. The text quoted below for convenience was first published in version 1.6 and remained unchanged since then.
The feature tags “rtlm” and “rtla” refer to “Right-to-left mirrored forms” and “Right-to-left alternates.” These features were created by Adobe Systems. The former is described as follows: “This feature applies mirrored forms appropriate for right-to-left text other than for those characters that would be covered by the character-level mirroring step performed by an OpenType layout engine.” The implementer is directed to the section “Left-to-right and right-to-left text” on the Advanced Typographic Extensions page, last updated 6 July 2017 (the cut text appears in tooltips):
When an OpenType text layout engine applies the Unicode bidi algorithm and gets to the point where mirroring needs to be performed on […]
[…] runs with an odd, i.e. right-to-left (RTL), resolved level, the engine does the following:
For each character i in the RTL run:
If it is mapped to character j by the OMPL and cmap(j) is non-zero:
Use glyph cmap(j) at character i
Here OMPL refers to the OpenType Mirroring Pairs List, and cmap(j) refers to the glyph at code point j in the Unicode cmap subtable.
For example, suppose U+0028, LEFT PARENTHESIS, occurred in the run at resolved level 1. The glyph at that code point in the run will be replaced by cmap(U+0029), since {U+0028, U+0029} is a pair in the OMPL.
The engine applies the ‘rtlm’ feature to the entire RTL run. The feature, if present, substitutes mirrored forms for characters other than those covered by the first elements of OMPL pairs (otherwise, it could cancel the effects of character-level mirroring).
[…]
With such a division of labor between the layout engine and the font, most fonts will not need to include an ‘rtlm’ feature, since the mirrored forms in their Unicode cmap subtable would be adequate.
The engine applies the ‘rtla’ feature to the entire RTL run. The feature, if present, substitutes variants appropriate for right-to-left text (other than mirrored forms).
In practice, the engine may apply features simultaneously; thus, it is up to the font vendor to ensure that the features’ lookups are ordered to achieve the desired effect of the algorithms described above. The engine may optimize its implementation in various ways, e.g. by taking advantage of the fact that character- and glyph-level mirroring won’t both apply on the same element in the run.
We can see that the characters with best-fit mappings in the OMPL (and already in BidiMirroring.txt) stay improperly mirrored when that algorithm has completed. Obviously this specification focusses on paired punctuation, while mathematical symbols are not taken into consideration.
Further, adding the parenthesized explanation at the end of the sentence: “The feature, if present, substitutes mirrored forms for characters other than those covered by the first elements of OMPL pairs (otherwise, it could cancel the effects of character-level mirroring)” is to show having forgotten that despite of grabbing a glyph from another character than the currently rendered one, the engine keeps working on glyph level only, and never switches characters.
This case shows how a terminological flaw may impact the accuracy of implementations of the Unicode Standard. There is a need to spread best practice in order to prevent further shortcomings, and to fix past ones.
Given that genuine “character-level” mirroring is the one performed by the end-user, eventually using a tool, to correct arrows when changing writing direction, we should explore other ways of talking about bidi-mirroring without misleading ourselves and others. Referring to “levels” and “bases” is too high of an abstraction to stay efficient in this context. Instead, we might prefer using names of actions and entities.
Discourage the use of terms like “character level” and “glyph level” when referring to bidi-mirroring.
Recommend terms like:
Still in the document quoted above, statements like: “The engine may optimize its implementation […] by taking advantage of the fact that character- and glyph-level mirroring won’t both apply on the same element” show a real demand for a streamlined handling of bidi-mirroring, that Unicode should cater for, while preventing these implementations from ending up as quick-and-dirty approximations of the expected rendering. On the other hand, the discourse about the “division of labor between the layout engine and the font, [in which] most fonts will not need to include an ‘rtlm’ feature, since the mirrored forms in their Unicode cmap subtable would be adequate” points to the concern with incomplete fonts that should be used to generate a fully legible rendering even of bidirectional text.
As demonstrated below (and more extensively in revision 4), BidiMirroring.txt in its actual state mixes both approaches based on divergent requirements, that were alternately taken into account during the lifetime of the file. It started supporting legible rendering in low-end environments, and was then shifted to support exact rendering in high-end environments while maintaining stability of the legacy pairs stock. As a result, it does not meet more specific requirements.
I havenʼt got screenshots of misrendered mathematical expressions in DTP, but I can demonstrate in HTML that legibility is actually compromised whenever a mathematical expression including non-commutative relational operators with slash and/or tilde(s) from the Supplemental Mathematical Operators block added in March 2002 for version 3.2, is displayed RTL. Figure 1 shows two strings of non-commutative relational operators whose glyphs include a negation stroke and/or one or several tildes, and that belong either to the Mathematical Operators block (these are mapped together as best-fit pairs in BidiMirroring.txt) or to the Supplemental Mathematical Operators block, mixed up by pairs in a random order and then separated by first-of-pair (left) and second-of-pair (right).
| ⊈ ⪱ ⫉ ⪷ ⋨ ⫇ ⪝ ⪹ ⋪ ⊄ ⪉ ⋠ ≲ ⋦ ⋢ ⪏ ⊀ ⪍ ≮ ≰ ⋬ ⪵ ≸ ≴ ⊊ ⪟ ⫋ ≨ ⋤ ≾ ⪅ ⪇ ∉ | ⊉ ⪲ ⫊ ⪸ ⋩ ⫈ ⪞ ⪺ ⋫ ⊅ ⪊ ⋡ ≳ ⋧ ⋣ ⪐ ⊁ ⪎ ≯ ≱ ⋭ ⪶ ≹ ≵ ⊋ ⪠ ⫌ ≩ ⋥ ≿ ⪆ ⪈ ∌ |
| ⊈ ⪱ ⫉ ⪷ ⋨ ⫇ ⪝ ⪹ ⋪ ⊄ ⪉ ⋠ ≲ ⋦ ⋢ ⪏ ⊀ ⪍ ≮ ≰ ⋬ ⪵ ≸ ≴ ⊊ ⪟ ⫋ ≨ ⋤ ≾ ⪅ ⪇ ∉ | ⊉ ⪲ ⫊ ⪸ ⋩ ⫈ ⪞ ⪺ ⋫ ⊅ ⪊ ⋡ ≳ ⋧ ⋣ ⪐ ⊁ ⪎ ≯ ≱ ⋭ ⪶ ≹ ≵ ⊋ ⪠ ⫌ ≩ ⋥ ≿ ⪆ ⪈ ∌ |
For reference, here is a stable view of what figure 1 was looking like at the time when this feedback was submitted. It uses appropriately reordered characters in a LTR display. This replaces a screenshot.
| ⊈ ⪱ ⫉ ⪷ ⋨ ⫇ ⪝ ⪹ ⋪ ⊄ ⪉ ⋠ ≲ ⋦ ⋢ ⪏ ⊀ ⪍ ≮ ≰ ⋬ ⪵ ≸ ≴ ⊊ ⪟ ⫋ ≨ ⋤ ≾ ⪅ ⪇ ∉ | ⊉ ⪲ ⫊ ⪸ ⋩ ⫈ ⪞ ⪺ ⋫ ⊅ ⪊ ⋡ ≳ ⋧ ⋣ ⪐ ⊁ ⪎ ≯ ≱ ⋭ ⪶ ≹ ≵ ⊋ ⪠ ⫌ ≩ ⋥ ≿ ⪆ ⪈ ∌ |
| ⪉ ⊅ ⋫ ⪹ ⪝ ⫇ ⋩ ⪷ ⫉ ⪱ ⊉ ⪵ ⋭ ≱ ≯ ⪍ ⊁ ⪏ ⋣ ⋧ ≳ ⋡ ∌ ⪇ ⪅ ≿ ⋥ ≩ ⫋ ⪟ ⊋ ≵ ≹ | ⪊ ⊄ ⋪ ⪺ ⪞ ⫈ ⋨ ⪸ ⫊ ⪲ ⊈ ⪶ ⋬ ≰ ≮ ⪎ ⊀ ⪐ ⋢ ⋦ ≲ ⋠ ∉ ⪈ ⪆ ≾ ⋤ ≨ ⫌ ⪠ ⊊ ≴ ≸ |
In theory, BidiMirroring.txt has a two-in-one status. That could be handled by adding a third field for the best-fit attribute of the mappings, beside of completing these mappings. But there are already too many assumptions in applications since its frozen rip-off was published in the wake of Unicode 5.1 (April 2008). See the OpenType™ specification (above, in a tooltip):
The data contents of the OMPL are identical to the Bidi Mirroring Glyph Property file of Unicode 5.1, and will never be revised. Thus, it will be up to the ‘rtlm’ feature to provide, if needed, mirrored forms for both (a) Unicode 5.1 code points with the “mirrored” property but no appropriate Unicode 5.1 character mirrors, as well as (b) all future “mirrored” property additions to Unicode, whether or not character mirrors exist for them.Such a scope does not require the list to be complete, but only to provide a bunch of facilities to streamline (high-end) fonts and rendering algorithms. The best-fit mappings do not match this pattern. They are set up for use with fonts without the ‘rtlm’ feature, such as the OpenType™ specification refers to when giving hints to streamline (low-end) implementations.
Consequently, high quality implementers and implementations like HarfBuzz and High-Logic use the up-to-date file maintained in the UCD. Whether a recent implementation uses BidiMirroring.txt, not OMPL, is easy to check by using it to view the pair of mathematical diagonals encoded for version 6.1 released in January 2012 (figure 2). Bidi-mirrored by glyph exchange, U+27CB ⟋ MATHEMATICAL RISING DIAGONAL and U+27CD ⟍ MATHEMATICAL FALLING DIAGONAL are the only additions to BidiMirroring.txt since the OMPL was forked from it. Hence this pair has become a touchstone.
The mathematical rising and falling diagonals are included in the font STIX Version 2.0.0.
| ⟋ | ⟍ |
| ⟋ | ⟍ |
One solution would be to disunify both lists, and to release two files on a per-usage basis. The legacy format shall be kept to fit implementations like the OpenType™ Standard as of version 1.8.2, and those applications that use always fonts with the ‘rtlm’ feature, while the fork would match the needs of applications equally handling fonts with or without mirrored glyph variants for RTL. As these implementers are interested in providing up-to-date support of all fonts, a new file completed with the missing mappings is highly appreciated.
Additionally one could say that the increase of processing resources per CPU since the OpenType™ specification had been designed, and lower energy consumption, made it trivial whether a character is given a mirror glyph once or twice (first by glyph exchange, then with RTL glyph). Perhaps there isnʼt any point in streamlining the rendering algorithms any longer, the less as the concerned symbols — all for higher mathematics — are uncommon in current text processing. Hence, completing the BidiMirroring.txt file would be most straightforward. Remedial 2 takes this into account and proposes several action plans. Plan C is a response to the fact that till now, BidiMirroring.txt has not been completed, supposing that there is some technical reason.
Implement either plan A, plan B or plan C (recommended).
Quite another lesson derives from the OpenType™ case: It could have been interesting for an application to parse the comments of BidiMirroring.txt for the [BEST FIT] tag, in order to skip these pairs when performing glyph exchange as a first step before completing with RTL mirror glyphs, if the order of the algorithm should be followed; admitting that if no more than one mirroring should be applied, there would be a point in using RTL glyphs first as far as available. But as no implementation should be expected to parse comments (that in this case might rather enable the implementer to cut these mappings off prior to using the file), it is straightforward to make this tag machine-readable.
Converting the best-fit comment to a machine-readable attribute is useful to streamline implementations, especially if the *BidiMirroringExtended.txt file is released. Depending on the availability of fonts and the completeness of the font stack, some engines could use sometimes the legacy format file, and sometimes the new format file. But as using two lists of which one is a subset of the other is inefficient, the new file may be given a third field (already mentioned in remedial 2) containing the value of a new *Bidi Mirroring Type property for each character in the list, e.g. ‘B’ for “best-fit mirror”, ‘A’ for “accurate mirror,” two letters also used with similar semantics in rating.
There is even more to it. This property could be used to identify mathematical arrows, that additionally should be mapped by pairs even while Bidi_Mirrored=No, in order to facilitate implementations that propose to automate the replacement of inline arrows when the user can confirm that none of them has absolute semantics. (See remedial 7.)
To make sure that all implementers follow up for a unified cross-platform and cross-application user experience, the *Bidi Mirroring Type property should be normative, and that status should apply also to the BidiMirroring.txt and BidiMirroringRestricted.txt or *BidiMirroringExtended.txt files. The actual informative status has proven too little efficient (see OpenType™).
Define a new property called Bidi Mirroring Type, allowing for a machine-readable distinction between glyph-exchange pairs that fit typographic requirements, and those that merely maintain legibility of character semantics, and for identification of mathematical arrows that are mostly to be replaced by their opposite counterpart at cross-writing-direction copy-pasting.
The suggested values have the format of one case-insensitive Latin letter:
The *Bidi Mirroring Type property is suggested for inclusion in the new *BidiMirroringExtended file as a third field (see remedial 2), and eventually in a dedicated file. Adding it in a column to MathClassEx.html would also be helpful, as this allows to document the bidi-mirroring behavior of mathematical symbols in a transparent way in the first place, making sure that implementations respect a minimum threshold for usable rendering.
In MathClassEx.txt (and MathClassEx.html): Add the *Bidi Mirroring Type property as field 6, or even better as field 3.
The *Bidi Mirroring Type property values are used in uppercase in the tables throughout this page. They differ from the values used in revision 4.
The mathematical arrows are commonly used with inline semantics, to such an extent that the leftwards double arrows without and with stroke U+21D2, U+21CD have not been given the General Category value of a mathematical symbol, However, due to unification of semantics [TUS], mathematical arrows are excluded from bidi-mirroring. Both facts contradict some of the most important Unicode design principles. The suggested fixes range from Unicode support for automation of arrow replacement through appropriate changes to the Bidi Mirrored property.
Unlike many other mathematical symbols such as U+22C5 ⋅ DOT OPERATOR and U+2236 ∶ RATIO that have been disunified with punctuations, e.g. for proper handling of inter-character spacing [TUS], some mathematical arrows such as U+2192 → RIGHTWARDS ARROW and U+2190 ← LEFTWARDS ARROW have been unified with general arrows at the expense of proper handling of bidi-mirroring. All other horizontal arrow symbols are likely to be used in mathematics with inline semantics exclusively, as opposed to circular arrows that have absolute semantics (complex plane) and are therefore stable across writing directions.
Despite of having the bidi-mirroring feature turned off, more than 20 mathematical arrow symbols were lacking a mirrored counterpart when they were initially encoded (most in 2002 for Unicode 3.2). Therefore, Azzeddine Lazrek of Cadi Ayyad University proposed a set of reversed arrow symbols, presented in section 6 of Diverse Mathematical Symbols for Arabic, Additional characters proposed to Unicode, page 4. They have been encoded in 2008 for version 5.1 of Unicode. Table 1 shows these symbols along with their LTR mirror. The letter ‘Z’ in columns 4 and 8 stands for “zero mirroring” as this table reflects the actual state. The recommended value of the suggested Bidi Mirroring Type property (see remedial 3) would be ‘W’ for “writing-direction-sensitive use of characters.”
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | |
|---|---|---|---|---|---|---|---|---|
| 1 | 2B30 | ⬰ | LEFT ARROW WITH SMALL CIRCLE | Z | 21F4 | ⇴ | RIGHT ARROW WITH SMALL CIRCLE | Z |
| 2 | 2B31 | ⬱ | THREE LEFTWARDS ARROWS | Z | 21F6 | ⇶ | THREE RIGHTWARDS ARROWS | Z |
| 3 | 2B32 | ⬲ | LEFT ARROW WITH CIRCLED PLUS | Z | 27F4 | ⟴ | RIGHT ARROW WITH CIRCLED PLUS | Z |
| 4 | 2B33 | ⬳ | LONG LEFTWARDS SQUIGGLE ARROW | Z | 27FF | ⟿ | LONG RIGHTWARDS SQUIGGLE ARROW | Z |
| 5 | 2B34 | ⬴ | LEFTWARDS TWO-HEADED ARROW WITH VERTICAL STROKE | Z | 2900 | ⤀ | RIGHTWARDS TWO-HEADED ARROW WITH VERTICAL STROKE | Z |
| 6 | 2B35 | ⬵ | LEFTWARDS TWO-HEADED ARROW WITH DOUBLE VERTICAL STROKE | Z | 2901 | ⤁ | RIGHTWARDS TWO-HEADED ARROW WITH DOUBLE VERTICAL STROKE | Z |
| 7 | 2B36 | ⬶ | LEFTWARDS TWO-HEADED ARROW FROM BAR | Z | 2905 | ⤅ | RIGHTWARDS TWO-HEADED ARROW FROM BAR | Z |
| 8 | 2B37 | ⬷ | LEFTWARDS TWO-HEADED TRIPLE DASH ARROW | Z | 2910 | ⤐ | RIGHTWARDS TWO-HEADED TRIPLE DASH ARROW | Z |
| 9 | 2B38 | ⬸ | LEFTWARDS ARROW WITH DOTTED STEM | Z | 2911 | ⤑ | RIGHTWARDS ARROW WITH DOTTED STEM | Z |
| 10 | 2B39 | ⬹ | LEFTWARDS ARROW WITH TAIL WITH VERTICAL STROKE | Z | 2914 | ⤔ | RIGHTWARDS ARROW WITH TAIL WITH VERTICAL STROKE | Z |
| 11 | 2B3A | ⬺ | LEFTWARDS ARROW WITH TAIL WITH DOUBLE VERTICAL STROKE | Z | 2915 | ⤕ | RIGHTWARDS ARROW WITH TAIL WITH DOUBLE VERTICAL STROKE | Z |
| 12 | 2B3B | ⬻ | LEFTWARDS TWO-HEADED ARROW WITH TAIL | Z | 2916 | ⤖ | RIGHTWARDS TWO-HEADED ARROW WITH TAIL | Z |
| 13 | 2B3C | ⬼ | LEFTWARDS TWO-HEADED ARROW WITH TAIL WITH VERTICAL STROKE | Z | 2917 | ⤗ | RIGHTWARDS TWO-HEADED ARROW WITH TAIL WITH VERTICAL STROKE | Z |
| 14 | 2B3D | ⬽ | LEFTWARDS TWO-HEADED ARROW WITH TAIL WITH DOUBLE VERTICAL STROKE | Z | 2918 | ⤘ | RIGHTWARDS TWO-HEADED ARROW WITH TAIL WITH DOUBLE VERTICAL STROKE | Z |
| 15 | 2B3E | ⬾ | LEFTWARDS ARROW THROUGH X | Z | 2947 | ⥇ | RIGHTWARDS ARROW THROUGH X | Z |
| 16 | 2B3F | ⬿ | WAVE ARROW POINTING DIRECTLY LEFT | Z | 2933 | ⤳ | WAVE ARROW POINTING DIRECTLY RIGHT | Z |
| 17 | 2B40 | ⭀ | EQUALS SIGN ABOVE LEFTWARDS ARROW | Z | 2971 | ⥱ | EQUALS SIGN ABOVE RIGHTWARDS ARROW | Z |
| 18 | 2B41 | ⭁ | REVERSE TILDE OPERATOR ABOVE LEFTWARDS ARROW | Z | 2972 | ⥲ | TILDE OPERATOR ABOVE RIGHTWARDS ARROW | Z |
| 19 | 2B42 | ⭂ | LEFTWARDS ARROW ABOVE REVERSE ALMOST EQUAL TO | Z | 2975 | ⥵ | RIGHTWARDS ARROW ABOVE ALMOST EQUAL TO | Z |
| 20 | 2B43 | ⭃ | RIGHTWARDS ARROW THROUGH GREATER-THAN | Z | 2977 | ⥷ | LEFTWARDS ARROW THROUGH LESS-THAN | Z |
| 21 | 2B44 | ⭄ | RIGHTWARDS ARROW THROUGH SUPERSET | Z | 297A | ⥺ | LEFTWARDS ARROW THROUGH SUBSET | Z |
A spreadsheet-based survey conducted for this feedback brings up that among the 644 mathematical symbols in Unicode 10.0 without a vertical axis of symmetry, 174 are arrow symbols. Additionally, several combining marks featuring arrows or harpoons are used in mathematics. None of them is bidi-mirrored, except when the arrow is not the main constituent. This exception covers eight angle symbols with open arm ending in arrow (U+29A8..U+29AF). In U+2A17 ⨗ INTEGRAL WITH LEFTWARDS ARROW WITH HOOK, the arrow must stay unmirrored, as do the circular arrows in U+2231 ∱, U+2232 ∲ and U+2233 ∳. As the Unicode Standard puts it:
In bidirectional layout, arrows are not automatically mirrored, because the direction of the arrow could be relative to the text direction or relative to an absolute direction. Therefore, if text is copied from a left-to-right to a right-to-left context, or vice versa, the character code for the desired arrow direction in the new context must be used. For example, it might be necessary to change U+21D2 RIGHTWARDS DOUBLE ARROW to U+21D0 LEFTWARDS DOUBLE ARROW to maintain the semantics of “implies” in a right-to-left context.As a result, in most cases, arrows in RTL are represented with characters whose semantics is opposite to the intended one. Wording it the other way around: Arrow characters have opposite inline semantics depending on writing direction. Semantics is shifted from character level back to glyph level. Figure 3 illustrates how the mathematical arrow cited in the Standard keeps pointing one way, while his ASCII fallback is mirrored.
| ⇒ | ==> |
| ⇒ | ==> |
In revision 4, Table 19 (near the end), I claimed that U+21D2 ⇒ RIGHTWARDS DOUBLE ARROW, as well as a dozen others, do not have any mirrored counterpart in the Unicode Standard. That is wrong, of course. Half of those arrows do have an opposite. This error occurred while that table was semi-automatically generated as a fall-off after the 144 arrows in Table 18 had been paired, out of a list that in turn was based on the assumption that if a rightwards arrow is given the General Category of a mathematical symbol, his leftwards counterpart is, too. This way, the Gc filter was set to Sm, so that all Gc=So arrows were hidden.
To some arrows, e.g. in the range U+2190..U+2194 ← ↑ → ↓ ↔, the General Category “Symbol, math” was assigned symmetrically (while the mostly diagonal arrows U+2195..U+2199 ↕ ↖ ↗ ↘ ↙ were left to “Symbol, other”). For a seamless change of writing direction and a consistent mathematical notation, it is desirable to make sure that both parts of a mirror pair belong to the same General Category. The value of this property for graphic characters, while subject to certain constraints, is not frozen under the effect of the Stability Policies (see Identity Stability and Property Value Stability).
For the characters listed in the righthand half of Table 2: Change the General Category value from ‘So’ to ‘Sm’.
Columns 4 and 8 contain the Gc values.
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | |
|---|---|---|---|---|---|---|---|---|
| 1 | 21A0 | ↠ | RIGHTWARDS TWO HEADED ARROW | Sm | 219E | ↞ | LEFTWARDS TWO HEADED ARROW | So→Sm |
| 2 | 21A3 | ↣ | RIGHTWARDS ARROW WITH TAIL | Sm | 21A2 | ↢ | LEFTWARDS ARROW WITH TAIL | So→Sm |
| 3 | 21A6 | ↦ | RIGHTWARDS ARROW FROM BAR | Sm | 21A4 | ↤ | LEFTWARDS ARROW FROM BAR | So→Sm |
| 4 | 21CF | ⇏ | RIGHTWARDS DOUBLE ARROW WITH STROKE | Sm | 21CD | ⇍ | LEFTWARDS DOUBLE ARROW WITH STROKE | So→Sm |
| 5 | 21D2 | ⇒ | RIGHTWARDS DOUBLE ARROW | Sm | 21D0 | ⇐ | LEFTWARDS DOUBLE ARROW | So→Sm |
| 6 | 21F5 | ⇵ | DOWNWARDS ARROW LEFTWARDS OF UPWARDS ARROW | Sm | 21C5 | ⇅ | UPWARDS ARROW LEFTWARDS OF DOWNWARDS ARROW | So→Sm |
Eight arrows from that Table 19 of revision 4, however, remain unpaired after a search for the virtual names of their mirrored counterparts. They are encoded in the Supplemental Arrows-B block added for Unicode 3.2 in 2002. The crossing arrows are used in knot descriptions and have absolute semantics there (although writing direction could have an influence on description of processes like knotting, the same way as it conditions reading and interpretation of many visual perceptions). Nevertheless their Gc=Sm suggests mathematical use (unless there is an error in these Gc values). Anyway, their mirrors are suggested for encoding.
Encode the arrow symbols listed in the righthand part of Table 3.
Note: The glyphs in column 6 are generated by CSS scaling.
Disclaimer: The symbols at lines 1 and 10 are actually Bidi_Mirrored=Yes.
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | |
|---|---|---|---|---|---|---|---|---|
| 1 | 228C | ⊌ | MULTISET | P | #### | *⊌ | *REVERSE MULTISET | P |
| 2 | 292D | ⤭ | SOUTH EAST ARROW CROSSING NORTH EAST ARROW | W | #### | *⤭ | *SOUTH WEST ARROW CROSSING NORTH WEST ARROW | W |
| 3 | 292E | ⤮ | NORTH EAST ARROW CROSSING SOUTH EAST ARROW | W | #### | *⤮ | *NORTH WEST ARROW CROSSING SOUTH WEST ARROW | W |
| 4 | 292F | ⤯ | FALLING DIAGONAL CROSSING NORTH EAST ARROW | W | #### | *⤯ | *RISING DIAGONAL CROSSING NORTH WEST ARROW | W |
| 5 | 2930 | ⤰ | RISING DIAGONAL CROSSING SOUTH EAST ARROW | W | #### | *⤰ | *FALLING DIAGONAL CROSSING SOUTH WEST ARROW | W |
| 6 | 2934 | ⤴ | ARROW POINTING RIGHTWARDS THEN CURVING UPWARDS | W | #### | *⤴ | *ARROW POINTING LEFTWARDS THEN CURVING UPWARDS | W |
| 7 | 2935 | ⤵ | ARROW POINTING RIGHTWARDS THEN CURVING DOWNWARDS | W | #### | *⤵ | *ARROW POINTING LEFTWARDS THEN CURVING DOWNWARDS | W |
| 8 | 2944 | ⥄ | SHORT RIGHTWARDS ARROW ABOVE LEFTWARDS ARROW | W | #### | *⥄ | *SHORT LEFTWARDS ARROW ABOVE RIGHTWARDS ARROW | W |
| 9 | 2970 | ⥰ | RIGHT DOUBLE ARROW WITH ROUNDED HEAD | W | #### | *⥰ | *LEFT DOUBLE ARROW WITH ROUNDED HEAD | W |
| 10 | 29F4 | ⧴ | RULE-DELAYED | P | #### | *⧴ | *REVERSE RULE-DELAYED | P |
Similarly to glyph-exchange bidi-mirroring, that Unicode started providing support for since version 3.0.1 of the Standard, released in August 2000 (see the first BidiMirroring-1.txt), Unicode may wish to provide support for character-exchange mirroring from version 11.0.0 on. This is easy to do by listing the paired mathematical arrow symbols as suggested in remedial 7 a response addressing concerns like those expressed by Daniel Marquès Solé in Edition with Arabic mathematical notation (2013):
At present, it is possible to toggle the directionality of any formula but many character-like symbols would need a manual adjustment.
Create a file named BidiArrows.txt, containing a list of all symbols with writing-direction-sensitive inline semantics but Bidi_Mirrored=No, mapped to the appropriate counterparts similarly to what is done in BidiMirroring.txt, and add it to the UCD.
In the file header:
An initial stock of such mirrored arrows is shown in Table 4.
Note: Character exchange mirrors all arrows appropriately except one single pair that is best-fit mirrored (line 4). In this feedback there is probably no need to make a special case of it, hence the value ‘W’ for all in columns 4 and 8, that stands for “writing-direction-sensitive use of characters.”
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | |
|---|---|---|---|---|---|---|---|---|
| 1 | 20D6 | ◌⃖ | COMBINING LEFT ARROW ABOVE | W | 20D7 | ◌⃗ | COMBINING RIGHT ARROW ABOVE | W |
| 2 | 20EE | ◌⃮ | COMBINING LEFT ARROW BELOW | W | 20EF | ◌⃯ | COMBINING RIGHT ARROW BELOW | W |
| 3 | 2190 | ← | LEFTWARDS ARROW | W | 2192 | → | RIGHTWARDS ARROW | W |
| 4 | 219A | ↚ | LEFTWARDS ARROW WITH STROKE | W | 219B | ↛ | RIGHTWARDS ARROW WITH STROKE | W |
| 5 | 21F4 | ⇴ | RIGHT ARROW WITH SMALL CIRCLE | W | 2B30 | ⬰ | LEFT ARROW WITH SMALL CIRCLE | W |
| 6 | 21F6 | ⇶ | THREE RIGHTWARDS ARROWS | W | 2B31 | ⬱ | THREE LEFTWARDS ARROWS | W |
| 7 | 21F7 | ⇷ | LEFTWARDS ARROW WITH VERTICAL STROKE | W | 21F8 | ⇸ | RIGHTWARDS ARROW WITH VERTICAL STROKE | W |
| 8 | 21FA | ⇺ | LEFTWARDS ARROW WITH DOUBLE VERTICAL STROKE | W | 21FB | ⇻ | RIGHTWARDS ARROW WITH DOUBLE VERTICAL STROKE | W |
| 9 | 21FD | ⇽ | LEFTWARDS OPEN-HEADED ARROW | W | 21FE | ⇾ | RIGHTWARDS OPEN-HEADED ARROW | W |
| 10 | 27F4 | ⟴ | RIGHT ARROW WITH CIRCLED PLUS | W | 2B32 | ⬲ | LEFT ARROW WITH CIRCLED PLUS | W |
| 11 | 27F5 | ⟵ | LONG LEFTWARDS ARROW | W | 27F6 | ⟶ | LONG RIGHTWARDS ARROW | W |
| 12 | 27F8 | ⟸ | LONG LEFTWARDS DOUBLE ARROW | W | 27F9 | ⟹ | LONG RIGHTWARDS DOUBLE ARROW | W |
| 13 | 27FB | ⟻ | LONG LEFTWARDS ARROW FROM BAR | W | 27FC | ⟼ | LONG RIGHTWARDS ARROW FROM BAR | W |
| 14 | 27FD | ⟽ | LONG LEFTWARDS DOUBLE ARROW FROM BAR | W | 27FE | ⟾ | LONG RIGHTWARDS DOUBLE ARROW FROM BAR | W |
| 15 | 27FF | ⟿ | LONG RIGHTWARDS SQUIGGLE ARROW | W | 2B33 | ⬳ | LONG LEFTWARDS SQUIGGLE ARROW | W |
| 16 | 2900 | ⤀ | RIGHTWARDS TWO-HEADED ARROW WITH VERTICAL STROKE | W | 2B34 | ⬴ | LEFTWARDS TWO-HEADED ARROW WITH VERTICAL STROKE | W |
| 17 | 2901 | ⤁ | RIGHTWARDS TWO-HEADED ARROW WITH DOUBLE VERTICAL STROKE | W | 2B35 | ⬵ | LEFTWARDS TWO-HEADED ARROW WITH DOUBLE VERTICAL STROKE | W |
| 18 | 2902 | ⤂ | LEFTWARDS DOUBLE ARROW WITH VERTICAL STROKE | W | 2903 | ⤃ | RIGHTWARDS DOUBLE ARROW WITH VERTICAL STROKE | W |
| 19 | 2905 | ⤅ | RIGHTWARDS TWO-HEADED ARROW FROM BAR | W | 2B36 | ⬶ | LEFTWARDS TWO-HEADED ARROW FROM BAR | W |
| 20 | 2906 | ⤆ | LEFTWARDS DOUBLE ARROW FROM BAR | W | 2907 | ⤇ | RIGHTWARDS DOUBLE ARROW FROM BAR | W |
| 21 | 290C | ⤌ | LEFTWARDS DOUBLE DASH ARROW | W | 290D | ⤍ | RIGHTWARDS DOUBLE DASH ARROW | W |
| 22 | 290E | ⤎ | LEFTWARDS TRIPLE DASH ARROW | W | 290F | ⤏ | RIGHTWARDS TRIPLE DASH ARROW | W |
| 23 | 2910 | ⤐ | RIGHTWARDS TWO-HEADED TRIPLE DASH ARROW | W | 2B37 | ⬷ | LEFTWARDS TWO-HEADED TRIPLE DASH ARROW | W |
| 24 | 2911 | ⤑ | RIGHTWARDS ARROW WITH DOTTED STEM | W | 2B38 | ⬸ | LEFTWARDS ARROW WITH DOTTED STEM | W |
| 25 | 2914 | ⤔ | RIGHTWARDS ARROW WITH TAIL WITH VERTICAL STROKE | W | 2B39 | ⬹ | LEFTWARDS ARROW WITH TAIL WITH VERTICAL STROKE | W |
| 26 | 2915 | ⤕ | RIGHTWARDS ARROW WITH TAIL WITH DOUBLE VERTICAL STROKE | W | 2B3A | ⬺ | LEFTWARDS ARROW WITH TAIL WITH DOUBLE VERTICAL STROKE | W |
| 27 | 2916 | ⤖ | RIGHTWARDS TWO-HEADED ARROW WITH TAIL | W | 2B3B | ⬻ | LEFTWARDS TWO-HEADED ARROW WITH TAIL | W |
| 28 | 2917 | ⤗ | RIGHTWARDS TWO-HEADED ARROW WITH TAIL WITH VERTICAL STROKE | W | 2B3C | ⬼ | LEFTWARDS TWO-HEADED ARROW WITH TAIL WITH VERTICAL STROKE | W |
| 29 | 2918 | ⤘ | RIGHTWARDS TWO-HEADED ARROW WITH TAIL WITH DOUBLE VERTICAL STROKE | W | 2B3D | ⬽ | LEFTWARDS TWO-HEADED ARROW WITH TAIL WITH DOUBLE VERTICAL STROKE | W |
| 30 | 2919 | ⤙ | LEFTWARDS ARROW-TAIL | W | 291A | ⤚ | RIGHTWARDS ARROW-TAIL | W |
| 31 | 291B | ⤛ | LEFTWARDS DOUBLE ARROW-TAIL | W | 291C | ⤜ | RIGHTWARDS DOUBLE ARROW-TAIL | W |
| 32 | 291D | ⤝ | LEFTWARDS ARROW TO BLACK DIAMOND | W | 291E | ⤞ | RIGHTWARDS ARROW TO BLACK DIAMOND | W |
| 33 | 291F | ⤟ | LEFTWARDS ARROW FROM BAR TO BLACK DIAMOND | W | 2920 | ⤠ | RIGHTWARDS ARROW FROM BAR TO BLACK DIAMOND | W |
| 34 | 2921 | ⤡ | NORTH WEST AND SOUTH EAST ARROW | W | 2922 | ⤢ | NORTH EAST AND SOUTH WEST ARROW | W |
| 35 | 2923 | ⤣ | NORTH WEST ARROW WITH HOOK | W | 2924 | ⤤ | NORTH EAST ARROW WITH HOOK | W |
| 36 | 2925 | ⤥ | SOUTH EAST ARROW WITH HOOK | W | 2926 | ⤦ | SOUTH WEST ARROW WITH HOOK | W |
| 37 | 2928 | ⤨ | NORTH EAST ARROW AND SOUTH EAST ARROW | W | 292A | ⤪ | SOUTH WEST ARROW AND NORTH WEST ARROW | W |
| 38 | 292B | ⤫ | RISING DIAGONAL CROSSING FALLING DIAGONAL | W | 292C | ⤬ | FALLING DIAGONAL CROSSING RISING DIAGONAL | W |
| 39 | 2931 | ⤱ | NORTH EAST ARROW CROSSING NORTH WEST ARROW | W | 2932 | ⤲ | NORTH WEST ARROW CROSSING NORTH EAST ARROW | W |
| 40 | 2933 | ⤳ | WAVE ARROW POINTING DIRECTLY RIGHT | W | 2B3F | ⬿ | WAVE ARROW POINTING DIRECTLY LEFT | W |
| 41 | 2936 | ⤶ | ARROW POINTING DOWNWARDS THEN CURVING LEFTWARDS | W | 2937 | ⤷ | ARROW POINTING DOWNWARDS THEN CURVING RIGHTWARDS | W |
| 42 | 2942 | ⥂ | RIGHTWARDS ARROW ABOVE SHORT LEFTWARDS ARROW | W | 2943 | ⥃ | LEFTWARDS ARROW ABOVE SHORT RIGHTWARDS ARROW | W |
| 43 | 2945 | ⥅ | RIGHTWARDS ARROW WITH PLUS BELOW | W | 2946 | ⥆ | LEFTWARDS ARROW WITH PLUS BELOW | W |
| 44 | 2947 | ⥇ | RIGHTWARDS ARROW THROUGH X | W | 2B3E | ⬾ | LEFTWARDS ARROW THROUGH X | W |
| 45 | 294A | ⥊ | LEFT BARB UP RIGHT BARB DOWN HARPOON | W | 294B | ⥋ | LEFT BARB DOWN RIGHT BARB UP HARPOON | W |
| 46 | 294C | ⥌ | UP BARB RIGHT DOWN BARB LEFT HARPOON | W | 294D | ⥍ | UP BARB LEFT DOWN BARB RIGHT HARPOON | W |
| 47 | 294F | ⥏ | UP BARB RIGHT DOWN BARB RIGHT HARPOON | W | 2951 | ⥑ | UP BARB LEFT DOWN BARB LEFT HARPOON | W |
| 48 | 2952 | ⥒ | LEFTWARDS HARPOON WITH BARB UP TO BAR | W | 2953 | ⥓ | RIGHTWARDS HARPOON WITH BARB UP TO BAR | W |
| 49 | 2954 | ⥔ | UPWARDS HARPOON WITH BARB RIGHT TO BAR | W | 2958 | ⥘ | UPWARDS HARPOON WITH BARB LEFT TO BAR | W |
| 50 | 2955 | ⥕ | DOWNWARDS HARPOON WITH BARB RIGHT TO BAR | W | 2959 | ⥙ | DOWNWARDS HARPOON WITH BARB LEFT TO BAR | W |
| 51 | 2956 | ⥖ | LEFTWARDS HARPOON WITH BARB DOWN TO BAR | W | 2957 | ⥗ | RIGHTWARDS HARPOON WITH BARB DOWN TO BAR | W |
| 52 | 295A | ⥚ | LEFTWARDS HARPOON WITH BARB UP FROM BAR | W | 295B | ⥛ | RIGHTWARDS HARPOON WITH BARB UP FROM BAR | W |
| 53 | 295C | ⥜ | UPWARDS HARPOON WITH BARB RIGHT FROM BAR | W | 2960 | ⥠ | UPWARDS HARPOON WITH BARB LEFT FROM BAR | W |
| 54 | 295D | ⥝ | DOWNWARDS HARPOON WITH BARB RIGHT FROM BAR | W | 2961 | ⥡ | DOWNWARDS HARPOON WITH BARB LEFT FROM BAR | W |
| 55 | 295E | ⥞ | LEFTWARDS HARPOON WITH BARB DOWN FROM BAR | W | 295F | ⥟ | RIGHTWARDS HARPOON WITH BARB DOWN FROM BAR | W |
| 56 | 2962 | ⥢ | LEFTWARDS HARPOON WITH BARB UP ABOVE LEFTWARDS HARPOON WITH BARB DOWN | W | 2964 | ⥤ | RIGHTWARDS HARPOON WITH BARB UP ABOVE RIGHTWARDS HARPOON WITH BARB DOWN | W |
| 57 | 2966 | ⥦ | LEFTWARDS HARPOON WITH BARB UP ABOVE RIGHTWARDS HARPOON WITH BARB UP | W | 2968 | ⥨ | RIGHTWARDS HARPOON WITH BARB UP ABOVE LEFTWARDS HARPOON WITH BARB UP | W |
| 58 | 2967 | ⥧ | LEFTWARDS HARPOON WITH BARB DOWN ABOVE RIGHTWARDS HARPOON WITH BARB DOWN | W | 2969 | ⥩ | RIGHTWARDS HARPOON WITH BARB DOWN ABOVE LEFTWARDS HARPOON WITH BARB DOWN | W |
| 59 | 296A | ⥪ | LEFTWARDS HARPOON WITH BARB UP ABOVE LONG DASH | W | 296C | ⥬ | RIGHTWARDS HARPOON WITH BARB UP ABOVE LONG DASH | W |
| 60 | 296B | ⥫ | LEFTWARDS HARPOON WITH BARB DOWN BELOW LONG DASH | W | 296D | ⥭ | RIGHTWARDS HARPOON WITH BARB DOWN BELOW LONG DASH | W |
| 61 | 296E | ⥮ | UPWARDS HARPOON WITH BARB LEFT BESIDE DOWNWARDS HARPOON WITH BARB RIGHT | W | 296F | ⥯ | DOWNWARDS HARPOON WITH BARB LEFT BESIDE UPWARDS HARPOON WITH BARB RIGHT | W |
| 62 | 2971 | ⥱ | EQUALS SIGN ABOVE RIGHTWARDS ARROW | W | 2B40 | ⭀ | EQUALS SIGN ABOVE LEFTWARDS ARROW | W |
| 63 | 2972 | ⥲ | TILDE OPERATOR ABOVE RIGHTWARDS ARROW | W | 2B41 | ⭁ | REVERSE TILDE OPERATOR ABOVE LEFTWARDS ARROW | W |
| 64 | 2973 | ⥳ | LEFTWARDS ARROW ABOVE TILDE OPERATOR | W | 2B4C | ⭌ | RIGHTWARDS ARROW ABOVE REVERSE TILDE OPERATOR | W |
| 65 | 2974 | ⥴ | RIGHTWARDS ARROW ABOVE TILDE OPERATOR | W | 2B4B | ⭋ | LEFTWARDS ARROW ABOVE REVERSE TILDE OPERATOR | W |
| 66 | 2975 | ⥵ | RIGHTWARDS ARROW ABOVE ALMOST EQUAL TO | W | 2B42 | ⭂ | LEFTWARDS ARROW ABOVE REVERSE ALMOST EQUAL TO | W |
| 67 | 2976 | ⥶ | LESS-THAN ABOVE LEFTWARDS ARROW | W | 2978 | ⥸ | GREATER-THAN ABOVE RIGHTWARDS ARROW | W |
| 68 | 2977 | ⥷ | LEFTWARDS ARROW THROUGH LESS-THAN | W | 2B43 | ⭃ | RIGHTWARDS ARROW THROUGH GREATER-THAN | W |
| 69 | 2979 | ⥹ | SUBSET ABOVE RIGHTWARDS ARROW | W | 297B | ⥻ | SUPERSET ABOVE LEFTWARDS ARROW | W |
| 70 | 297A | ⥺ | LEFTWARDS ARROW THROUGH SUBSET | W | 2B44 | ⭄ | RIGHTWARDS ARROW THROUGH SUPERSET | W |
| 71 | 297C | ⥼ | LEFT FISH TAIL | W | 297D | ⥽ | RIGHT FISH TAIL | W |
| 72 | 2B47 | ⭇ | REVERSE TILDE OPERATOR ABOVE RIGHTWARDS ARROW | W | 2B49 | ⭉ | TILDE OPERATOR ABOVE LEFTWARDS ARROW | W |
| 73 | 2B48 | ⭈ | RIGHTWARDS ARROW ABOVE REVERSE ALMOST EQUAL TO | W | 2B4A | ⭊ | LEFTWARDS ARROW ABOVE ALMOST EQUAL TO | W |
| 74 | FFE9 | ￩ | HALFWIDTH LEFTWARDS ARROW | W | FFEB | ￫ | HALFWIDTH RIGHTWARDS ARROW | W |
To date, as of version 10.0.0, the Unicode Standard features already one mathematical symbol that is bidi-mirrored while built from a plain arrow. It had been encoded in 2002 (version 3.2) in the Miscellaneous Mathematical Symbols-B block: U+29F4 ⧴ RULE-DELAYED. It joined another symbol with a bidi-mirrored arrow: U+228C ⊌ MULTISET, in the Standard from the beginning on (Table 3 above, lines 1 and 10).
The facts reviewed so far are likely to prove that horizontal arrows for mathematics (Gc=Sm) are used only with writing-direction-relative semantics and thus could use automated bidi-mirroring, while absolute semantics is best carried by Gc=So arrows. The discourse about multiple semantics and unification is likely to have been de facto obsoleted by the development of the Standard since the time it was worded.
Arrow keys for example are no longer to be represented with mathematical arrows. Inhibiting the bidi-mirroring of the latter is of some interest only for maintaining legacy data predating the encoding of triangle-headed arrows in version 7.0 and 8.0 (2014, 2015), or generated by automated conversion of even older documents. This use case does probably not exist. What should be done today is to spread best practice for proper representation of UI elements.
Whether the time has come to take the last hurdle on the way to fully cross-writing-direction compatible plain text handling, depends on further decisions of RTL user communities, notably from the intersection of RTL scripts and mathematics. Unwanted bidi-mirroring of arrows may impact RTL script usage and can only be dealt with by RTL UX managers. No doubt the role of Unicode is to encourage re-engineering and to keep the door open.
Stay in touch with longstanding RTL experts and partner up with all RTL user communities, both mathematicians and non-mathematicians, to study the feasability of automated bidi-mirroring of mathematical arrow symbols while diversifying arrow usage outside of mathematics in order to free overloaded common arrows.
Explore and evaluate various solutions, such as:
Wonder whether inhibiting the bidi-mirroring feature for those mathematical operators that have the misfortune of being arrow-shaped, is not to perpetuate a digital disadvantage.
In the meantime, we can diversify the use of arrows in any writing direction, so as to take plain advantage of the Unicode repertoire. This brings the need to reinforce Unicode education, notably among LTR communities for bidi-mirroring awareness and correct — i.e. disambiguated — use of arrows in order to make LTR documents bidi-mirroring-ready.
In NamesList.txt:
In The Unicode Standard, Core Specification:
Again, if BidiMirroring.txt was used only with complete OpenType™ support — excluding all fonts not coming along with a complete set of RTL glyphs — then indeed there would be no point in mapping best-fit pairs, nor in adding new ones. But that was not the scope of BidiMirroring.txt when it was created, and it isnʼt today.
As demonstrated above in section 1: Three types of handling mirroring (and already in revision 4), paired relational operators without a vertical axis of symmetry, although being bidi-mirrored, are inequally handled with respect to glyph-exchange bidi-mirroring, depending on a changing policy of how this feature is intended to be used. Consequently, later encoded symbols built with tildes and/or a negation stroke were excluded from glyph-exchange bidi-mirroring, so that they display the wrong way wherever bidi-mirroring relies on glyph exchange only. That means that the formula gets the opposite meaning when the reader relies as usual on the glyph and does not check the character code.
To get an idea based on the already mentioned survey spreadsheet: As of Unicode 10.0.0, out of 263 non-commutative asymmetric operators, 176 symbols are accurately mirrored by glyph exchange, 36 symbols are best-fit mirrored by glyph exchange, and 51 symbols are mirrored only if an RTL glyph is available in the font and called by the rendering engine. These 51 symbols are the problematic ones. 20 of them are excluded from glyph exchange because they have tildes (but 10 others with tildes are included as best-fit mappings), 8 are excluded only because of their negation stroke (and 4 of the previous include a negated almost-equal-to). Among the 23 remaining symbols, 2 (one pair) have a hindering question mark, U+29E8 ⧨ and U+29E9 ⧩ are excluded for an unknown reason, and 19 are unpaired: 8 turnstiles, among which 4 negated ones, and 11 other relational operators.
It becomes clear that the problem encompasses various situations and should be addressed in different ways depending on the available resources. The solutions depend also on whether the two bidi-mirroring pairs lists disambiguated in subsection 1.2: Scope of BidiMirroring.txt will be materially separated, or remain unified. Additionally, whether the slant of the negation slash is mirrored in good typography may be locale-dependent. We will look at this, after fixing the tilde issue and before proposing to complete the UCS.
Whether tildes are mirrored or not, does matter in typography, but mostly not for readability. When writing direction changes, switching the < >-like operators is absolute priority, whatever environment the text is displayed in. Therefore, the missing best-fit pairs should be added either to BidiMirroring.txt, or to the new *BidiMirroringExtended.txt.
However, when discussing the requirements for tilde rendering, there is a need to underscore the semantic difference in three pairs of symbols that exist with tilde and with reversed tilde. Two of these pairs are mirrored by glyph exchange, while the third pair like all other tilde symbols is mirrored by RTL glyphs only (Table 5).
Note: The ‘A’ in columns 4 and 8 stays for “accurate rendering by glyph exchange”; ‘P’ means “publishing-devised mirroring only.”
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | |
|---|---|---|---|---|---|---|---|---|
| 1 | 223C | ∼ | TILDE OPERATOR | A | 223D | ∽ | REVERSED TILDE | A |
| 2 | 2243 | ≃ | ASYMPTOTICALLY EQUAL TO | A | 22CD | ⋍ | REVERSED TILDE EQUALS | A |
| 3 | 2245 | ≅ | APPROXIMATELY EQUAL TO | P | 224C | ≌ | ALL EQUAL TO | P |
Again, that works fine in publishing, when all tildes are mirrored anyway. But as glyph-exchange bidi-mirroring is not designed just as a convenience to streamline high-end rendering algorithms, but as a last resort to facilitate a usable display in whatever environment, there is scarcely any point in mirroring just two pairs, because the effect would be to merge the reversed tildes among the unmirrored ones, while the normal tildes stand out as if they were reversed (Figure 4).
| ≅ ≂ ≈ ∼ ≊ ≋ ⩰ | ≅ ≂ ≈ ∽ ≊ ≋ ⩰ |
| ≅ ≂ ≈ ∼ ≊ ≋ ⩰ | ≅ ≂ ≈ ∽ ≊ ≋ ⩰ |
In BidiMirroring.txt: Remove the pairs in Table 6 from the pair mapping list in order to equalize the mirroring behavior of all operators with tilde or reversed tilde.
Note: The values of the *Bidi_Mirroring_Type property in columns 4 and 8 are set to ‘P’ that stands for “publishing-devised mirroring only.”
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | |
|---|---|---|---|---|---|---|---|---|
| 1 | 223C | ∼ | TILDE OPERATOR | P | 223D | ∽ | REVERSED TILDE | P |
| 2 | 2243 | ≃ | ASYMPTOTICALLY EQUAL TO | P | 22CD | ⋍ | REVERSED TILDE EQUALS | P |
Once the tilde issue is fixed by excluding the four symbols above from glyph-exchange bidi-mirroring, the semantics of the < >-shaped symbols can be equalized as well, by adding the missing pairs to the list.
In BidiMirroring.txt or, if existing, in *BidiMirroringExtended.txt: Add the symbols in Table 7 to the mirroring pairs list.
Note: These are best-fit mappings. Depending on the decisions taken with respect to remedial 2 and remedial 3, either the comments for these symbols shall start with the ‘[BEST FIT]’ string, or the value in the third field shall be ‘B’ for “BEST FIT” (columns 4 and 8).
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | |
|---|---|---|---|---|---|---|---|---|
| 1 | 2A85 | ⪅ | LESS-THAN OR APPROXIMATE | B | 2A86 | ⪆ | GREATER-THAN OR APPROXIMATE | B |
| 2 | 2A89 | ⪉ | LESS-THAN AND NOT APPROXIMATE | B | 2A8A | ⪊ | GREATER-THAN AND NOT APPROXIMATE | B |
| 3 | 2A8D | ⪍ | LESS-THAN ABOVE SIMILAR OR EQUAL | B | 2A8E | ⪎ | GREATER-THAN ABOVE SIMILAR OR EQUAL | B |
| 4 | 2A8F | ⪏ | LESS-THAN ABOVE SIMILAR ABOVE GREATER-THAN | B | 2A90 | ⪐ | GREATER-THAN ABOVE SIMILAR ABOVE LESS-THAN | B |
| 5 | 2A9D | ⪝ | SIMILAR OR LESS-THAN | B | 2A9E | ⪞ | SIMILAR OR GREATER-THAN | B |
| 6 | 2A9F | ⪟ | SIMILAR ABOVE LESS-THAN ABOVE EQUALS SIGN | B | 2AA0 | ⪠ | SIMILAR ABOVE GREATER-THAN ABOVE EQUALS SIGN | B |
| 7 | 2AB7 | ⪷ | PRECEDES ABOVE ALMOST EQUAL TO | B | 2AB8 | ⪸ | SUCCEEDS ABOVE ALMOST EQUAL TO | B |
| 8 | 2AB9 | ⪹ | PRECEDES ABOVE NOT ALMOST EQUAL TO | B | 2ABA | ⪺ | SUCCEEDS ABOVE NOT ALMOST EQUAL TO | B |
| 9 | 2AC7 | ⫇ | SUBSET OF ABOVE TILDE OPERATOR | B | 2AC8 | ⫈ | SUPERSET OF ABOVE TILDE OPERATOR | B |
| 10 | 2AC9 | ⫉ | SUBSET OF ABOVE ALMOST EQUAL TO | B | 2ACA | ⫊ | SUPERSET OF ABOVE ALMOST EQUAL TO | B |
| 11 | 2A7B | ⩻ | LESS-THAN WITH QUESTION MARK ABOVE | B | 2A7C | ⩼ | GREATER-THAN WITH QUESTION MARK ABOVE | B |
Mirroring the negation stroke is locale dependent. Consequently the negated symbols were included in BidiMirroring.txt with the best-fit tag. In some locales, namedly in Morocco, the LTR slant of the negation slash is convenient in RTL, so that these mirror pairs fit typographic requirements in the corresponding locales.
In BidiMirroring.txt or, if existing, in *BidiMirroringExtended.txt: Add the pairs in Table 8.
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | |
|---|---|---|---|---|---|---|---|---|
| 1 | 2A87 | ⪇ | LESS-THAN AND SINGLE-LINE NOT EQUAL TO | B | 2A88 | ⪈ | GREATER-THAN AND SINGLE-LINE NOT EQUAL TO | B |
| 2 | 2AB1 | ⪱ | PRECEDES ABOVE SINGLE-LINE NOT EQUAL TO | B | 2AB2 | ⪲ | SUCCEEDS ABOVE SINGLE-LINE NOT EQUAL TO | B |
| 3 | 2AB5 | ⪵ | PRECEDES ABOVE NOT EQUAL TO | B | 2AB6 | ⪶ | SUCCEEDS ABOVE NOT EQUAL TO | B |
| 4 | 2ACB | ⫋ | SUBSET OF ABOVE NOT EQUAL TO | B | 2ACC | ⫌ | SUPERSET OF ABOVE NOT EQUAL TO | B |
Due to the preference of mirroring the negation stroke, negated symbols that would otherwise have a vertical axis of symmetry are generally Bidi Mirrored=Yes. Mathematicians often prefer a vertical negation stroke, coded by adding the variation selector VS1 U+FE00. so that a number of negated symbols get a vertical axis of symmetry.
Therefore, U+226D ≭ NOT EQUIVALENT TO should probably be given the Bidi_Mirrored=Yes property.
For U+226D ≭ NOT EQUIVALENT TO: Change Bidi_Mirrored from No to Yes.
A few other bidi-mirrored symbols stay unpaired while being confusable when displayed the wrong way.
Encode the right-hand part of Table 9, then include these pairs in BidiMirroring.txt or, if existing, in BidiMirroringExtended.txt.
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | |
|---|---|---|---|---|---|---|---|---|
| 1 | 22AC | ⊬ | DOES NOT PROVE | B | #### | *⊬ | *NEGATED VERTICAL BAR LEFT TURNSTILE | B |
| 2 | 22AD | ⊭ | NOT TRUE | B | #### | *⊭ | *NEGATED VERTICAL BAR DOUBLE LEFT TURNSTILE | B |
| 3 | 22AE | ⊮ | DOES NOT FORCE | B | #### | *⊮ | *NEGATED DOUBLE VERTICAL BAR LEFT TURNSTILE | B |
| 4 | 22AF | ⊯ | NEGATED DOUBLE VERTICAL BAR DOUBLE RIGHT TURNSTILE | B | #### | *⊯ | *NEGATED DOUBLE VERTICAL BAR DOUBLE LEFT TURNSTILE | B |
| 5 | 22A7 | ⊧ | MODELS | A | #### | *⊧ | *VERTICAL BAR SHORT DOUBLE LEFT TURNSTILE | A |
| 6 | 22AA | ⊪ | TRIPLE VERTICAL BAR RIGHT TURNSTILE | A | #### | *⊪ | *TRIPLE VERTICAL BAR LEFT TURNSTILE | A |
| 7 | 22F5 | ⋵ | ELEMENT OF WITH DOT ABOVE | A | #### | *⋵ | *CONTAINS AS MEMBER WITH DOT ABOVE | A |
| 8 | 22F8 | ⋸ | ELEMENT OF WITH UNDERBAR | A | #### | *⋸ | *CONTAINS AS MEMBER WITH UNDERBAR | A |
| 9 | 22F9 | ⋹ | ELEMENT OF WITH TWO HORIZONTAL STROKES | A | #### | *⋹ | *CONTAINS AS MEMBER WITH TWO HORIZONTAL STROKES | A |
| 10 | 22FF | ⋿ | Z NOTATION BAG MEMBERSHIP | A | #### | *⋿ | *Z NOTATION BAG CONTAINERSHIP | A |
| 11 | 27D3 | ⟓ | LOWER RIGHT CORNER WITH DOT | A | #### | *⟓ | *LOWER LEFT CORNER WITH DOT | A |
| 12 | 27D4 | ⟔ | UPPER LEFT CORNER WITH DOT | A | #### | *⟔ | *UPPER RIGHT CORNER WITH DOT | A |
| 13 | 29CE | ⧎ | RIGHT TRIANGLE ABOVE LEFT TRIANGLE | A | #### | *⧎ | *LEFT TRIANGLE ABOVE RIGHT TRIANGLE | A |
| 14 | 29E1 | ⧡ | INCREASES AS | A | #### | *⧡ | *DECREASES AS | A |
| 15 | 2A1E | ⨞ | LARGE LEFT TRIANGLE OPERATOR | A | #### | *⨞ | *LARGE RIGHT TRIANGLE OPERATOR | A |
| 16 | 2A20 | ⨠ | Z NOTATION SCHEMA PIPING | A | #### | *⨠ | *Z NOTATION SCHEMA BACKPIPING | A |
| 17 | 2AA3 | ⪣ | DOUBLE NESTED LESS-THAN WITH UNDERBAR | A | #### | *⪣ | *DOUBLE NESTED GREATER-THAN WITH UNDERBAR | A |
| 18 | 2AE2 | ⫢ | VERTICAL BAR TRIPLE RIGHT TURNSTILE | A | #### | *⫢ | *VERTICAL BAR TRIPLE LEFT TURNSTILE | A |
| 19 | 2AE6 | ⫦ | LONG DASH FROM LEFT MEMBER OF DOUBLE VERTICAL | A | #### | *⫦ | *LONG DASH TO RIGHT MEMBER OF DOUBLE VERTICAL | A |
These are Bidi_Mirrored=Yes and are the exact mirror of each other. Action item 153-A82 of UTC meeting #153 indicates that MULTIMAP (first instance in Table 10 below) is already considered.
In BidiMirroring.txt or, if existing, in *BidiMirroringExtended.txt: Add the pairs listed in Table 10.
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | |
|---|---|---|---|---|---|---|---|---|
| 1 | 22B8 | ⊸ | MULTIMAP | A | 27DC | ⟜ | LEFT MULTIMAP | A |
| 1 | 29E8 | ⧨ | DOWN-POINTING TRIANGLE WITH LEFT HALF BLACK | A | 29E9 | ⧩ | DOWN-POINTING TRIANGLE WITH RIGHT HALF BLACK | A |
Whether angle symbols have absolute directional semantics or text-relative directional semantics, is perhaps an open question. It seems that usually, angle symbols follow the text direction, and are therefore Bidi_Mirrored=Yes. Whether they should be mapped for glyph-exchange bidi-mirroring may be another question, given the incompleteness of angle symbol pairs. If in HTML and plain text, some angles are mirrored, and some are not, the reader may run into issues the same way as with tildes (see section 3.1: With tilde or question mark, above). But the trend is to extend the use of glyph-exchange bidi-mirroring.
As a consequence of consensus 153-C36 and of action item 153-A81, the first two pairs in table 11 below are already included in Draft BidiMirroring.txt for Unicode 11.0, where they add to the following two pairs. The last two pairs are not yet mapped but could be so.
In BidiMirroring.txt or, if existing, in *BidiMirroringExtended.txt: Add the pairs listed in Table 11, lines 5 and 6.
| 1 | 2220 | ∠ | ANGLE | A | 29A3 | ⦣ | REVERSED ANGLE | A |
| 2 | 2221 | ∡ | MEASURED ANGLE | A | 299B | ⦛ | MEASURED ANGLE OPENING LEFT | A |
| 3 | 2220 | ∠ | ANGLE | A | 29A3 | ⦣ | REVERSED ANGLE | A |
| 4 | 2221 | ∡ | MEASURED ANGLE | A | 299B | ⦛ | MEASURED ANGLE OPENING LEFT | A |
| 5 | 2222 | ∢ | SPHERICAL ANGLE | A | 29A0 | ⦠ | SPHERICAL ANGLE OPENING LEFT | A |
| 6 | 29A4 | ⦤ | ANGLE WITH UNDERBAR | A | 29A5 | ⦥ | REVERSED ANGLE WITH UNDERBAR | A |
The following eight angles have an arrow arm but are nevertheless Bidi Mirrored=Yes. (Arrows are generally not bidi-mirrored, but section 2: Mathematical arrow symbols above shows that most mathematical arrow symbols should be.) Since these arrow-arm angle symbols have been encoded by mirroring pairs, they do not need to rely on RTL glyphs. Hence they are suggested for glyph-exchange bidi-mirroring mapping.
In BidiMirroring.txt or, if existing, in *BidiMirroringExtended.txt: Add the pairs listed in Table 12.
| 1 | 29A8 | ⦨ | MEASURED ANGLE WITH OPEN ARM ENDING IN ARROW POINTING UP AND RIGHT | A | 29A9 | ⦩ | MEASURED ANGLE WITH OPEN ARM ENDING IN ARROW POINTING UP AND LEFT | A |
| 2 | 29AA | ⦪ | MEASURED ANGLE WITH OPEN ARM ENDING IN ARROW POINTING DOWN AND RIGHT | A | 29AB | ⦫ | MEASURED ANGLE WITH OPEN ARM ENDING IN ARROW POINTING DOWN AND LEFT | A |
| 3 | 29AC | ⦬ | MEASURED ANGLE WITH OPEN ARM ENDING IN ARROW POINTING RIGHT AND UP | A | 29AD | ⦭ | MEASURED ANGLE WITH OPEN ARM ENDING IN ARROW POINTING LEFT AND UP | A |
| 4 | 29AE | ⦮ | MEASURED ANGLE WITH OPEN ARM ENDING IN ARROW POINTING RIGHT AND DOWN | A | 29AF | ⦯ | MEASURED ANGLE WITH OPEN ARM ENDING IN ARROW POINTING LEFT AND DOWN | A |
Again, the problem with bidi-mirroring angles by glyph-exchange is the risk of inconsistency with RTL-glyph-only mirrored symbols in glyph-exchange-only supporting environments, a bit like in many other instances discussed on this page. It depends on the experience of RTL script user communities whether there is sufficient unambiguity.
Angle symbols that are not mirrored in glyph-exchange-only supporting environments, include the following. Given that already several reversed angles have been added to the UCS, it might be interesting to do the same for the acute angle and for the obtuse angles (Table 14). Generic symbols with specific “right angle” semantics however perhaps don’t occur in reversed forms when featuring a sqare or a dotted arc, and these are unambiguous, so that their publishing-quality rendering may rely on RTL glyphs only (Table 13).
| 1 | 2 | 3 | 4 | |
|---|---|---|---|---|
| 1 | 22BE | ⊾ | RIGHT ANGLE WITH ARC | P |
| 2 | 299C | ⦜ | RIGHT ANGLE VARIANT WITH SQUARE | P |
| 3 | 299D | ⦝ | MEASURED RIGHT ANGLE WITH DOT | P |
Encode the right-hand part of Table 14, then include these pairs in BidiMirroring.txt or, if existing, in BidiMirroringExtended.txt.
Note: U+299E ⦞ ANGLE WITH S INSIDE is only best-fit mirrored. — The glyphs in column 6 are generated by CSS scaling.
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | |
|---|---|---|---|---|---|---|---|---|
| 1 | 221F | ∟ | RIGHT ANGLE | A | #### | *∟ | *REVERSED RIGHT ANGLE | A |
| 2 | 22BF | ⊿ | RIGHT TRIANGLE | A | #### | *⊿ | *REVERSED RIGHT TRIANGLE | A |
| 3 | 27C0 | ⟀ | THREE DIMENSIONAL ANGLE | A | #### | *⟀ | *REVERSED THREE DIMENSIONAL ANGLE | A |
| 4 | 299E | ⦞ | ANGLE WITH S INSIDE | B | #### | *⦞ | *REVERSED ANGLE WITH S INSIDE | B |
| 5 | 299F | ⦟ | ACUTE ANGLE | A | #### | *⦟ | *REVERSED ACUTE ANGLE | A |
| 6 | 29A2 | ⦢ | TURNED ANGLE | A | #### | *⦢ | *INVERTED ANGLE | A |
| 7 | 29A6 | ⦦ | OBLIQUE ANGLE OPENING UP | A | #### | *⦦ | *REVERSED OBLIQUE ANGLE OPENING UP | A |
| 8 | 29A7 | ⦧ | OBLIQUE ANGLE OPENING DOWN | A | #### | *⦧ | *REVERSED OBLIQUE ANGLE OPENING DOWN | A |
Summing it up: The reason why non-commutative relational operators in the Mathematical Operators block are glyph-exchange bidi-mirrored even if containing slashes and tildes, while very similar operators in the Supplemental Mathematical Operators block are RTL-glyph bidi-mirrored only, is best explained by some new specification that had come up in the meantime. The timespan runs from Unicode version 1.1 with the Mathematical Operators block in June 1993, to version 3.2 with the Supplemental Mathematical Operators block in March 2002. The OpenType™ bidi-mirroring specification could have been written up roughly within this decade. It prevents RTL-glyph mirroring from being applied to characters that can be glyph-exchange mirrored. Under such a constraint, glyph-exchange mirroring is limited to the set of those pairs whose glyphs stay fitting the expectations of high-quality typography when switched in a bidirectional context.
That particular OpenType™ specification seems in turn to be influenced by the popular representation of “character-level bidi-mirroring” vs “glyph-level bidi-mirroring,” because that idea seems to fuel a misconception of what “character-level mirroring” is expected to achieve. The specification states indeed that applying what we call RTL-glyph mirroring to characters that are already glyph-exchange mirrored, “could cancel the effects of character-level mirroring” (quoted from “Left-to-right and right-to-left text”, odd level, #2, on “Advanced Typographic Extensions - OpenType™ Layout”).
In my opinion, bidi-mirroring does never occur on character level. It is always done on glyph level. Considering an OpenType™ rendering system, the place in a font where a suitable glyph is taken from can only be either the table of the character itself, or the table of the associated character inside a mirroring pair. In the latter case, taking a glyph from another characterʼs table than the one that is to be displayed, does not shift bidi-mirroring from “glyph level” to “character level” as if mirroring was now done with characters instead of glyphs. The Unicode Bidirectional Algorithm does not use these terms, hyphenated or not, neither in version 6.0 synched with Unicode version 3.0, nor in the actually latest version Unicode 10.0.0. Nor does the Unicode Core Specification v10.0 and v6.0 (except “character level” in one unrelated instance). Nor are they found in BidiMirroring.txt. Nor in the whole UCD, any version, based on a Google search, that finds in turn, on the Unicode website, 99 instances of "character level", but none of them related to bidi-mirroring.
Consequently, the popular wording of the two ways bidi-mirroring is performed in, sbould be adjusted. We might say “glyph-exchange mirroring” instead of “character-level mirroring,” and “right-to-left-glyph mirroring”, short “RTL-glyph mirroring”, instead of “glyph-level mirroring.”
To keep fonts minimal in size, performing bidi-mirroring by glyph exchange is the way to go wherever suitable. However this feature should also protect the readability of semantics against decay due to incomplete mirroring in environments with limited support. Hence, RTL-glyph mirroring must be applicable also to those characters that benefit from glyph-exchange mirroring for the sole purpose of maintaining readability, be that at the expense of typographic perfection.
When the goal is to display characters with mirrored glyphs, it doesnʼt matter what glyphs they are currently displayed with, if mirroring is not applied to glyphs (as opposed to CSS scaling, where it can be). Hence, in proper implementations, glyph-exchange mirroring and RTL-glyph mirroring do never conflict, even if both are applied to a given run.
Such a guarantee should embolden to extend glyph-exchange bidi-mirroring to all those characters whose semantics require it in order to stay legible in all writing and rendering systems. Legibility of semantics is top priority. Once this is ensured, typesetting should be done depending on the technically reachable level of typographic perfection, but never by using algorithms and libraries whose assumptions lead to compromise legibility in less performative environments.