BLF Bidirectional Text and Complex Shaping #100207

New Issue

Harley Acheson · 2022-08-04T19:08:19+02:00

Harley Acheson commented

2022-08-04 19:08:19 +02:00

This task is for tracking the goals and implementation of bidirectional text layout and complex text shaping. Note that there might be many parts of this plan that could be (practically) impossible to do and are merely aspirational. Some definitions and explanations:

Bidirectional Text - https://en.wikipedia.org/wiki/Bidirectional_text

Blender currently only displays text left-to-right, which is what is expected for languages like English. However, there are languages - Arabic, Aramaic, Azeri, Dhivehi/Maldivian, Hebrew, Kurdish (Sorani), Persian/Farsi, Urdu - that are primarily right-to-left.

In our context this means that these languages have a display order that differs from their logical order, which remains LTR. When you append an extra character to the end of Arabic text, it is added to the end of the buffer or file, just like in English. It is only during the display of that string that it will (probably) be shown in reversed order.

In the preceding paragraphs I do use “primarily” and “probably” about the display order. This is because even when using only a RTL language there could be portions that are LTR. For example, numbers are shown LTR within strings that are RTL. The same goes for embedded and quoted text from other languages. To make this even more complex our need to support multiple languages simultaneously means that we need to support single strings containing multiple languages with multiple directions.

Complex Text Layout (shaping) - https://en.wikipedia.org/wiki/Complex_text_layout
This is the support of complex scripts like Arabic, Brahmic (Indic) scripts, Devanagai, Khmer, and Thai. These scripts will often use different glyph depending on the position of the character in the word, and/or based on context. Sometimes individual glyphs will have a different order depending on context.

For many English-only users the idea of complex scripts can seem a bit weird. But in English we can hand-write text in either block letters or cursive. If English users had decided to only use cursive we might be faced with a similar situation today, where the glyphs used to display a string might vary depending on their positions relative to other characters in order to make it all join up nicely.

Ligatures - https://en.wikipedia.org/wiki/Ligature_(writing)

Supporting Ligatures (replacing some combinations of multiple characters with a different specific character) is a part of supporting complex scripts. But it is also used in other languages. In English layout we often will replace an “f” followed by an “I” with a single “fi” glyph so that the “tittle” of the “I” does not collide with the hood of the “f”. Turkish has some specific ligatures to help distinguish dotted and dottless “I”. Dutch can sometimes have separate glyphs for combined “ij” and “IJ”.

One new Ligature-related topic that we might not be able to support is programming-specific fixed-width fonts that use ligatures for ease of reading. For example, these fonts will often replace the character combination “!=” with “≠” and ">=" with "≥". Supporting these features with this type of font might be very difficult within our codebase for Text Editor but might be nice to do.

Implementation Challenges

Tasks

Patch
D15687: WIP: Bidirectional Text and Complex Shaping

This task is for tracking the goals and implementation of bidirectional text layout and complex text shaping. Note that there might be many parts of this plan that could be (practically) impossible to do and are merely aspirational. Some definitions and explanations: **Bidirectional Text** - https://en.wikipedia.org/wiki/Bidirectional_text Blender currently only displays text left-to-right, which is what is expected for languages like English. However, there are languages - Arabic, Aramaic, Azeri, Dhivehi/Maldivian, Hebrew, Kurdish (Sorani), Persian/Farsi, Urdu - that are primarily right-to-left. In our context this means that these languages have a *display* order that differs from their *logical* order, which remains LTR. When you append an extra character to the end of Arabic text, it is added to the end of the buffer or file, just like in English. It is only during the display of that string that it will (probably) be shown in reversed order. In the preceding paragraphs I do use “primarily” and “probably” about the display order. This is because even when using only a RTL language there could be portions that are LTR. For example, numbers are shown LTR within strings that are RTL. The same goes for embedded and quoted text from other languages. To make this even more complex our need to support multiple languages simultaneously means that we need to support single strings containing multiple languages with multiple directions. **Complex Text Layout (shaping)** - https://en.wikipedia.org/wiki/Complex_text_layout This is the support of complex scripts like Arabic, Brahmic (Indic) scripts, Devanagai, Khmer, and Thai. These scripts will often use different glyph depending on the position of the character in the word, and/or based on context. Sometimes individual glyphs will have a different order depending on context. For many English-only users the idea of complex scripts can seem a bit weird. But in English we can hand-write text in either block letters or cursive. If English users had decided to only use cursive we might be faced with a similar situation today, where the glyphs used to display a string might vary depending on their positions relative to other characters in order to make it all join up nicely. **Ligatures** - https://en.wikipedia.org/wiki/Ligature_(writing) Supporting Ligatures (replacing some combinations of multiple characters with a different specific character) is a part of supporting complex scripts. But it is also used in other languages. In English layout we often will replace an “f” followed by an “I” with a single “fi” glyph so that the “tittle” of the “I” does not collide with the hood of the “f”. Turkish has some specific ligatures to help distinguish dotted and dottless “I”. Dutch can sometimes have separate glyphs for combined “ij” and “IJ”. One new Ligature-related topic that we might not be able to support is programming-specific fixed-width fonts that use ligatures for ease of reading. For example, these fonts will often replace the character combination “!=” with “≠” and ">=" with "≥". Supporting these features with this type of font might be very difficult within our codebase for Text Editor but might be nice to do. **Implementation Challenges** **Tasks** **Patch** [D15687: WIP: Bidirectional Text and Complex Shaping](https://archive.blender.org/developer/D15687)

Harley Acheson self-assigned this 2022-08-04 19:08:19 +02:00

Harley Acheson commented

2022-08-04 19:08:19 +02:00

Changed status from 'Needs Triage' to: 'Confirmed'

Harley Acheson commented

2022-08-04 19:08:19 +02:00

Added subscriber: @Harley

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

BLF Bidirectional Text and Complex Shaping #100207