Arabic/Persian are not supported in demo

[hkalbasi]

I'm asking since it is advertised in the README that they are supported.

As you can see, the text سلام دنیا‍ in my native terminal is rendered as دنیا سلام and سلام is in the error message, but in the ghostty demo it becomes م‌ا‌ل‌س (characters are reversed and separated). This is my biggest problem with xterm.js as well, it would be great if ghostty address it.

[sreya]

Unfortunately this needs to be fixed in ghostty itself. There's this issue where they talk about it and then this discussion where someone supposedly has it working. We'll be on the lookout for when this lands and see what it takes to integrate it.

Otherwise, I don't think there's much we can do.

[neomantra]

In this WIP PR (#162) where I upgrade to the latest Ghostty 1.3, I think this is resolved. I have a little animated happy face that uses non-western characters in this demo:

[Nadav23AnT]

I can reproduce the same rendering defect with Hebrew in a production integration (dev-3.0, which embeds ghostty-web@0.4.0):

שלום עולם

is delivered to the PTY in logical Unicode order but is painted visually in reverse in the browser terminal.

I traced the current renderer: CanvasRenderer.renderLine() iterates screen cells left-to-right and calls fillText() separately for each cell. That prevents the browser/Canvas text engine from applying the Unicode Bidirectional Algorithm to a line or styled run. This also means a CSS direction: rtl change cannot solve it.

The required fix appears to be upstream BiDi support in the Ghostty VT/screen model plus a renderer mapping for visual cell order, including cursor, selection, copy, hit testing, ANSI style runs, and mixed LTR/RTL text.

Could maintainers confirm whether the Ghostty 1.3 upgrade in #162 includes the needed VT API/data to implement this? If so, I can test dev-3.0 against it and provide a Hebrew mixed-text reproduction matrix.

Related upstream issue: ghostty-org/ghostty#1442

[neomantra]

I explored this some in Golang using booba as a host. I made a test there called rtl-text to explore Hebrew, Persian, and Arabic bi-directional text. I then used Claude in Chrome for it to help analyze it. On the left is the test program in the Ghostty terminal program, on the right is it in a browser via booba and thus Ghostty 1.3 based.

Various issues surfaced which I've kept as UPSTREAM-FIX_PROMPT.md in the test directory. The glyphs look nice though, I'm not sure what comes through in stock ghostly-web.

As @Nadav23AnT notes, it covers painting, selection, hit-testing, and mouse reporting. There are also issues with cursive.

Fortunately, it seems to be scoped to ghostty-web and does not need further upstream work. [There are more selection APIs coming to libghostty-vt, so that will be an interesting line to check.].

After that, I worked through an implementation with the LLM (in loops with Claude-in-Chrome, pretty interesting). Here's the result of that... first is before and right is after application of the nm-rtl branch, which itself is on the nm-webgpu which is on a Ghostty 1.3 branch...

Honestly I have no idea if that is correct or not as I'm unfamiliar with the languages involved.