Marcel Schneider (charupdate@orange.fr)
r1: 2018-01-15
While accurate rendering of mathematical notation in right-to-left writing systems is provided by dedicated engines and supported by other high-end software using notably the OpenType™ font technology, the legibility of that 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.
These proposals aim at making plain text and HTML usable for bidirectional math notations, by reviewing and correcting both Bidi Mirroring Glyph and Bidi Mirrored values for the whole set of mathematical symbols without a vertical axis of symmetry and whose semantics are mirroring sensitive, and by completing 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 proposals 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' 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.
Any effort to localise 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 standardisation 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 mechanism 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.
Prior to this proposal, after a 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]. It is used for reference in synergy and may not be considered superseded. While designed to stand alone, it ends up paired with this complementary document.
A spreadsheet folder used as survey tool, and revisions of this series of proposals, eventually including further development, are available here.
The main point that is assumed to be understood along these proposals 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 it was not followed by other standards bodies, that donʼt focus on handling bidirectional layout.
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. (Please skip the following three paragraphs if you are familiar with bidi-mirroring.)
Basically (as stated in Unicode Support for Mathematics, under the heading “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 so as 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 prevent 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 referring to the geometrical plane 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 Azzeddine Lazrek, Diverse Mathematical Symbols for Arabic, Additional characters proposed to Unicode, section 6, page 4). 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, L2/17-438 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 propose 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 so as 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 to talk 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 L2/17-438 demonstrates, BidiMirroring.txt in its actual state is a hybrid mix-up of 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 any requirement.
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. Figures 1 and 2 show the same 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 and second-of-pair.
⊈ ⪱ ⫉ ⪷ ⋨ ⫇ ⪝ ⪹ ⋪ ⊄ ⪉ ⋠ ≲ ⋦ ⋢ ⪏ ⊀ ⪍ ≮ ≰ ⋬ ⪵ ≸ ≴ ⊊ ⪟ ⫋ ≨ ⋤ ≾ ⪅ ⪇ ∉ | ⊉ ⪲ ⫊ ⪸ ⋩ ⫈ ⪞ ⪺ ⋫ ⊅ ⪊ ⋡ ≳ ⋧ ⋣ ⪐ ⊁ ⪎ ≯ ≱ ⋭ ⪶ ≹ ≵ ⊋ ⪠ ⫌ ≩ ⋥ ≿ ⪆ ⪈ ∌ |
⊈ ⪱ ⫉ ⪷ ⋨ ⫇ ⪝ ⪹ ⋪ ⊄ ⪉ ⋠ ≲ ⋦ ⋢ ⪏ ⊀ ⪍ ≮ ≰ ⋬ ⪵ ≸ ≴ ⊊ ⪟ ⫋ ≨ ⋤ ≾ ⪅ ⪇ ∉ | ⊉ ⪲ ⫊ ⪸ ⋩ ⫈ ⪞ ⪺ ⋫ ⊅ ⪊ ⋡ ≳ ⋧ ⋣ ⪐ ⊁ ⪎ ≯ ≱ ⋭ ⪶ ≹ ≵ ⊋ ⪠ ⫌ ≩ ⋥ ≿ ⪆ ⪈ ∌ |
For reference, here is a stable view of what figure 1 was looking like at the time when these proposals were 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 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 implementations.
Consequently, high quality implemeters and implementations like HarfBuzz and High-Logic all 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.
⟋ | ⟍ |
⟋ | ⟍ |
The proposed solution is 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 and those applications that use always fonts with the ‘rtlm’ feature, while the new 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.
In BidiMirroring.txt: Remove the [BEST-FIT] mappings.
In the file header: State that this file is for use in right-to-left mirrored glyph supporting environments, and must not be used when mirrored glyphs on a per-character basis are missing.
Explain that this file contains only such pairs whose glyphs are mirror images exactly as they are used in RTL display, even if not being exact mirror images of each other.
Disclaim that this file is designed for backwards compatibility.
Link to the new *BidiMirroringExtended.txt file for comprehensive support.
From BidiMirroring.txt version 10.0.0: Fork a file named BidiMirroringExtended.txt, add all missing [BEST-FIT] mappings.
Complete the new file by adding a third field according to proposal 4.
In the file header: State that this file must not be used to streamline rendering engines when RTL mirrored glyphs are available and can be handled.
Explain that these mappings are intended to maintain legibility of semantics across writing directions regardless of RTL glyph support by fonts.
Disclaim that pairs with *Bidi Mirroring Type property value ‘b’ (see proposal 4), formerly tagged [BEST-FIT], are without interest for high-quality typography.
The case of OpenType™ provides quite another lesson: It could be 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 otherwise, 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), making this tag machine-readable is most straightforward.
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 with one being a subset of the other is inefficient, the new file may be given a third field, already mentioned in proposal 3, containing the value of a new *Bidi Mirroring Type property for each character in the list, e.g. ‘b’ for “best-fit”, and ‘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 proposing to automate the replacement of in-line arrows when the user can confirm that none of them has absolute semantics.
To make sure that all implementers follow through 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 *BidiMirroringExtended.txt files. The actual informative status has proven too little efficient.
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 counterparts when copied across writing directions.
The proposed values have the format of one case-insensitive Latin letter:
The *Bidi Mirroring Type property is proposed for inclusion in the new *BidiMirroringExtended file as a third field (see proposal 3), 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 L2/17-438.
The mathematical arrows are commonly used with in-line 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 Unicode design principles. The proposed 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. In mathematics, all other horizontal arrow symbols are likely to be used 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 initially encoded (most in 2002 for Unicode 3.2) without a mirrored counterpart. Therefore, Azzeddine Lazrek of Cadi Ayyad University proposed a set of reversed arrow symbols — included in Diverse Mathematical Symbols for Arabic, Additional characters proposed to Unicode — 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. It is the value of the proposed Bidi Mirroring Type property (see proposal 4).
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 |
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. 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 L2/17-438, 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 filter was set to Gc=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 all potentially mirrored symbols 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 Table 19 of L2/17-438, 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 over description of processes like knotting, the same way as it conditions reading and interpretation of any visual perception). Nevertheless their Gc=Sm suggests mathematical use (unless there is an error in these Gc values). Anyway, these mirrors are proposed for encoding.
Encode the arrow symbols listed in the righthand part of Table 3.
Note: The glyphs in column 6 are obtained by CSS scaling.
1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | |
---|---|---|---|---|---|---|---|---|
1 | 292D | ⤭ | SOUTH EAST ARROW CROSSING NORTH EAST ARROW | Z | #### | *⤭ | *SOUTH WEST ARROW CROSSING NORTH WEST ARROW | * |
2 | 292E | ⤮ | NORTH EAST ARROW CROSSING SOUTH EAST ARROW | Z | #### | *⤮ | *NORTH WEST ARROW CROSSING SOUTH WEST ARROW | * |
3 | 292F | ⤯ | FALLING DIAGONAL CROSSING NORTH EAST ARROW | Z | #### | *⤯ | *FALLING DIAGONAL CROSSING NORTH WEST ARROW | * |
4 | 2930 | ⤰ | RISING DIAGONAL CROSSING SOUTH EAST ARROW | Z | #### | *⤰ | *RISING DIAGONAL CROSSING SOUTH WEST ARROW | * |
5 | 2934 | ⤴ | ARROW POINTING RIGHTWARDS THEN CURVING UPWARDS | Z | #### | *⤴ | *ARROW POINTING LEFTWARDS THEN CURVING UPWARDS | * |
6 | 2935 | ⤵ | ARROW POINTING RIGHTWARDS THEN CURVING DOWNWARDS | Z | #### | *⤵ | *ARROW POINTING LEFTWARDS THEN CURVING DOWNWARDS | * |
7 | 2944 | ⥄ | SHORT RIGHTWARDS ARROW ABOVE LEFTWARDS ARROW | Z | #### | *⥄ | *SHORT LEFTWARDS ARROW ABOVE RIGHTWARDS ARROW | * |
8 | 2970 | ⥰ | RIGHT DOUBLE ARROW WITH ROUNDED HEAD | Z | #### | *⥰ | *LEFT DOUBLE ARROW WITH ROUNDED HEAD | * |
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 Table 18 of L2/17-438. That is a possible response so that concerns like those expressed in Edition with Arabic mathematical notation from Daniel Marquès Solé (2013) can be addressed:
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: Suggest that this file can be used to facilitate the implementation of tools converting mathematical formulae between writing directions.
Warn that arrows must not be automatically replaced unless the end-user gives his consent after having checked which arrows, if any, have absolute semantics.
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 21 in L2/17-438).
The facts reviewed so far are likely to prove that horizontal mathematical arrows (Gc=Sm) are used only with writing-direction-relative semantics and thus could use automated bidi-mirroring, while absolute semantics are best carried by Gc=So arrows. The discourse about multiple semantics and unification is de facto obsoleted by the development of the Standard since the time it was worded.
Arrow keys for example are no longer 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 the on-coming 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. 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 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:
Keep in mind that inhibiting the bidi-mirroring feature for those mathematical operators that have the misfortune of being arrow-shaped, is 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 not used without 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-1.txt when it was created, and it isnʼt today. As demonstrated in L2/17-438 and in section 1: Three types of handling mirroring, 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.
When trying to put together a survey, one could say approximately, as of Unicode 10.0.0, that 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 4).
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 or, if existing, in BidiMirroringExtended.txt: Remove the pairs in Table 5 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 6 to the mirroring pairs list.
Note: These are best-fit mappings. Depending on the decisions taken with respect to proposal 2 through proposal 4, 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 7.
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 |
Encode the right-hand part of Table 6, In BidiMirroring.txt or, if existing, in BidiMirroringExtended.txt: then include these pairs .
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 one another.
In BidiMirroring.txt or, if existing, in BidiMirroringExtended.txt: Add the following.
Note: MULTIMAP is reported in the meeting minutes of UTC meeting #153.
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 |