Epic: Add configuration options for font rendering things (fallback, line height, ligatures, ...)

[be5invis]

Tasks

Beta Give feedback

1. Investigate/implement renderer setting to disable ligatures #759
   Area-Rendering Help Wanted Issue-Task Priority-3 Product-Terminal Resolution-Fix-Committed +6
2. Allow for the configuration of font fallback #2664
   Area-Fonts Area-Settings Help Wanted In-PR Issue-Task Needs-Tag-Fix Product-Terminal +7
3. Feature Request: Antialiasing mode options #1298
   Area-Rendering Area-Settings Help Wanted Issue-Task Priority-3 Product-Terminal Resolution-Fix-Committed +7
4. Add a setting to control vertical antialiasing #5093
   Area-Rendering Help Wanted Issue-Task Product-Terminal +4
5. Add preference to customize vertical line spacing #3498
   Area-Rendering Area-Settings Help Wanted In-PR Issue-Task Needs-Tag-Fix Product-Terminal +7
   
6. [Settings] An option to disable colour font emoji #956
   Area-Rendering Area-Settings Help Wanted In-PR Issue-Task Needs-Tag-Fix Priority-3 Product-Terminal +8
7. Add support for configuring Font Weight #1751
   Area-Rendering Area-Settings Issue-Task Product-Terminal Resolution-Fix-Committed +5
8. Request: Support for Font Width Variants #5828
   Area-Settings Area-TerminalControl Issue-Task Product-Terminal Resolution-Fix-Committed +5
9. Consider grouping font options in the json into an object #6049
   Area-Settings Issue-Task Needs-Tag-Fix Product-Terminal +4
10. Italics look awkward and are hard to read (possibly different font entirely?) #10231
    Area-Fonts Issue-Task Needs-Triage Priority-3 Product-Terminal Resolution-By-Design Resolution-External +7

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.

[DHowett-MSFT]

Should we should move these things into #759 and make that the master issue for font rendering options? @miniksa.

[DHowett-MSFT]

Congrats, this is now the epic for font rendering settings.

[be5invis]

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]

Eagerly awaiting this in general, but perhaps especially for disabling ligatures and changing line heights.

[musm]

I agree this would be "epic"

[mdtauk]

Colour vs Monocoloured Emoji's would be a good option to include too

[mdtauk]

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]

@mdtauk #5897 is a better place to discuss that.

[mdtauk]

@mdtauk #5897 is a better place to discuss that.

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]

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:

• Meslo, as recommended by the oh-my-posh project
• Caskaydia Cove, the nerd-font patched version of Cascadia Code

Another alternative is adding the missing characters directly to Cascadia Code, which would sidestep the font fallback. @aaronbell was trying to get approval for that in microsoft/cascadia-code#210 (comment)

[rbeesley]

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]

@rbeesley FYI #109 has a much longer and specific discussion of 1m than 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)