be5invis commented 5 years ago

### Tasks
- [x] #759
- [ ] #2664
- [x] #1298
- [ ] #5093
- [ ] #3498
- [ ] #956
- [x] #1751
- [x] #5828
- [x] #6049
- [ ] #10231

consider (backlog)

[x] #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 commented 5 years ago

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

DHowett-MSFT commented 5 years ago

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

be5invis commented 5 years ago

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 commented 4 years ago

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

Source Code Pro

Lucida Sans Console

musm commented 4 years ago

I agree this would be "epic"

mdtauk commented 4 years ago

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

mdtauk commented 4 years ago

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 commented 4 years ago

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

mdtauk commented 4 years ago

@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 commented 3 years ago

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 https://github.com/microsoft/cascadia-code/issues/210#issuecomment-561490170

rbeesley commented 3 years ago

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 commented 3 years ago

@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:

2916#issuecomment-544880423

microsoft / terminal

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

consider (backlog)

original content

109, #5682, #6703 / #6873, https://github.com/microsoft/terminal/issues/2916#issuecomment-544880423