Increase whitespace between lines by default

[effinsky]

With default line height settings in ITerm2 and other terminal emulators, the font is considerably more vertically "crowded" than Consolas or Jetbrains Mono, both of which are fantastic in this regard out of the box. This requires increasing line height, but terminal emulators save for ITerm and some others are notoriously bad for that, stretching the cursor vertically to make it look crappy.

Here's a reference for default line height settings:

I think even a slight increase in whitespace would go considerable way towards making Agave feel better to use. It's still great and I understand if there's no time for this.

[alexmyczko]

reminds me of the "they are the same image" meme ;) seriously, i think terminals should have a setting for line height similar to wysywig word processors.

[blobject]

Thanks for the feedback, effinsky. You pose a valid complaint, and this line-height question did figure into the initial design.

My opinion, however, is that the current crowded behavior best aligns with the font's design. While adding vertical padding within the font definition is possible, I feel that it will throw off the numeric consistency (for example, the glyph box would no longer be the neat 1024x2048, with 1:2 ratio, but some 1024x2yyy). It seems that configuring the application is an easier and cheaper solution to this issue, although I understand that not all applications do this well. I agree with alexmyczko, terminals definitely need to be on top of this.

To give an example of what I mean by "numeric consistency", see for example the "a" template screenshot in agave's readme. It shows an 8-part division with the "a" glyph occupying exactly the middle 4 slots. A glyph with a descender, like "g", would occupy an additional slot below the middle 4.

An unfortunate consequence of this is the too-crowded look. On the flip side, the crowdedness "maximises" the number of lines that a terminal can show (see also: https://github.com/blobject/agave/issues/15). I believe the user (and therefore the application) should ultimately decide what they are comfortable with, but the font definition should remain faithful to the underlying design.

[effinsky]

thanks for the exhaustive response! I think it'd be cool if terminal emulators took care of decent line height rendering options, but they do not, with some notable exceptions. in fact, the responses I got from the maintainers on this matter have been outright dismissive so far.

so I understand you aim for a certain balance in the fonts total composition. would you consider creating an alternative variant with increased whitespace, perhaps? wherever this lands, I appreciate your efforts.

[clort81]

LibVTE based terminals allow insertion of blank space between rows in the terminal program.

This is not a job for your terminal font.

To correctly emulate a serial terminal, the terminal must have contigous joining character cells. Bottom of above row should abutt top of current row.

[effinsky]

nobody does this in code nowadays and they won't. the point is to have sane readability settings as we actually use terminals and other editing environments. terminals do a s**t hob of handling line height (beyond iterm2, which I love in this respect). it IS the job of a font to make itself readable, in my opinion, 100%. any font. especially if the context, in this case terminal, does not occupy itself with this.

fortunately great fonts like source code pro, consolas, operator mono, jetbrains mono are wonderful out of the gate here and require relatively little -- or none, for some people -- additional terminal line height increase.

my 2 cents.

[alexmyczko]

instead of getting upset, you could have a look at https://github.com/blobject/agave/issues/62 and the source to fine tune it yourself?

[blobject]

Oh, I missed effinsky's suggestion of providing a variant with a larger gap. That sounds like a good solution. Unfortunately, I've cleared up my dev environment and have been busy with other stuff. So I'll get to this when I find some time / stop being so damn lazy.

As for the discussion, I feel that the line height setting can only be opinionated. In most use cases, a relaxed and generous gap looks great. But in particular use cases like administering a system or going through logs in a terminal where the number of visible lines is critical, I would say, the smaller the gap the better.