Text Sizing Protocol

[rockorager]

Kitty has recently implemented a text sizing protocol. The idea is that in a single sequence, one can specify a scale factor (integer, for larger text), a numerator + denominator (for smaller text), and explicit widths. The explicit widths are used as an alternate solution to mode 2027, and are (IMO) more robust - the application can explicitly tell a terminal how wide a given grapheme should be, as opposed to hoping they both agree.

Aside from the width portion, I think there are numerous use cases for the scaling protocol as well. I'm planning to implement this in libvaxis (width is already implemented, but I will do scaling once I have figured out a good data model for it) and it would be great for Ghostty to have support as well.

[rockorager]

More discussion here: kovidgoyal/kitty#8226

Also note: foot is implementing the width portion of the spec.

[reykjalin]

Quick demo of why this would be cool in a markdown CLI renderer. The demo just scales the size of h1, h2, and h3 headings, but I think it does a good job showing off the potential :)

out.mp4

I'm personally excited for this to use for building TUIs. Scaling certain UI elements would be really nice, e.g. making some buttons bigger, rendering different sized text in dialogs, and other things of that sort.

EDIT: Repo with demo executable I'm using here: https://github.com/reykjalin/md

[00-kat]

Somewhat relevant: there is also some chatter over at Neovim about utilising Kitty's new text sizing protocol: neovim/neovim#32539.

[caquino]

presenterm is also supporting Kitty's new text sizing protocol, came here to check if there was plans to support it in the future

[Wukuyon]

Maybe it'd be better for Ghostty to start with the width part of the spec first, like how foot terminal did it. As well as the cell splitting algorithm (kovidgoyal/kitty#8533).

Like @rockorager said in kovidgoyal/kitty#8226 (comment), the width part of the spec is probably the most valuable to the terminal ecosystem is a whole. There will be projects that balk at the idea of scaled text, but would benefit from the explicit width portion.

The width part of the spec fixes a very big issue for the terminal ecosystem. Right now, the terminal emulator and the client application try to use separate Unicode character width tables, so when they disagree the UI of the client application breaks.

Fundamentally, this is a co-ordination problem. Both the client program and the terminal have to somehow share the same database of character properties and the same algorithm for computing string lengths in cells based on that shared database. Sadly, there is no such shared database in reality. The closest we have is the Unicode standard. Unfortunately, the Unicode standard has a new version almost every year and actually changes the width assigned to some characters in different versions. Furthermore, to actually get the "correct" width for a string using that standard one has to do grapheme segmentation, which is a complex algorithm, specified below. Expecting all terminals and all terminal programs to have both up-to-date character databases and a bug free implementation of this algorithm is not realistic.

So instead, this protocol solves the issue robustly by removing the co-ordination problem and putting only one actor in charge of determining string width. The client becomes responsible for doing whatever level of grapheme segmentation it is comfortable with using whatever Unicode database is at its disposal and then it can transmit the segmented string to the terminal with the appropriate w values so that the terminal renders the text in the exact number of cells the client expects.

Fixing this problem is a huge deal for every complex TUI app. If text scaling would introduce difficult complexity to Ghostty, then Ghostty should prioritize the width half of the new spec alone first.

[benjajaja]

https://github.com/benjajaja/mdfried leverages this, it's another way to try it out. On ghostty (and any other terminal) it falls back to rendering text as images.

[pluiedev]

I suppose we can start with parsing the text sizing protocol correctly first — actually rendering each glyph in the correct size might be difficult and might need significant restructuring of the current cell renderer, but we can take care of that later