Additional options for lineHeight option (fractional height, pixel height)

[sholalkere]

(Note, all screenshots were taken with webgl enabled.)
Some, fonts, e.g. Comic Code, appear to have too large of a line height even with lineHeight = 1.

Fractional line heights would allow for what I believe is a more reasonable spacing in between lines.

I think there should be support for for fractional line heights, and line heights specified in pixels (as suggested in #2612).

My proposal is to follow VSCode's convention for handling lineHeight (with some modifications).

First, instead of allowing lineHeight = 0, the user can just use lineHeight = 1, which already computes the line height from the character height.
Next, if 0 < lineHeight <= 8, the line height can be treated as a multiplier for the character height (as it is currently).
Finally, if lineHeight > 8 the line height is exactly what is specified (in pixels).

These fixes can be implemented relatively quickly with something like the following in CanvasRenderer.ts and WebglRenderer.ts (and of course modifying the allowed bounds in OptionsService.ts).
this.dimensions.device.cell.height = this._optionsService.rawOptions.lineHeight > 8 ? this._optionsService.rawOptions.lineHeight : Math.floor(this.dimensions.device.char.height * this._optionsService.rawOptions.lineHeight);

One potential downside is that characters can potentially be too large for the cell and are thus cut off, but I believe this behavior is fine if one is willing to stray from within the multiplier bounds (and I'm not sure how many users uselineHeight as a multiplier for something greater than 8 so effectively no functionality is lost). Furthermore, the way VSCode handles this, for example, is allowing characters to overlap, which I believe leads to a similar loss in clarity.

[Tyriar]

I didn't like the 0-8 special case initially but it does seem to have solved most problems without needing to introduce another setting so it's growing on me.

[jerch]

I also stumbled about the whole dimension calculation during the DOM PR, mainly when trying out different settings for the inline patch (not done yet).

I got the following picture of the whole grid size mechanics - ideally we bind our terminal grid to integer cell sizes. This is somewhat needed to make size reports properly working (sadly the sequences can only report in integers). This also means, that the whole text area / canvas size should be a perfect multiple of that integer cell size in both dimensions (which is currently not the case, at least in x direction).

That restriction is a big bummer, but kinda the only way we can make the size reports work properly. It makes the styling of terminal font sizes and resulting grid sizes very restrictive, and more annoyingly - will give the terminal a quite different style output than the rest of the embedding page.
So not sure yet, what to make of this - the proposed fractional height here def. does not work within these restrictions.

(A different solution to the integer issue would be to introduce a virtual coord system with custom points resolution on grid cells, but thats quite involved to get done right ...)