Xterm.js: Support setting font weight

[Tyriar]

VS Code issue: https://github.com/Microsoft/vscode/issues/29887

Some users would like to be able to set their standard font weight to something other than "normal". This needs to be supported by the new renderer.

[Tyriar]

Open to PRs, this will involve adding a new option https://github.com/xtermjs/xterm.js/blob/a6899c74d838e68bc58fb41f718fd7796b9240b2/typings/xterm.d.ts#L14 and making BaseRenderLayer aware of it (that's the class that draws the text).

[nikonso]

I'd like to grab this 😄

One quick question tough, in the VS Code issue there's the following comment:

This setting would conflict with the "terminal.integrated.enableBold" setting that currently exists. Should it override that setting if the font weight is set to bold or a higher weight?

What should we do in this case?

[Tyriar]

@bmf-ribeiro cool :smiley:

Thinking about it some more, they should probably live together:

• enableBold: Makes bold text act like non-bold text
• fontWeight: Sets the boldness of non-bold text, eg. 100, 200, bold, etc. (the formats accepted by CanvasRenderingContext2D.font

So when enableBold is false and fontWeight is set to "bold", that means that all text is bold.

The only thing I'm not sure about right now is what sort of values we should accept, ie. what level of validation should we use.

[mofux]

Well, the most reasonable way to get this done would be to make both, the normal and bold font weights configurable (normal, bold, bolder, 100, 200, ...).

term.setOptions({
  normalFontWeight: 'normal',
  boldFontWeight: 'bold'
})

if enableBold is false, we would always use the font weight that is configured fornormalFontWeight...

[Tyriar]

make both, the normal and bold font weights configurable

I considered this in the VS Code issue, setting the normal part is the main requirement on the VS Code side to align with the editor setting. Apparently boldFontWeight was not considers when the editor.fontWeight setting was added though (as bold is not used as much as in the terminal). Anyway, 👍 to doing both 😄.

For ordering reasons flipping the wording might be a good idea; fontWeight (fontWeightNormal?), fontWeightBold

If we're doing both then maybe enableBold should be removed and if people want to implement it they can do it by setting fontWeightNormal and fontWeightBold. VS Code should be the only consumer right now.

[theflyingape]

To me, enableBold does not translate to the rendering I anticipated. It renders the font style 'normal' as expected, but it also uses the normal palette color and not the "bright" equivalent. With enableBold = false, I expect to see, i.e., white (#c0c0c0) and brightWhite (#ffffff) using the normal font style.

[Tyriar]

@theflyingape if I recall correctly terminals behave a little inconsistency in regards to using the bright color on bold by default. If we allowed this to be configurable (use bright for bold), then we would get the behavior you're after. I'd want to check how most terminal act and what options they expose in regards to this before committing to it though.

[theflyingape]

Understood clearly. I think just the two parameters as described could handle all cases sought in fontWeightNormal and fontWeightBold. That is, if the common character attributes are Normal and Bold, I think the fontWeight configurations for them are good to handle both situations: one could set the BoldWeight = NormalWeight if changing style is _not_ wanted.

As far as determining whether Bold in that same context also Brightens the color, then I can see why enableBold works the way it does now (as brighten or don't brighten) for that convenience. But like the fontWeights, couldn't I get the same net effect by having the normal 8 palette colors as the same for the 8 bright colors defined in my theme?

My experiences with many console emulators is most provide a flag to enable/disable applying changes (bold, italic) to the font style only. I cannot recall any emulator opting _not_ to alter intensity for the normal/bold sequence: monochrome (lol, dating myself) or color.

[didenko]

¢2, in reference to the font settings in _VS Code_'s integrated teminal use of _xterm.js_:

I am not sure a non-font-fluent user will be able to translate their OS font selector interface to proposed settings. I did not look up how that works on _Windows_, but here is a _macOS_ example:

In this context a "Typeface" sub-key may be best on _macOS_. There is also a question of Italic and such...

I know some backend developers who would prefer to avoid that cognitive load mapping typefaces to weights. And they are the ones who use the terminal a lot.

AFAIK currently _VS Code_'s "terminal.integrated.fontFamily": "Roboto Mono Light" breaks rendering. Could it be done that a typeface can be specified? How compatible would it be with the fontWeight setting?

[didenko]

Here is how Google does it at the example selection at https://fonts.google.com/?selection.family=Roboto+Mono:300,300i :

Could it be done that the setting accepts a combination of case insensitive italic and weights as strings? Should it be called something else then?