Fix wide characters printed under DEC line drawing from taking up two columns

[robmorgan]

What do you want to change?

Hi, I'm Rob and I'm looking to make my first contribution.

Ghostty supports legacy charsets such as DEC line drawing, which programs use for box borders. When one of those charsets is active, Ghostty prints any character it can't map (e.g., anything above 0xFF, such as emoji) as a space, and it sizes that space from the original character, so an emoji becomes a two-column space and everything after it on the line shifts one column right.

Here's how to reproduce toggling line drawing:

printf '\033(0\360\237\230\200A\033(B\n'  && printf ' A\n'

Tested on Ghostty macOS 1.3.1

The fix is to map each printed character through its charset exactly once and write padding cells without the charset.

Why do you want to make this change?

I'm working on a CLI app that uses libghostty-vt to keep snapshots and keep a copy of each session's terminal. When I reopen the app, it sends that copy back as VT output, and it's misaligned.

Honestly, it's an edge case, as programs usually switch back to normal text before printing emoji characters, but it will be a problem for multiplexer apps that support legacy or web clients that don't use a binary protocol.

I don't think my proposed fix will materially impact performance either, since it's a one-function change.

I acknowledge that:

• I have read the Contributing Guide and understand the contribution process.
• I have read and agree to follow the AI Usage Policy.
• I wrote this vouch request myself, in my own voice, without AI generating it.

[jcollie]

!vouch

[jcollie]

We love edge case fixes. Be sure and reference the xterm source code as that's what we generally follow when it comes to how "things should work" when it comes to terminal sequences.

[robmorgan]

@jcollie thanks for steering me in the right direction, will do!

[j4james]

FYI, it's not the widths that are wrong - it's the mapping of emoji to spaces. The purpose of the \033( sequence is to a designate a character set into the G0 g-set. And by default the G0 g-set is mapped into GL, which is the left half of the code table (code points 0x21 to 0x7E). No other code points should be affected unless G0 is also mapped into GR (but Ghostty doesn't support that, and it wouldn't apply when UTF-8 was active anyway).

The standard for this is defined in DEC STD 070-3, which is based on ISO 2022. These are also the documents that Xterm would be following.

[robmorgan]

@j4james thank you for the insight! Agreed. My fix in #14554 stops mapping code points outside GL to spaces and the width issue was just a symptom. I believe it's still an improvement based on my use case. I'll update the description and commit message.