Repository navigation
Epic: Add configuration options for font rendering things (fallback, line height, ligatures, ...) #1790
Description
### Tasks
- [x] #759
- [ ] #2664
- [x] #1298
- [ ] #5093
- [ ] #3498
- [ ] #956
- [x] #1751
- [x] #5828
- [x] #6049
- [ ] #10231
consider (backlog)
- Permit fractional 0.5 sized font scaling #6678 should we support fractional point sizes?
original content
This is a summary from #714 #455
- To properly handle box drawing characters we may need ability to explicitly set line height in pixels (to avoid rounding error). We may also need baseline position settings to avoid clipping.
- For the arrow issue, we may need the ability to support specifying a fallback sequence of fonts rather than a master font, pretty like how CSS works.
- We may also need some method to allow WT to change how it measure characters in a fallen font?
- Option for antialiasing modes — at least for the case that the console's background isn’t transparent.
Reacted by obskyr, Mustafa Mohamad, ExE Boss, Liu Yuhui, Trevor N. Suarez, Vũ Văn Dũng, Yasuaki Gohko, 谢政, Chao Shi, vizmoe and 50 more
Activity
DHowett-MSFT commentedon Jul 8, 2019
Should we should move these things into #759 and make that the master issue for font rendering options? Michael Niksa (@miniksa).
DHowett-MSFT commentedon Jul 8, 2019
Congrats, this is now the epic for font rendering settings.
[-]Give the ability to explicitly set line height, baseline position and font fallback sequence[/-][+]Epic: Add configuration options for font rendering things (fallback, line height, ligatures, ...)[/+]be5invis commentedon Aug 2, 2019
I think one more interesting thing is to redefine certain characters' "width", in both rendering and cell allocation. For example, if someone is working frequently with Japanese applications, they may want box-drawing characters to become full-width.
obskyr commentedon Sep 20, 2019
Eagerly awaiting this in general, but perhaps especially for disabling ligatures and changing line heights.
musm commentedon Oct 26, 2019
I agree this would be "epic"
mdtauk commentedon Nov 11, 2019
Colour vs Monocoloured Emoji's would be a good option to include too
mdtauk commentedon May 20, 2020
Could this be a good away to handle the Block Drawing characters? Enable Terminal to override the font characters, so even with increased line spacing, the various shapes and lines will still connect horizontally, vertically, and diagonally. #5897 #5743 #455
DHowett commentedon May 20, 2020
Martin Anderson (@mdtauk) #5897 is a better place to discuss that.
mdtauk commentedon May 20, 2020
Sure to discuss the implementation, but I meant would the font section of the settings be the best place to handle allowing an override option?
waf commentedon Nov 4, 2020
I suspect the "font fallback" task may become more highly requested when oh-my-posh v3 is released (it's currently in beta). It defaults to using characters that aren't in Cascadia Code, so without font fallback many people will have to switch to one of:
Another alternative is adding the missing characters directly to Cascadia Code, which would sidestep the font fallback. Aaron (@aaronbell) was trying to get approval for that in microsoft/cascadia-code#210 (comment)
rbeesley commentedon Mar 26, 2021
I'd really like to see the option of handling 1m and 2m attributes as bold/light font weights and/or brighten/diminish intensity. Looking across the landscape of terminal programs for different platforms, bold/intensify is implemented differently, sometimes as font weight, sometimes as intensify, using brblack instead of black for instance, and sometimes both.
With the implementation of 2m/dimming it applies across all terminal colors. Obviously if the terminal color is already floored, like black #000, then it can't go lower, but brblack doesn't render the same as black. With 1m/bold/intensify, it doesn't try to brighten 30m-37m, but instead the range just shifts up to 90m-97m and 90m-97m remain the same. In this case black becomes brblack. This means that while 1m and 2m are somewhat complimentary, they aren't in their current implementations.
Font weight would be a good solution which gives the attributes meaning across the entire range of terminal colors. Likewise an intensity attribute implemented in a similar way to diminish would also give value across the full range. I think maintaining a compatibility mode would be appropriate, but for modern terminals with a palette of more than 16 colors, these changes would benefit the user. If using a Solarized theme for instance, 1;31m wouldn't be expected to be orange, it should be a bold/intensified red. It almost certainly shouldn't shift into different hues as some of the base* colors might with the current implementation, green for instance.
Edit: Looking at the links zadjii-msft added below, I'm not sure I'm contributing further to the discussion. I had already left some comments in those threads and someone else called out the problem with Solarized. Leaving this comment here as it is still relevant, but I'll redirect my efforts to one of these other issues as appropriate.
zadjii-msft commentedon Mar 26, 2021
Ryan Beesley (@rbeesley) FYI #109 has a much longer and specific discussion of
1mthan this thread - it's dedicated to just the "bold text" discussion.actually, after looking through #6879, the discussions are in:
#109, #5682, #6703 / #6873, #2916 (comment)
Group font options in the json into a single object (#10433)
Spec for font features and axes of variation (#10457)
Allow users to set font features and font axes (#10525)
Add support for turning off full-color Emoji (#16871)