-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support fonts and fonts attributes through inline escape sequences like mintty and vte52 #6779
Comments
I'm personally not in favour of many of these attribute, without some evidence of their being widely used, because otherwise we're just wasting buffer space on a feature that most people will never need. For example, last I checked alternate fonts were supported by nobody other than Mintty, so it seems highly unlikely that there are many apps making use of that functionality. It also never seemed like a particularly practical feature to me. In what situation would an app choose to set a particular font number without knowing what that font was? Your "Very thin font" could just as easily be a very bold font, or a gothic font, or even just wingdings. An app has no way of knowing. |
ECMA-48 defines FONT SELECTION (FNT), for selecting which ten fonts can be referenced with SELECT GRAPHIC RENDITION (SGR). However, it seems inconvenient:
For those reasons, I think OSC or DCS is more suitable for specifying a font name than FNT. Xterm uses OSC 5 0 ; Pt ST but does not support alternative fonts in SGR. I imagine OSC 5 0 : Ps ; Pt ST might be a reasonable encoding, but I don't know if some terminals assign a different meaning to this encoding or define a different way to set alternative fonts. ITU-T Rec. T.416 §8.2 (Font selection) uses SGR but not FNT. |
OSC 50 is problematic, because it's one of those sequences that has a bunch of different interpretations. Other than the XTerm font selection, iTerm2 uses it for clipboard operations, and Konsole uses it for setting profile options (one of those options is the font, actually, but obviously not in a way that's compatible with the XTerm usage). |
What do you mean? As far as I can tell, Windows Terminal removes unsupported SGR control sequences from the output.
Dead link. https://github.com/csdvrx/sixel-testsuite/blob/31596c68ff960fd45457a6f0d8d86fa5614bc502/ansi-vte52.sh works better. |
I was not interested in this feature, until now. GitHub released the monaspace font family. They proposes to change the font based on semantics, such as having a different font for completion suggestions (GitHub Copilot, …), and they include fonts which plays nicely with each-others. This idea would also be useful in Windows Terminal, for example to have a different font for shell commands completion suggestions, but would need support for alternative fonts using ECMA-48 SGR codes (edit: or using other codes ?). |
Yeah, I had the same thought when I first read about that monaspace font. But I still come back to my initial objection above: I don't see any applications using something like this without a way to control (or at least query) the font/style associated with each SGR number. It's also worth noting that DEC used SGR 10, 11, and 12 for something more akin to character set selection (see VT510 SGR), and I think there are a few modern terminals that follow that behavior too. So if we do ever decide to support SGR font selection, it may be best to limit it to SGR 13 and above. |
I find syntax coloring to be very distracting, so I make heavy use of styles and fonts and I would really appreciate if WT terminal could support this feature:
This is because there is a very simple workaround: after the manual mapping process has been done within WT (ex: Font 1 is XX, Font 2 is YY...), then editors like vim (or shells) could show the "current result" to the user, to check if it matches the user expectations. If it doesn't, the editors could offer suggestions to redo the mapping. like a guide process. As for actual uses within the editor 2 examples:
Only Microsoft can decide how features should be prioritized, and this is just a simple example with vim and eza, but I can see many text applications benefitting from having different usable fonts in the terminal (IRC: different font per channel or friend group, etc) The user could also directly benefit from being able to introduce esc sequences for software with configuration files. |
There might be some different syntax for specifying fonts, but basic usage of Additionally, the Incidentally, iTerm has long since changed their clipboard control code to 1337. |
Where exactly? 8.3.89 OSC - OPERATING SYSTEM COMMAND does not mention fonts. I don't see anything relevant when searching for |
The |
@acook I think there may be some confusion here.
Not exactly. iTerm still interprets |
It seems to me that XTerm's font implementation is certainly based on the ECMA-48's FNT, even if they chose This is not to justify XTerm dictating the design of all other terminals, but this pattern is useful for library and application developers like me that want to use advanced font features when they're available. This sequence is supported by at least 5 other terminals today outside of XTerm. If we want to have a different standard, then developers beyond the XTerm team need to work together to define it. Entirely bespoke or unreliable workarounds are not realistic to maintain, so we as terminal application and library developers will have to pick and choose what ones to support. I'm happy to help however I can to facilitate this.
Their documentation says that " But I just tested the latest release of iTerm from December and you are correct. Not an ideal situation. Thank you for the additional information! |
Escape sequences to set fonts and their attributes are ignored, instead they are displayed as raw
Terminals support escape sequences to alter the fonts. Windows Terminal at the moment only support basic colors and reverse colors
This is linked to #109 #2916 #5461 #5462 #6703 and #6205 as currently most of the VTE52 font attributes are not supported.
Full support can be tested with:
https://github.com/csdvrx/sixel-testsuite/ansi-vte52.sh
Expected output:
https://github.com/csdvrx/sixel-testsuite/blob/master/test-passed-part1.jpg
It would be desirable to support all mintty font attributes, including support for alternative fonts, using ECMA-48 SGR codes. This would be linked to #1163 for usecases like CJK.
Mintty patch implementing this is on mintty/mintty@1250829
This allows sequences like:
echo "\e[12mVery thin font\e[0m"
The text was updated successfully, but these errors were encountered: