Open zadjii-msft opened 3 years ago
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.
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;
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.
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.
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.
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.
I'm more concerned about how other terminals handle this particular scenario, especially the long-standing veterans, for example GNOME terminal.
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).
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
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.
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.
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.
Bold is waaay too bold when using light or semi-light font now. I'd love to be able to customize this.
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)
I think we should allow the user to choose the font(and weight) used for bold text. That would be a quick workaround.
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:
Relevant comments:
et al in https://github.com/microsoft/terminal/pull/10498/files#r657675585.