Proposals to ensure legibility of bidirectional mathematical notation

Marcel Schneider (charupdate@orange.fr)

r1: 2018-01-15

Abstract

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.

0.  Proposal history

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.

1. Three types of handling mirroring

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.

1.0 State of the art

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.

1.1 Terminology

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):

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.

1.2 Scope of BidiMirroring.txt

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.

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.

1.3 Mirroring type awareness

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.

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.

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.

2. Mathematical arrow symbols

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.

2.0 State of the art

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).

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.

2.1 General Category

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).

2.2 Unpaired Gc=Sm arrows

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.

2.3 Arrow replacement automation

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.

2.4 Bidi-mirroring arrow symbols

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.

2.5 Spread usage recommendations

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.

3. Non-commutative asymmetric operators

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.

3.0 Overview

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.

3.1 With tilde or question mark

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.”

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).

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.

3.2 Mirrored negation stroke?

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.

3.3 Unpaired non-commutative operators

3.4 Mirror pairs

These are Bidi_Mirrored=Yes and are the exact mirror of one another.