xtermjs/xterm.js

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

Open

#4 463 ouverte le 31 mars 2023

Voir sur GitHub
 (2 commentaires) (0 réactions) (0 assignés)TypeScript (1 574 forks)batch import
area/addon/webglarea/renderer-domhelp wantedtype/enhancement

Métriques du dépôt

Stars
 (16 196 stars)
Métriques de merge PR
 (Merge moyen 4j 3h) (81 PRs mergées en 30 j)

Description

(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.

Guide contributeur