terminal icon indicating copy to clipboard operation
terminal copied to clipboard

Relatively "more bold" discussion

Open zadjii-msft opened this issue 4 years ago • 13 comments

A follow up to #10498.

If the user already has a bold font selected, should we make the font for bold text even more bold?

Options:

  • when the user has a bold font, leave intense text just bold
  • increase the font weight EVEN MORE, so bold text becomes extra bold (up to a sensible max)
    • how does this play when the user's default font weight is something like extra-light? does extra-light -> light -> normal -> bold -> extra-bold?
  • possible have a setting to switch between the above behaviors? (might be overkill)
  • Allow the user to specify a custom "bold text font weight", so they could have extra-bold text by default, and "bold" text we could render as extra-light (if you're a crazy person) (also overkill)

Relevant comments:

https://github.com/microsoft/terminal/issues/109#issuecomment-743929268 is probably the comment you're looking for?

Just multiply by 1.75, cap it at 1000, and call it a day, perhaps. I run font weight 450 locally ("Retina" weight) rather than 400, so this would come out closer to Extra Bold than Bold, which seems reasonable to me. If the font doesn't support variable-width, let DirectWrite work out which weight instance to pick.

If it's helpful, CSS defines its own transformation for bold, but that doesn't allow for variable-weight fonts, it relies on their font rounding calculation to pick a "named" weight first, then enbolden it. I would expect DirectWrite to do that for us.

et al in https://github.com/microsoft/terminal/pull/10498/files#r657675585.

zadjii-msft avatar Jul 07 '21 16:07 zadjii-msft

For the record, I dig this "multiply by 1.75, cap at 1000" option personally. I doubt this needs to be configurable, and the scaling font weight seems like it'll work in most cases. We could even limit it to solely the case where the font weight is already >=bold if we wanted.

zadjii-msft avatar Jul 07 '21 16:07 zadjii-msft

Posting some thoughts I have on this...

I think when it comes to "bolder than the chosen weight" this is a sensible idea.

When a font has limited weights, then Normal and Bold tend to be the only options, but some fonts may only be a single weight.

Some apps have a "simulated bold" which could be used for the single weight fonts.

When the font range is a little wider, perhaps for anything below Bold, the bold command could switch to the next instance up? - So Light, would use Semi Light or Regular;

  • Semi Light would use Regular or Bold;
  • Regular would use Semibold or Bold;
  • Semibold would use Bold, Extrabold, or Black;

But then when the font weight chosen is bold, then what happens after would need some consideration.

If there is a Black or Extra Bold weight, then that gives you a place to go, but there may need to be a simulated bold option for fonts with only Regular and Bold options. Adobe supports a Faux bold, and I am sure Direct Write supports this too.
This may impact readability, so perhaps there could be a warning in the settings UI when a heavy weight is chosen?

For Variable fonts you may have a Weight axis to increase on, as well as the established instances.

mdtauk avatar Jul 07 '21 16:07 mdtauk

If you already are using a chonky font weight... couldn't wrapping over to the thin weights symbolize the same sort of emphasis of text that "bold" signaling would be used for? Like don't cap at 1000.... overflow back down to 100.

miniksa avatar Jul 07 '21 20:07 miniksa

Or if your normal text is already heavy-weight, bold could be like this?

That's a clearly perceptible difference, but probably not ideal in a fixed-width terminal layout.

TBBle avatar Jul 07 '21 20:07 TBBle

Or if your normal text is already heavy-weight, bold could be like this?

That's a clearly perceptible difference, but probably not ideal in a fixed-width terminal layout.

Spacing would break for richer output like with pseudo GUIs.

If you already are using a chonky font weight... couldn't wrapping over to the thin weights symbolize the same sort of emphasis of text that "bold" signaling would be used for? Like don't cap at 1000.... overflow back down to 100.

Wrapping around has a sort of logic too it, but I suspect it may lead to an onslaught of github issues calling it out as a bug.

mdtauk avatar Jul 07 '21 20:07 mdtauk

I'm more concerned about how other terminals handle this particular scenario, especially the long-standing veterans, for example GNOME terminal.

skyline75489 avatar Jul 08 '21 06:07 skyline75489

I'm more concerned about how other terminals handle this particular scenario, especially the long-standing veterans, for example GNOME terminal.

If you're going to be looking at GNOME Terminal for inspiration, I'd suggest testing older versions too. I can't find the issue now, but I know there were complaints fairly recently about a VTE update that broke bold font handling in some way, and I'm almost sure the issue was with users that were setting their default font weight to bold, and VTE wasn't respecting that choice anymore (or something along those lines).

j4james avatar Jul 08 '21 09:07 j4james

Thanks James for the info about GNOME terminals. Also the fact that people do care about the behavior when setting the default font weight to bold.

获取 Outlook for iOShttps://aka.ms/o0ukef

skyline75489 avatar Jul 08 '21 11:07 skyline75489

I just came across the CSS Fonts 4 draft and it has a "bolder" algorithm that accounts for variable-weight fonts.

Currently, that's

image

where "Inherited value" is the value to which bolder or lighter is being applied, i.e. the current font weight. It's pretty much the same rule from the current CSS Fonts spec, with rounding done for you.

So that is another externally-justifiable approach to "bold when the user overrides fontWeight but not boldFontWeight".

I'm not sure I like it more than the "multiply by 1.75" approach (which is nice and simple, but probably too linear as you move away from 400), but better to have this approach visible in this discussion than ignore it.

TBBle avatar Dec 01 '21 10:12 TBBle

kitty handles this by offering configuration settings for the standard font face, bold, italic, and bold-italic: https://sw.kovidgoyal.net/kitty/conf/#opt-kitty.font_family

I can see the merit of auto-calculating a "bolder" font when there isn't one manually specified, but wouldn't it be more straightforward to offer similar, per-font-type configurability? Even if an auto-bolder algorithm does get implemented, it still makes sense to have this configuration. A user might want to use a completely different font family to emphasize bold text, or they might want to specify a special script variant of a font for italics.

jaminthorns avatar Feb 08 '22 00:02 jaminthorns

I'd say just do what every other terminal does: there are two weights you can set: one for normal, one for bold. Let users just do whatever weird stuff they want with that.

Diablo-D3 avatar Jun 25 '22 08:06 Diablo-D3

Bold is waaay too bold when using light or semi-light font now. I'd love to be able to customize this.

majocha avatar Oct 24 '22 18:10 majocha

Makes sense to me, the font I'm using (a variable of Iosevka) provides 9 weights from Extra-Light to Extra-Black (and also has variable weight up to 990). Perfeably, I would set weight to Semi-Bold or Bold, but that's where I can barely tell the difference between intense text and normal one. If I increase weight more, the bold text became relatively thinner (laugh)

horror-proton avatar Dec 15 '22 03:12 horror-proton

I think we should allow the user to choose the font(and weight) used for bold text. That would be a quick workaround.

acomagu avatar Aug 17 '23 05:08 acomagu