4 ms·
The concept of changing "line height" seems completely broken for monospace fonts. Changing the line height of a monospace font makes line-drawing characters (l
by JoshTriplett 6y ago
The concept of changing "line height" seems completely broken for monospace fonts. Changing the line height of a monospace font makes line-drawing characters (lines, boxes, etc) fail to line up, either by overlapping or by having gaps between them.
This gist shows an example of the problem; GitHub's CSS breaks this property of monospace fonts: https://gist.github.com/joshtriplett/dc2446716999c54cc9a5c48d67a88ca7 https://gist.github.com/joshtriplett/dc2446716999c54cc9a5c48...
- kevincox 6y agoI agree, by default I would want to trust the line height of my font designer, just like I trust their letter spacing. I very rarely use multiple fonts on the same line (maybe a monospace font for inline code?).
- JoshTriplett 6y agoRight. If you're mixing multiple fonts on the same line, the default should be the maximum line height of the fonts, unless overridden.
- tonsky 6y agoMany fonts are designed so that you’ll set at least 1.2 line height. 1.0 barely fits the characters themselves
- tonsky 6y agoThose should not be drawn by font. I believe the only way is for the app, e.g. terminal, to intercept and draw them directly, not through the font. Otherwise you’ll get horizontal gaps too https://github.com/tonsky/FiraCode/issues/449 https://github.com/tonsky/FiraCode/issues/449
- JoshTriplett 6y agoThat looks like a rendering bug in the application. There's no fundamental reason they should have either horizontal or vertical gaps, if character cells are rendered at the correct size.
- tonsky 6y agofont metrics are fractional at most sizes. You can optimize font for one particular size, but for any other, there will be gaps