Bidi math issues feedback
L2/17-438

Bidi-mirroring mathematical symbols issues feedback

Marcel Schneider (charupdate@orange.fr)

r7: 2018-01-18

Abstract

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.

DISCLAIMERS

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.

0. Feedback history

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.

1. Three types of handling mirroring

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.

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

1.1 Terminology

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

Left-to-right and right-to-left text

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:

  1. Character-level mirroring:

    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.

  2. Glyph-level mirroring:

    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.

  3. RTL glyph alternates:

    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.

Remedial 1

Discourage the use of terms like “character level” and “glyph level” when referring to bidi-mirroring.

Recommend terms like:

  1. glyph exchange, glyph permutation; inter-character glyph exchange; glyph-exchange bidi-mirroring.
  2. right-to-left-glyph bidi-mirroring, RTL-glyph bidi-mirroring, mirror-glyph bidi-mirroring;
  3. character-exchange mirroring, character-replacement mirroring.
Note: Item 3 should not be referred to as “manual mirroring” given that it may be automated (and is suggested for automation, see subsection 2.3: Arrow replacement automation).

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

Figure 1. Two strings of non-commutative relational operators
with slash and/or tilde, spaced out,
in LTR runs (above) and RTL runs (below)
⊈ ⪱ ⫉ ⪷ ⋨ ⫇ ⪝ ⪹ ⋪ ⊄ ⪉ ⋠ ≲ ⋦ ⋢ ⪏ ⊀ ⪍ ≮ ≰ ⋬ ⪵ ≸ ≴ ⊊ ⪟ ⫋ ≨ ⋤ ≾ ⪅ ⪇ ∉ ⊉ ⪲ ⫊ ⪸ ⋩ ⫈ ⪞ ⪺ ⋫ ⊅ ⪊ ⋡ ≳ ⋧ ⋣ ⪐ ⊁ ⪎ ≯ ≱ ⋭ ⪶ ≹ ≵ ⊋ ⪠ ⫌ ≩ ⋥ ≿ ⪆ ⪈ ∌
‮⊈ ⪱ ⫉ ⪷ ⋨ ⫇ ⪝ ⪹ ⋪ ⊄ ⪉ ⋠ ≲ ⋦ ⋢ ⪏ ⊀ ⪍ ≮ ≰ ⋬ ⪵ ≸ ≴ ⊊ ⪟ ⫋ ≨ ⋤ ≾ ⪅ ⪇ ∉ ‮⊉ ⪲ ⫊ ⪸ ⋩ ⫈ ⪞ ⪺ ⋫ ⊅ ⪊ ⋡ ≳ ⋧ ⋣ ⪐ ⊁ ⪎ ≯ ≱ ⋭ ⪶ ≹ ≵ ⊋ ⪠ ⫌ ≩ ⋥ ≿ ⪆ ⪈ ∌

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.

Figure 1bis. A stable emulation of figure 1 using characters in LTR runs only
⊈ ⪱ ⫉ ⪷ ⋨ ⫇ ⪝ ⪹ ⋪ ⊄ ⪉ ⋠ ≲ ⋦ ⋢ ⪏ ⊀ ⪍ ≮ ≰ ⋬ ⪵ ≸ ≴ ⊊ ⪟ ⫋ ≨ ⋤ ≾ ⪅ ⪇ ∉ ⊉ ⪲ ⫊ ⪸ ⋩ ⫈ ⪞ ⪺ ⋫ ⊅ ⪊ ⋡ ≳ ⋧ ⋣ ⪐ ⊁ ⪎ ≯ ≱ ⋭ ⪶ ≹ ≵ ⊋ ⪠ ⫌ ≩ ⋥ ≿ ⪆ ⪈ ∌
⪉ ⊅ ⋫ ⪹ ⪝ ⫇ ⋩ ⪷ ⫉ ⪱ ⊉ ⪵ ⋭ ≱ ≯ ⪍ ⊁ ⪏ ⋣ ⋧ ≳ ⋡ ∌ ⪇ ⪅ ≿ ⋥ ≩ ⫋ ⪟ ⊋ ≵ ≹ ⪊ ⊄ ⋪ ⪺ ⪞ ⫈ ⋨ ⪸ ⫊ ⪲ ⊈ ⪶ ⋬ ≰ ≮ ⪎ ⊀ ⪐ ⋢ ⋦ ≲ ⋠ ∉ ⪈ ⪆ ≾ ⋤ ≨ ⫌ ⪠ ⊊ ≴ ≸

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.

Figure 2. U+27CB (left) and U+27CD (right)
in LTR runs (above) and RTL runs (below)
‮⟋ ‮⟍

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.

Remedial 2

Implement either plan A, plan B or plan C (recommended).

  1. Plan using one file:
    1. In BidiMirroring.txt:
      1. Add all missing [BEST FIT] mappings according to remedials 12, 13, 15 through 19.
      2. In the file header:
        • State that this file can be used to streamline rendering engines when RTL mirror glyphs are available and handled, provided that the algorithm does not exclude from RTL glyph mirroring those characters mapped to mirrored counterparts.
        • Explain that these mappings are intended to maintain legibility of semantics across writing directions regardless of RTL glyph support by fonts.
        • Disclaim that in high-quality typography, pairs tagged [BEST FIT] are without interest and must be skipped, or the glyphs provided by glyph exchange must be overridden by proper RTL glyphs.
    2. Advise the OpenType™ editors that the specification is ready to be upgraded for version 1.9, coming up with a new mirroring pairs list (frozen or not), derived from version 11.0.0 of BidiMirroring.txt by cutting off all [BEST FIT] pairs, and christened OpenType Exact Mirror Pairs List, short OTEMPL.
  2. Plan using two files, descending:
    1. In BidiMirroring.txt: Same as in plan A.

    2. From BidiMirroring.txt, version 10.0.0:
      1. Fork a file named BidiMirroringRestricted.txt;
      2. Remove all [BEST FIT] pairs;
      3. 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/where mirrored glyphs on a per-character basis are missing.
        • Explain that this file contains only such pairs whose glyphs are mirrors of each other as they are required in publishing.
        • Disclaim that this file is designed for backwards compatibility with respect to those implementations where it is used to exclude from RTL glyph mirroring all characters mapped to paired characters.
        • Link to the BidiMirroring.txt file for those interested in comprehensive support.
  3. Plan using two files, ascending (recommended plan):
    1. In BidiMirroring.txt:
      1. Remove all [BEST FIT] mappings.
      2. In the file header: Same as in plan B #2, with link to BidiMirroringExtended.txt.
    2. From BidiMirroring.txt, version 10.0.0:
      1. Fork a file named BidiMirroringExtended.txt;
      2. Add all missing [BEST FIT] mappings;
      3. Complete by adding a third field according to remedial 3.
      4. In the file header: Same as in plan A.

1.3 Mirroring type awareness

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

Remedial 3

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:

  1. ‘A’: accurately mirrored by glyph exchange;
  2. ‘B’: best-fit mirrored by glyph exchange to maintain legibility of semantics, but right-to-left mirror glyph required in typography;
  3. ‘P’: publishing-devised, right-to-left mirror glyph mirroring only, but semantically legible unmirrored;
  4. ‘W’: writing direction sensitive use of characters as of mathematical arrow(-like) symbols, with character semantics swapped according to writing direction;
  5. ‘Z’: zero mirroring either using glyphs or using characters (default).
Recommended status: normative.

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.

Remedial 4

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.

2. Mathematical arrow symbols

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.

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. 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.”
Table 1. 21 mathematical arrow symbols encoded for RTL (left),
and their LTR mirrors (right)
12345678
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.

Figure 3. U+21D2 (left) and his ASCII fallback (right)
in LTR runs (above) and RTL runs (below)
==>
‮⇒ ‮==>

2.1 General Category

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

Remedial 5

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.

Table 2. Arrows of Gc=Sm and their mirrored counterparts of Gc=So
12345678
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

2.2 Unpaired Gc=Sm arrows

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.

Remedial 6

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.

Table 3. Unpaired mathematical arrows without a vertical axis of symmetry,
completed
12345678
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

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

Remedial 7

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

Table 4. Paired arrow symbols for mathematics,
for mapping in suggested BidiArrows.txt
12345678
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

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

Remedial 8

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:

Make these controls accessible in UIs (ideally on keyboards), turn bidi-mirroring on for all and update existing documents by representing arrow symbols with characters that have same semantics as in LTR, and the (very few) instances where arrows must not be bidi-mirrored.

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.

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.

Remedial 9

In NamesList.txt:

  1. From U+219E LEFTWARDS TWO HEADED ARROW through U+21A1 DOWNWARDS TWO HEADED ARROW: remove alias names referring to cursor move; add annotations suggesting use of triangle-headed arrows U+2BEC (already x-ref for U+219E) through U+2BEF; these are already declared as preferred for cursor keys.
  2. From U+2190 LEFTWARDS ARROW through U+2193 DOWNWARDS ARROW: add annotations discouraging use for arrow keys and recommend triangle-headed arrows U+2B60..U+2B63.
  3. From U+2B60 LEFTWARDS TRIANGLE-HEADED ARROW through U+2B63 DOWNWARDS TRIANGLE-HEADED ARROW: add alias names referring to cursor move; add annotations stating that triangle headed arrows are the preferred representation for arrow keys.
  4. Arrows block 2190..21FF, blockheader: Add annotation recommending use of mathematical arrows for inline semantics, while for absolute semantics, other-symbol arrows are the preferred representation.
    Warn that due to initial unification of semantics, bidi-mirroring of arrows is compromised, while several arrow ranges happen to be dispatched on both math-symbol and other-symbol categories.

Remedial 10

In The Unicode Standard, Core Specification:

  1. State that mixed arrows usage is no longer recommended since more dedicated other-symbol arrows have been encoded, such as triangle-headed arrows.
  2. Complain that the arrows usage mix heavily compromises cross-writing-direction mathematical notation by hindering automation of proper display of arrow-shaped mathematical operators.

3. Non-commutative asymmetric operators

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.

3.0 Overview

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.

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

Note: The ‘A’ in columns 4 and 8 stays for “accurate rendering by glyph exchange”; ‘P’ means “publishing-devised mirroring only.”

Table 5. Mirror pairs of operators with tilde or reversed tilde
12345678
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).

Figure 4. U+223C TILDE OPERATOR (left) and U+223D REVERSED TILDE (right)
amidst a string of operators with tilde, spaced out,
in LTR runs (above) and RTL runs (below)
≅ ≂ ≈ ∼ ≊ ≋ ⩰ ≅ ≂ ≈ ∽ ≊ ≋ ⩰
‮≅ ≂ ≈ ∼ ≊ ≋ ⩰ ‮≅ ≂ ≈ ∽ ≊ ≋ ⩰
Remedial 11

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.”
Table 6. Mirror pairs of operators with tilde or reversed tilde,
to be unpaired for consistency
12345678
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.

Remedial 12

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

Table 7. Non-commutative relational operators with tilde or question mark
12345678
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

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.

Remedial 13

In BidiMirroring.txt or, if existing, in *BidiMirroringExtended.txt: Add the pairs in Table 8.

Table 8. Non-commutative relational operators with only a negation stroke
12345678
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.

Remedial 14

For U+226D ≭ NOT EQUIVALENT TO: Change Bidi_Mirrored from No to Yes.

3.3 Unpaired non-commutative operators

A few other bidi-mirrored symbols stay unpaired while being confusable when displayed the wrong way.

Remedial 15

Encode the right-hand part of Table 9, then include these pairs in BidiMirroring.txt or, if existing, in BidiMirroringExtended.txt.

Table 9. Unpaired non-commutative relational operators
12345678
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

3.4 Mirror pairs

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.

Remedial 16

In BidiMirroring.txt or, if existing, in *BidiMirroringExtended.txt: Add the pairs listed in Table 10.

Table 10. Mirror pairs
12345678
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

4. Angle symbols

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.

Remedial 17

In BidiMirroring.txt or, if existing, in *BidiMirroringExtended.txt: Add the pairs listed in Table 11, lines 5 and 6.

Table 11. Angle symbols newly/already/not yet mapped for glyph-exchange mirroring
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.

Remedial 18

In BidiMirroring.txt or, if existing, in *BidiMirroringExtended.txt: Add the pairs listed in Table 12.

Table 12. Angle symbols with arrow arm and Bidi Mirrored=Yes
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).

Table 13. Right angle symbols with arc or square
1234
1 22BE RIGHT ANGLE WITH ARC P
2 299C RIGHT ANGLE VARIANT WITH SQUARE P
3 299D MEASURED RIGHT ANGLE WITH DOT P
Remedial 19

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.

Table 14. Angle symbols completed with mirrored forms for disambiguation
12345678
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

5. Document the reasons

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

6. Update and encourage follow-up

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.