Help debugging bad letter-spacing

[jtbandes]

I've noticed that xterm.js's default rendering has resulted in characters being slightly truncated on the right side. If I manually disable overflow: hidden on a line, you can see that the last letter slightly overflows the line:

If I disable the letter-spacing property on both the individual line and on the .xterm-rows container, then the text seems to fit within the line:

Does anyone have advice on what might be causing this and how should I debug it? I wasn't able to reproduce the issue in a codesandbox easily, so it must be something else about my app / CSS that's triggering the issue, but I don't know where to look. Any help appreciated 🙏 Thanks!

This was encountered in Chrome 130.0.6723.117 on macOS 15.1.

[jtbandes]

Actually, it does seem like this is reproducible in a sandbox: https://codesandbox.io/p/sandbox/xtermjs-test-forked-chl7kj
The letter o is cut off on the right. The clipping is more noticeable the wider you make the window.

[jerch]

This looks like a font issue to me. What is your current font being used? On what browser engine? Which system?

Background on this - the terminal does an initial measurement of 'W' chars to get the basic cell size for your current font settings. Later on, every char to be rendered gets compared to those metrics and corrected by letter-spacing to form a perfect grid.

For some reason your other char metrics differ from the W-metrics by a tiny amount. Ideally this should not be the case for a proper monospace font. Those tiny differences stack up and lead to the total width being 1 or 2 pixels too short (thats at least what it looks like in your case).

What really causes those tiny differences is unclear - can be the font itself or your font renderer in the browser.

Maybe try a different font? Also make sure not to mess with custom CSS font rules/settings on the terminal container (e.g. kerning rules must be off).

[jtbandes]

Oops, thanks for pointing that out. I think it’s public now, could you try again?

[jerch]

Yupp, can access it - so thats a webfont. Eww - well basically this applies here: https://github.com/xtermjs/xterm.js/blob/085a2750387f8c446b9443d2d0a9d7187e38db9b/addons/addon-web-fonts/README.md

Thats the readme of a new addon, which is not yet released (PR: #5178).

[jerch]

Since the addon is not yet available, you can try to get around the loading issue with that one-liner before the terminal init:

await Promise.all(Array.from(document.fonts).map(ff => ff.load()));
// do terminal init here...

For this to work it is important, that document.fonts already contains the font-face definitions, e.g. the css containing them is already loaded.

[jtbandes]

I was already using document.fonts.ready in the codesandbox, but just updated it to use your .load() version instead. Also added a console log so you can see if the fonts were present. I'm not sure the sandbox is set up quite right so you may need to refresh a couple times to ensure the fonts are present before the terminal init. Unfortunately, the conclusion is that the truncation still happens even after waiting for the font to load:

(In fact, if the fonts are not loaded before terminal init, it's quite obvious that there is a problem because the letter spacing is about 2x the actual width and the gaps are very noticeable. And also, this example contains fitAddon.fit() so even if they are not loaded at first, you can resize the window and see the size get recalculated dynamically – yet it still has this truncation issue.)

[jerch]

3 things:

1. Seems the font preloading still does not work correctly, as I get a wrongly styled repr of the terminal initially. Maybe thats an issue with codesandbox, idk. After reloading the inner preview, the font assets are loaded correctly.
2. I dont see the issue with the viewport being 1 or 2px too short, its wrapping correctly here. The problem here might be a totally different one - the scrollbar width is not always reported correctly by the browser, thus might actually render wider than what xterm.js subtracts from its viewport. You could try here the new beta versions, which include a new scroll impl, and see if the issue is gone.
3. Last but not least - I still see tiny letter-spacing rules being added, thus something might be indeed off with that font. But to rule that out, it is important, to get 1. fixed.