Relatively &#34;more bold&#34; discussion #14416

@zadjii-msft commented on GitHub (Jul 7, 2021):

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 commented on GitHub (Jul 7, 2021): 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.

claunia commented

@mdtauk commented on GitHub (Jul 7, 2021):

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 commented on GitHub (Jul 7, 2021): 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.

claunia commented

@miniksa commented on GitHub (Jul 7, 2021):

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 commented on GitHub (Jul 7, 2021): 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.

claunia commented

@TBBle commented on GitHub (Jul 7, 2021):

Or if your normal text is already heavy-weight, bold could be like ｔｈｉｓ?

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

@TBBle commented on GitHub (Jul 7, 2021): **Or if your normal text is already heavy-weight, bold could be like ｔｈｉｓ?** That's a clearly perceptible difference, but probably not ideal in a fixed-width terminal layout.

claunia commented

@mdtauk commented on GitHub (Jul 7, 2021):

Or if your normal text is already heavy-weight, bold could be like ｔｈｉｓ?

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 commented on GitHub (Jul 7, 2021): > **Or if your normal text is already heavy-weight, bold could be like ｔｈｉｓ?** > > 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.

claunia commented

@skyline75489 commented on GitHub (Jul 8, 2021):

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

@skyline75489 commented on GitHub (Jul 8, 2021): I'm more concerned about how other terminals handle this particular scenario, especially the long-standing veterans, for example GNOME terminal.

claunia commented

@j4james commented on GitHub (Jul 8, 2021):

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 commented on GitHub (Jul 8, 2021): > 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).

claunia commented

@skyline75489 commented on GitHub (Jul 8, 2021):

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 commented on GitHub (Jul 8, 2021): 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 iOS<https://aka.ms/o0ukef>

claunia commented

@TBBle commented on GitHub (Dec 1, 2021):

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

Currently, that's

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 commented on GitHub (Dec 1, 2021): I just came across the [CSS Fonts 4 draft](https://www.w3.org/TR/css-fonts-4/#relative-weights) and it has a "bolder" algorithm that accounts for variable-weight fonts. Currently, that's ![image](https://user-images.githubusercontent.com/138397/144211052-c750d3ef-cee9-479b-8950-d2807850ddf9.png) 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.

claunia commented

@jaminthorns commented on GitHub (Feb 8, 2022):

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 commented on GitHub (Feb 8, 2022): [kitty](https://sw.kovidgoyal.net/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.

claunia commented

@Diablo-D3 commented on GitHub (Jun 25, 2022):

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 commented on GitHub (Jun 25, 2022): 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.

claunia commented

@majocha commented on GitHub (Oct 24, 2022):

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

@majocha commented on GitHub (Oct 24, 2022): Bold is waaay too bold when using light or semi-light font now. I'd love to be able to customize this.

claunia commented