Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Increase whitespace between lines by default #74

Open
effinsky opened this issue May 26, 2023 · 7 comments
Open

Increase whitespace between lines by default #74

effinsky opened this issue May 26, 2023 · 7 comments

Comments

@effinsky
Copy link

effinsky commented May 26, 2023

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:

Screenshot 2023-05-26 at 12 37 53

Screenshot 2023-05-26 at 12 38 42 Screenshot 2023-05-26 at 12 38 21

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
Copy link

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
Copy link
Owner

blobject commented Jun 1, 2023

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: #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
Copy link
Author

effinsky commented Jun 2, 2023

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
Copy link

clort81 commented Dec 20, 2023

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
Copy link
Author

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
Copy link

instead of getting upset, you could have a look at #62 and the source to fine tune it yourself?

@blobject
Copy link
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants