[HN Gopher] Font size is useless; let's fix it
___________________________________________________________________
Font size is useless; let's fix it
Author : garaetjjte
Score : 5 points
Date : 2023-05-13 15:34 UTC (7 hours ago)
(HTM) web link (tonsky.me)
(TXT) w3m dump (tonsky.me)
| azornathogron wrote:
| There is some useful information here, but I'm a little doubtful
| about some parts.
|
| Specifying font size in terms of cap-height is ok, and I do agree
| it's kind of annoying that when using the normal font size metric
| two different fonts with the same nominal size can actually be
| visually very different. However I think there are some
| collections of fonts (collections of font families really)
| created together where the sizes are supposed to harmonize. For
| example, Sans / Serif / Mono families of a single collection like
| the Noto fonts are probably (I say probably because I haven't
| checked! Someone correct me!) designed together so that, eg, some
| mono text inline in a sans paragraph will look "right" when the
| same _nominal_ font size is used for both. If you specify cap-
| height instead you might subtly break that aspect of the design.
|
| But I agree it generally doesn't work to do that for totally
| separate families (Noto sans + Courier Prime or whatever), and
| then cap-height will probably give better consistency and be a
| better starting point.
|
| > I see no reason to honor the so-called "default line-height".
| It's basically a font designer's personal preference
|
| Well, the whole design of the font is "a font designer's personal
| preference". Or to put it the other way around, line height (like
| letter spacing and other metrics) is _part of the design_. You
| might choose to adjust the design by changing these metrics but
| the values chosen by the font designer are probably a good place
| to start. It is probably not a good idea (aesthetically) to
| choose your line height independently of the actual font you 're
| using.
|
| Ultimately, there is a lot of subtlety in font design and
| typography, and purely geometrical approaches (eg, based on
| actual computed bounding box) tend to fail. If you want the best
| sizing and spacing, you probably have to work it out by eye for
| an individual font in a particular context. Since you have to do
| that, the fact that sizes are specified using a geometrically
| arbitrary scaling factor is perhaps not a big problem.
| alwillis wrote:
| Safari is shipping leading-trim and margin-trim [1] in current
| versions.
|
| [1]: https://www.webkit.org/blog/13966/webkit-features-in-
| safari-...
| jfultz wrote:
| Yes, there's a lot of messiness in how fonts work. Doing cross-
| platform desktop GUI development, I feel that pain firsthand (and
| not just for fonts, but for all kinds of rendered
| constructs...controls, lines/curves/polys, bitmaps, windows). But
| working with pixels is no solution. On macOS, Retina pixels are
| 1/2 the dimensions of non-Retina pixels (in principle, on Apple
| hardware...actual dot pitches will vary). "Standard" vs. 2k vs.
| 4k vs. 8k monitors (not to mention all the things in between).
| And multiple monitors on the same system might not agree with one
| another. This is especially common with laptops, where there's
| really no particular correlation between the laptop's built-in
| display and the external monitor the user happens to have
| available.
|
| I can't understand why anybody would consider pixel measurements
| a viable solution at all. My best attempt to understand what the
| blog author is wanting to achieve is maybe he wants to fine-tune
| appearances on his system in a way that doesn't need to be
| portable. He talks about customizing editor appearances, and I
| suppose that editors generally don't have the problem of having
| to do something sensible across multiple systems. But even there,
| at least some people are still going to have the disagreeing-
| multiple-monitors problem.
___________________________________________________________________
(page generated 2023-05-13 23:02 UTC)