Rephrase support for rendering RTL scripts

[mjec]

As discussed in ghostty-org/ghostty#1442 (comment),
this clarifies that RTL text is not supported, although rendering of
individual grapheme clusters from RTL scripts is done correctly.

cc @Flimm - is this language clearer?

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
website	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jan 4, 2025 2:03am

[mitchellh]

An improvement in any case. Thank you!

[Flimm]

Thanks for asking my opinion. I agree that this is an improvement. I think it can be improved even further.

An explanation of why this is confusing

Imagine if I spoke a language Foobar that was like English, but it only used a cursive script. I would expect the text "hello world" to look like this:

But in my imaginary example, Ghostty instead renders it like this:

Would you be satisfied if the documentation for Ghostty said this?

Individual grapheme clusters in the Foobar language are rendered correctly, although only right-to-left text is supported.

Wouldn't you find that confusing? The ending point of the stroke rendering "h" should be connected to the starting stroke of the following letter "e" on its right, not on its left! And so on, and so forth, for the rest of the text. The text is simply unreadable! It renders exactly as if someone had typed the text backwards ("d" followed by "l"), instead of in the correct order ("d", "l"). Maybe the documentation is trying to highlight that it supports cursive fonts, but that support is useless if the text is rendered backwards!

To make my point even clearer, if I type cat into my terminal, but instead Ghostty displays tac, would you say that grapheme clusters had been rendered correctly? cat and tac are two different programs that do different things. It is simply incorrect to render grapheme clusters backwards in Foobar, in English, and also in Arabic.

Instead, I suggest this wording:

Grapheme clustering: Multi-codepoint emoji such as flags, skin tones, etc. are rendered correctly as a single character. Individual grapheme clusters in certain scripts (like Thai) are also rendered correctly, although Ghostty does not yet support right-to-left scripts like Arabic and Hebrew.

Thai is a left-to-right language (like English) that also features grapheme clusters.

[mjec]

The ending point of the stroke rendering "h" should be connected to the starting stroke of the following letter "e" on its right, not on its left! And so on, and so forth, for the rest of the text.

To me this is decidedly not an issue with the rendering of grapheme clusters; this is a text direction issue. That causes ligature issues with fonts, because the direction the computer thinks the characters should be joined together is wrong. But I don't think that's related to grapheme clustering or the rendering of grapheme clusters.

My understanding is that a grapheme cluster is a single rendering unit, which may consist of a potentially arbitrary number of codepoints. So h is a grapheme cluster (consisting of a single codepoint, U+0068), as are é (U+00E9 or the sequence U+0065 U+00B4) and H̵̛͕̞̦̰̜͍̰̥̟͆̏͂̌͑ͅ (codepoint seqeunce U+0048 U+0335 U+031B U+0355 U+031E U+0326 U+0330 U+031C U+034D U+0330 U+0325 U+031F U+0346 U+030F U+0342 U+030C U+0351 U+0345) and אֶ (U+05D0 U+05B6). The last of those is a Hebrew grapheme cluster. All of these are, to my understanding, correctly rendered by Ghostty, and that is the feature being discussed.

[Flimm]

That makes perfect sense. As I was typing my comment, I had to read up more about the definition of grapheme clusters, and you're right.

Good documentation keeps in mind its target audience. The target audience are potential users, some of whom want to know if Ghostty supports grapheme clusters (it does), and some of whom want to know if Ghostty supports right-to-left languages (it doesn't). I still think the current phrasing is confusing for the target audience, at least, for those who care about RTL support. Since Ghostty doesn't support RTL text, it probably would be best not to mention Arabic or Hebrew at all in the bullet point talking about grapheme clusters. Languages like French or Thai would be better examples of grapheme cluster support.