xterm.js
xterm.js copied to clipboard
xtermjs
OSC 50 (get/set font) VT sequence
As per ctlseqs.txt from xterm, OSC 50 is used to query/set the use font.
I was actually looking into neofetch and how it is detecting the font being used, and I think they all got it wrong (fishing the font by looking into the config file of the detected terminal). The proper way to communicate with the TE is to use the PTY, so through some VT sequence.
There is already OSC 50 and at least xterm and mintty (and mine) are supporting that. I'd wonder if you have interest in supporting that too (at least the getter part).
Many thanks, Christian.
I think we should only support something like this if it's in vte/iterm, seems like a pretty obscure one that would probably not be used in VS Code anyway since it would conflict with the font setting.
Ah, too bad. So xterm, mintty, and contour are having it. if you want to wait for libvte, hmm... :) I think the reading part of OSC 50 is at least beneficial for the reasons I gave above. Not trying to force you to implement that here, I just wanted to propose that while looking for other TEs implementing this. (I didn't test Mac based TEs though)
mintty is pretty far ahead, when it comes to font settings and the possibilities to script them from appside. I think no other TE implements SGR 11-19.
@christianparpart I have never heard or seen OSC 50, what does it do in the set case? Allowing font uploads? It would simply not be possible for xterm.js that easy (Is it possible to add a font into a document from a base64 inline URL?). I am not against the get action, just dont see much usage for that, if set doesnt work.
On a bigger scale: xterm.js is still pretty thin in the OSC realms in general, some features simply never got implemented, other are not that useful. I remember fighting against that OSC 7 workdir idea, but meh, most thought it is a good idea to have a close heuristic approximation. Well I am not a fan of "works most of the time" (and it doesnt, ssh will like always fail here), imho the terminal has enough of those sloppy additions.
@jerch the font access API would make this possible using client only code, it's not ready for prime time though. It's what I'll be using in Luna Paint to get the system's fonts for writing text.
Hey; just try that on xterm. You'll get the some kind of font name back. You can modify that to your liking and send it back - the font name - not content :).
I see a real usage in tools that want to introspect the environment to display some summary. I'm not (even though I did implement it) that much interested in the set-case, but the get-case is definitely useful, at least for such tooling app developers, also, because it works across the network.
For the set case, you specify a font family. In my case (as I was concerned a little about apps unwillingly changing stuff without asking the user), I've added a permission wall in front, where the user can configure whether or not he likes the app doing that without notice, not all all, or by asking (popup window in my case, where the terminal asks and given on the user input, acts on it).
Well I think we already have a use case for this - nerdfont. Or any other font with custom glyphs an app would like to load. But dont we need a listing sequence for that, whether the TE knows a particular font at all, and prolly a way to upload/register one, if it is not listed? To me this field feels like either going all in providing the full package of font customization, or it is not useful at all. The full package would provide something like that:
- get/set default font (OSC 50?)
- list fonts usable as default (aka installed fonts for the TE)
- upload a new font (old VTs had sequences for that)
- register a font to an SGR slot 11-19
The latter would be needed to allow to overwrite codepoint regions with custom font glyphs from another font. Nerdfont could use that to their advantage, all they have to provide is a tiny font for their PUA glyphs without the need to patch tons of established fonts. The shell then can access those as SGR 12 \uXXXX SGR 0.
Seems all of the full package would be possible with xterm.js, even the custom font upload, as @Tyriar pointed out. But such an addition would be huge, how likely is it to be implemented by other TEs? I hestitate to add such a package of functionality on our own, as it will just further segregate TEs. Guess this needs some agreement among other TE devs first. (And we prolly could learn from ~mlterm~ mintty here.)
upload a new font (old VTs had sequences for that) exactly, I forgot which one it was, but I had that in mind too. I think it should be attempted to reuse what is already there.
Also, I think OSC 50 can be done completely separately from the upload/list-all-fonts topic. It's a different feature that does make sense, too, I absolutely agree. But I think both topic can be handled individually without overlapping.
p.s.: unclear to me for font-uploads would be how to deal with font fallback. that's an unknown complexity to me still. p.p.s.: Can we ping the mlterm dev(s) in this thread on that matter? :)
Oh sorry, I mixed the TE names - I actually meant mintty, thats the TE which is far ahead in terms of font settings, not mlterm. I think the core maintainer is active on github under the same name.
Edit:
p.s.: unclear to me for font-uploads would be how to deal with font fallback. that's an unknown complexity to me still.
Yes, once going that path it pulls quite a lot, it is def. not done in one Saturday afternoon. For your question - I'd say always fall back to default font handling, if a glyph is missing. But maybe @mintty has more insights here.
get/set default font (OSC 50?)
This sequence refers to the currently selected font attribute in mintty. So SGR 12 OSC 50 SGR 10 would change alternative font 2 etc. Also works separately in Tek mode.
list fonts usable as default (aka installed fonts for the TE)
Mintty has a command-line option to report (monospace) fonts: mintty -Rf. I don't think it's too useful to retrieve the (long) list interactively.
upload a new font (old VTs had sequences for that)
This feature of historic VT terminals was applicable and defined for bitmap fonts. So it's not really too useful nowadays and I would discourage any terminal to spend effort on it; there are no plans to ever implement it in mintty.
register a font to an SGR slot 11-19
Actually SGR 11-20, where 11 and 20 are slightly special cases.
get/set default font (OSC 50?)
This sequence refers to the currently selected font attribute in mintty. So SGR 12 OSC 50 SGR 10 would change alternative font 2 etc. Also works separately in Tek mode.
@mintty sorry for not being knowledgeable enough with mintty here, but does that mean you do in fact implement OSC 50 and especially also the set part? I've done that too (and I've put it behind a configurable permission wall for those who are concerned). When setting a font, do you set it only for regular, or also bold/italic/bold+italic (same font but respective weight/slant)?
list fonts usable as default (aka installed fonts for the TE)
Mintty has a command-line option to report (monospace) fonts:
mintty -Rf. I don't think it's too useful to retrieve the (long) list interactively.
In kitty I think there is a similar CLI command to retrieve the list of fonts kitty can find at least.
upload a new font (old VTs had sequences for that)
This feature of historic VT terminals was applicable and defined for bitmap fonts. So it's not really too useful nowadays and I would discourage any terminal to spend effort on it; there are no plans to ever implement it in mintty.
I do remember that this was in the bitmap time, right. So you want to say it's not just recommended to implement the exact same VT sequences for doing that but also for doing that in general (uploading TTF/OTF fonts)?
I do remember that this was in the bitmap time, right. So you want to say it's not just recommended to implement the exact same VT sequences for doing that but also for doing that in general (uploading TTF/OTF fonts)?
Just a minor headsup: I remember that on some platforms (windows) loading a font file from arbitrary source was known to be a security nightmare (foreign code execution). Not sure if thats still the case, if so, a natively running app might not want that at all.
(Imho xterm.js gets not hit by that, as browsers have countermeasure in place...)
you do in fact implement OSC 50 and especially also the set part? When setting a font, do you set it only for regular, or also bold/italic/bold+italic (same font but respective weight/slant)?
OSC 50 takes a font name to set it for the current font attribute. The 4 font styles are always based on the same font name.
I do remember that this was in the bitmap time, right. So you want to say it's not just recommended to implement the exact same VT sequences for doing that but also for doing that in general (uploading TTF/OTF fonts)?
It's not possible as the sequence is defined as a bitmap format, with fixed resolution (of the time).