33 ms·

Let’s fix font size

• ineedasername 6y ago
  You can't fix font size without also addressing printing. 72 may have been chosen as the PPI due to Mac monitors at the time, but it wasn't just for the on-screen size: It also meant that what you printed out on paper would be certain size as well. The roots in physical printing is precisely why there can a disconnect between screen size and text size: The bedrock assumptions that were baked into the system were targeting desktop publishing. That's still the case today: 12pt font on a 13" 1080p screen will print may look a lot smaller than 12pt font on a 24" 1080p display, but when you hit the print button they will both be the exact same size on paper.
  • tracker1 6y ago
    I think TFA is mistaken on it being mac sizing... afaik, 72pt/inch for printing pre-dates the mac.. and 12pt meaning 6 rows per inch was pretty standard long before computers[1] Also, if ppi is reported correctly on the device/os (usually isn't), rendering is actually pretty close most of the time. https://en.wikipedia.org/wiki/Point_(typography) https://en.wikipedia.org/wiki/Point_(typography)
• lucideer 6y ago
  Worth noting this article is discussing OS-level native app font-sizes, and is quite separate to discussions of CSS `font-size` on the web, for which this "problem" is well-known and `px` is the commonly used unit. Also: > P.S. VS Code seems to take editor.fontSize value directly in pixels. That’s a start! I presume this is just the result of VS Code being Electron/HTML/CSS, rather than MS deliberately "fixing" the issue explicitly for this app.
• grenoire 6y ago
  This is also a very big pet peeve of mine, Mr Author. I'm honestly more frustrated when I want to have multiple systems with different fonts at least look similar in 'space occupied,' whereas the lettering being slightly different is just... really a whatever matter.
• belinder 6y ago
  Not sure if capital letter size would catch scenarios with little circly swirls that make other characters taller than capital letter characters
• jfk13 6y ago
  > The solution > - Specify cap height, not em square size. > - Specify it in pixels. Specify cap height, really? How does that work for Arabic or Tibetan or Mongolian (or ..., or ...) -- so many writing systems where "cap height" is meaningless, because there are no "capital letters" and no single dimension that is common across most characters in the set? Not all the world uses English. Specify it in pixels? So if I set my editor font size to 16 pixels, on my MacBook's display, with 226 pixels per inch, the 16-pixel tall letters will be somewhat less than 2mm tall, if I've got the calculation right. Move the window to my external FlexScan display and that same 16-pixel letter will now be 4.32mm tall.
  • skrebbel 6y ago
    Oh come on, this entire article is obviously about Latin typography. Other scripts are simply out of scope. You'll find that nearly all typography articles focus on a single script they way. Often that's Latin because of its widespread use in the west, but not always. There's no racism here. Articles about pizza aren't dismissive of kebab.
    • kps 6y ago
      For Latin, x-height is much more important than cap height, in particular for selecting compatible sets of fonts.
    • akersten 6y ago
      > . Other scripts are simply out of scope. Luckily, the font engine developers for popular operating systems did not scope those issues out just because they were inconvenient for designers who falsely assume that "16" should mean an arbitrary part of a letter in a font is always 16 pixels high. > There's no racism here. No one said there was until you brought it up?
    • jfk13 6y ago
      Nobody said anything about racism. Yes, the article was obviously focused on Latin typography, but it was calling for a user interface change that would affect everyone using the affected software, no matter what language they speak/write.
• ddevault 6y ago
  Something any proposal of this nature tends to be missing is an inquiry into the implications for non-English langauges.
  • rhabarba 6y ago
    You mean, like German?
    • zweifuss 6y ago
      ẞ (capital sharp s; added to Unicode in 2008) and even the much older ß (eszett) are not included in all modern fonts. Sometimes Eszett is simulated with a lowercase β sign even today. Often its size doesn't match the ASCII characters.
      • tonsky 6y ago
        Fira Code has it!
• VWWHFSfQ 6y ago
  > I am using Sublime Text 4 on macOS did I miss when sublime text 4 was released? I'm still on 3
  • jd3 6y ago
    Sublime Text 4 is under private alpha for users with a paid license. https://gist.github.com/jfcherng/7bf4103ea486d1f67b7970e846b3a619 https://gist.github.com/jfcherng/7bf4103ea486d1f67b7970e846b...
    • VWWHFSfQ 6y ago
      oh cool
    • pier25 6y ago
      Oh wow had no idea. Anyone knows what the major changes are compared to v3?
      • ben-schaaf 6y ago
        We just released a teaser on twitter with some of the major changes: https://twitter.com/sublimehq/status/1377088860836913153 https://twitter.com/sublimehq/status/1377088860836913153
        • pier25 6y ago
          Awesome thanks!
  • trinovantes 6y ago
    Oh man, I'm still on 2. I wonder if I can still get discount upgrade from 2->4
• mrob 6y ago
  There are three font sizes with valid uses beyond designers trying to justify their existence: small, medium, and large. Likewise there are three valid fonts: fancy (serif or non-Latin equivalent), plain (sans-serif or non-Latin equivalent), and mono-spaced. This means only 9 font sizes need to be decided. The software can provide reasonable defaults, and a simple UI to allow to user to change them, which won't take long. The only difficulty is when a font doesn't provide full Unicode coverage. Full coverage will have to be assembled from multiple fonts, which means the sizing won't necessarily be consistent. But in this case consistency is already lost, so I see no need to further complicate the UI. The user can still tweak things with fontconfig or equivalent.
  • kbelder 6y ago
    I think this covers 99% of all practical cases. I'd go further, and say that all three sizes and all three fonts should be purely under the control of the client, not the web designer.
• chrisseaton 6y ago
  > Instead, macOS always uses 72 PPI to convert points to pixels. Can't displays report their physical dimensions now? Couldn't this be used to restore using a physical dimension like mm for font sizes? (Please not inches of all things though!)
  • jfk13 6y ago
    It could, but would usually be misused. People would design for the size of display and typical viewing distance that they like to use, forgetting that these things vary hugely. (And that doesn't even begin to address the question of what part of the font you'd be measuring.)
  • dfox 6y ago
    They do and in fact both X11 and Windows are capable of using that information to scale font pixel sizes appropriately. In both cases this mostly defaults to off and fixed DPI for UI font layout because the result of non-default display DPI leads to either the result looking wrong/ugly (blurry text, thickness of font strokes disproportionate to other UI elements etc) or even unusable (there is edge case in Win32 UI where one way to create non-resizable dialog-style top-level application window causes its contents to scale with DPI, while size of the window itself does not -> you get UI elements that are cliped outside of the window).
  • deleted 6y ago
    [deleted]
  • kmeisthax 6y ago
    macOS already does this at the pixel step, by multiplying the entire pixel layout by a scaling term before actually drawing the widgets. So effectively, macOS does not use 72 points-per-inch, it uses 72 points-per-pixel, and then ensures 1 pixel is a particular physical measurement, for the same compatibility reasons that caused us to drop device pixels. The reason why the author is having issues with text sizes on different size monitors is that macOS does not support fractional scaling; and it's high-DPI detection is fairly limited. A non-high-DPI monitor has no scaling options whatsoever, it's locked to 1x. High-DPI monitors are locked to 2x; with the additional option to change the desktop's layout size and scale the resulting image to achieve the effect of fractional scaling. (Apple is really paranoid about introducing rounding errors in pixel-aligned layouts, which is why they handle non-integer displays this way.) BTW, if anyone happens to know how to manually flag a monitor as HiDPI in macOS Mojave (or if I can do it in Catalina/Big Sur), please let me know. I have a 1080p NexDock Touch that I have to run at 720p because macOS won't give me the fractional scaling options on an external monitor.
• PaulHoule 6y ago
  Font metrics is a super-complex topic. I have been digging into old Word documents and it's started to dawn on me why Visual Basic "worked" as GUI builder in a time when its competitors didn't... The font metric system in Windows 95 gave great control, with the ability to position individual characters and more configuration choices (e.g. strikethrough) than most web browsers today. It is way "beyond state of the art" to change the typeface in your text editor easily and have it work. I have lately been doing a project that involves printing onto cards with bitmaps I make with Pillow, and you learn pretty quick that there is no such thing as a "unicode font" but instead you have to patch up your own "unicode font" by putting together a 日本語 font with a nice Latin font, and not worrying about other languages until I have to print them... The web browser and other high-level tools do it automatically but they don't do well.
  • Moru 6y ago
    I have some memories of zooming into a word document and the space occupied by the text was not the same any more... I forget what OS it was running but W95 or earlier is likely.
    • jfk13 6y ago
      Ah, yes... the good ol' days when changing your selected printer driver could also cause Word to reflow your entire document (because it affected the font metrics) and suddenly your carefully-tuned page breaks and figure placements were all wrong.
  • spiznnx 6y ago
    The only "unicode font" I know of is the Noto family. > Noto helps to make the web more beautiful across platforms for all languages. Currently, Noto covers over 30 scripts, and will cover all of Unicode in the future. https://en.wikipedia.org/wiki/Noto_fonts https://en.wikipedia.org/wiki/Noto_fonts
• mcguire 6y ago
  "500 years of typography is useless; let's throw everything out!" "Also, I see no reason to honor the so-called “default line-height”. It’s basically a font designer’s personal preference, imposed on every user of the font in every viewing condition." Yes, that would be "font design".
  • ectopod 6y ago
    I typeset a scanned and ocred copy of an old book. It used a moderately common font except with extremely narrow line spacing. None of the tools I had supported a line spacing narrower than the spacing chosen by the font designer, so I had to create a hacked version of the font to make it work. Traditionally, the leading was separate from the type. Nowadays it isn't, and that can be a huge pain in the bum.
    • JxLS-cpgbe0 6y ago
      Is this app-development specific? In CSS the font-size and leading are easily decoupled.
      • ectopod 6y ago
        I'm not sure what you're asking. As a software developer, supporting negative leading isn't hard, but as an end user (as I was in the example above) that's no help if the software developer hasn't done the work.
    • mcguire 6y ago
      I believe the problem there is that the leading was specified separately from the font and was negative. In the old days, that would have required filing down each type element.
• deleted 6y ago
  [deleted]
• jamesu 6y ago
  Font metrics are a pain. A while back I was working on trying to reliably reproduce the behaviour you get from the win32 font api using stb_truetype, but due to time constraints I just ended up having to manually tweak font sizes to match.
• ska 6y ago
  > It’s basically a font designer’s personal preference, imposed on every user of the font in every viewing condition. Buried the lede here; but "personal preference" is really design. Article perhaps should be retitled "I don't like typographic design because it forces UI element to adjust to typographic spacing rather than the other way around". Clearly you can make arguments for both being the "right" way.
• true_religion 6y ago
  In other news, this guys dark theme simply blacks out the sight and only lets you read text by using the mouse cursor as a flash light. It's hilarious.
  • kevincox 6y ago
    It is, but I really wish there was an option other than that yellow. Maybe if you click it again you can get an actual dark theme? Pretty please?
    • mixmastamyk 6y ago
      Reader view in light or dark mode works fine.
  • dredmorbius 6y ago
    https://news.ycombinator.com/item?id=26590267 https://news.ycombinator.com/item?id=26590267 https://news.ycombinator.com/item?id=26072323 https://news.ycombinator.com/item?id=26072323 https://news.ycombinator.com/item?id=24589944 https://news.ycombinator.com/item?id=24589944 https://news.ycombinator.com/item?id=23941312 https://news.ycombinator.com/item?id=23941312
    • true_religion 6y ago
      Great minds.... think alike. And also don't look up prior art comment threads before expressing their opinions. :-)
      • dredmorbius 6y ago
        It is a pretty amusing feature, and it's fun watching people discover it.
  • deleted 6y ago
    [deleted]
  • forgotpwd16 6y ago
• anticristi 6y ago
  Reading this article makes me feel nostalgic: Remember the time when text rendering meant bitblt-ing from an 8x8 pixel matrix stored in ROM.
  • grenoire 6y ago
    "Dude, I can't believe that your TTY renders the 'a's counters at four pixels high whereas mine at six! They're both eight-by-twelve in the bitmap."
  • jfk13 6y ago
    And font design meant uploading a new set of bitmaps to the video card (if you were lucky enough to have a machine where they weren't strictly limited to what was provided in ROM). The first non-Latin font editor, text processing and typesetting software I worked on ran on just such systems. Yes, those were very different times!
• arduinomancer 6y ago
  Isn't specifying font size as "display-independent pixels (dp)" supposed to deal with this?
• rgovostes 6y ago
  Relatedly, it's really lame that many apps have an "Actual Size" zoom option (that's ⌘0 to you Mac Safari users) that doesn't mean anything. If I create a word processor document with a 11" tall page size and zoom it to "Actual Size," I should be able to hold a sheet of US Letter up to the screen and have it match perfectly, but it is much too small. Displays (except projectors) provide physical dimensions via EDID metadata, which can be used to compute the correct scaling factor.
  • dylan604 6y ago
    >(that's ⌘0 to you Mac Safari users) Or a lot of other Mac apps. Adobe software has had ⌘0 for longer than Safari has exisited followed by ⌘-/⌘+ for zooming out/in. FF does it as well
  • account42 6y ago
    Physical size might be sufficient if you are holding a paper up to the monitor but for most uses what matters is the apparent size to the user, which would also need to take the viewing distance into account.
    • Doxin 6y ago
      Surely the size of a piece of paper at the same distance as the viewing distance from the monitor would end up having the same dimensions as the paper on the monitor?
• Tenal 6y ago
  "So user requesting 32 pt font is actually requesting 32 px on macOS and 43 px on Windows. But these numbers are still nowhere to be seen." Is that first sentence poorly written or is this some crazy English grammatical clause I have yet to encounter.
• hyakosm 6y ago
  The article points to an interesting UI bug in macOS, text alignment in buttons is weird. Cf https://grumpy.website/post/0UfwgmMDe https://grumpy.website/post/0UfwgmMDe
  • CharlesW 6y ago
    I'd bet this was done on purpose, since the optical centering of "Revert" is improved by this change. However, Apple should reduce this optical offset for smaller buttons with relatively larger text, e.g. those in the Bluetooth System Preferences panel. The side-effect is that all-caps button text is no longer optically-centered, but that's a relatively-rare case other than the "OK" button.
  • hyakosm 6y ago
    There is a issue of the incoherence of this behavior in Big Sur. Example: on my screen, in the menubar, vertical alignment of menu items (File, Edit...) is not the same as date & time widget (slightly upper). I don't know if it's because of my non-Retina screen and the lack of optimisation in recent macOS in this regard.
• jancsika 6y ago
  Here's a simple issue that I've never figured out: 1. Create an svg 2. Draw an svg rectangle in there 3. Draw an svg text "Hello World" so that it fits inside the rectangle. 4. Make sure #3 above works regardless of which platform/browser you are using. Now, I don't see it as a catastrophic problem that I can't (easily) automate everything up to step #3. I mean, maybe I could by iterating over various sizes inside an offscreen HTML5 canvas and measuring the results or something. But it isn't the end of the world to, say, just guess and check in a browser until I hit the right pixel size. Problem is, that rendered result tells me absolutely nothing about what will render on other platforms. Maybe OSX will eat less horizontal width. Hell, maybe some troglodyte who lives deep in the guts of Gnu font rendering stack makes a change that accordions out the horizontal width so it's way out of whack with Windows and OSX. There's no spec that says a troglodyte can't do that. (This all holds for fixed-width fonts the same as variable width, btw.) It's weird because I see all these SVG frameworks that have demos with, say, a graph where text looks to be aligned so that the end of a label doesn't overlap with a vertical line. But there's never a caveat given-- if there were, it should be that SVG cannot guarantee there won't be an overlap there, because it cannot control the underlying font engine that way. You literally have to check with your eye on every platform that you want to support[1]. Edit: clarification Edit: [1] You can't even simply check for each different font stack-- you have to check every extant version of that stack. Because again, a font stack can make a lot of arbitrary changes from version to version.
  • jfk13 6y ago
    Are you explicitly using a linked/embedded font resource, so that you control exactly what font is used to render the text? If not, there's certainly no expectation of uniformity.
    • perardi 6y ago
      Agreed. I simply would not expect this to work properly if you don't specify a font. Just compare Times New Roman and Verdana, two fonts that are broadly available, and broadly different in terms of character widths. Verdana will probably bust out of that container. Maybe if we had container queries, and could set font size as a…container unit? I don't even know what to call it. Like vw and vh units, but relative to a parent container.
• JxLS-cpgbe0 6y ago
  What's the x-height of z̷̡̡̧̛̛͕̩̯̮̯̱̱͚͎̠̳̦͉̤̙̙͔̭̩̝͉̱̯̠̘̝͙̞̟̝̦͈̻͈̱̳̯̱̦̭̱̝͇̪̬͚̹͈̉͐̃͑̒͗̆̒͂̀͂̿͑͋͂́̓͆̅̐̓̎̔̓̔̓̊̀̌̈́̀̀̍̏̈̈̑̍̈̐̓̂̆̉̑͑̒̌͛̀̀́̈́̈́̊͋̃̅̑̎͆̏͗̑̊̀̓̾̈́͗̄̆̂̿̑̌̀̅̽̑͂̒̆̓̃̔̅̒̀̓̂̄̋̐͆̔̂̓̋̽̉͌̈́͂̀́̏͌̾̎̿̑͒͑̿̀̈́̈́̏̃̑̈̐̓̈́̔͋͊̃͊̈́̎̈́̃̓́̏͛̆͗̄̓̈́̊͋̕͘̕̚̚͘̕̕͘̕͘̕͘͝͝͝͝͝͝͝͠͠͝͠͝͝͠ͅͅͅ?
  • forty 6y ago
    Interesting character :) what is it?
    • zarq 6y ago
      Capital Ẕ̷̲̳̥̎̆͌̏̍̆́̓͠ḁ̶̡̖̲̮̫̞̘̠̳̗̯͇̪̘͊̿̐̀̍̽̂̇͌̈́̿̔͌͂͘ḷ̵̙̯̓͋̌̆̍̚̕͝ͅğ̸̡̳̠̦̥̹̝̳͕̜̆̒́̉͛͝ͅơ̸̝͉̟̜͎̜͚͑̾͘ͅ
    • jfk13 6y ago
      It's just a "z" with a ton of combining diacritics. Which is entirely irrelevant. x-height is a dimension of the font, it's nothing to do with an individual character. (In most Latin fonts, it'll match the height of the "x" glyph, but that's not a hard and fast rule.)
• globular-toast 6y ago
  > The solution > Specify it in pixels. No, no, no... I don't understand why the author would suggest specifying in pixels. We know pixel size varies widely between different displays. This means we need stupid hacks like having a multiplier to convert from specified pixels to actual pixels. So why pretend it's specifying pixels in the first place? It's always annoyed me that DPI is not expected to be set correctly. All monitors should come with a DPI value that you set in your OS. Of course, a user is free to add some kind of multiplier on top of that (to account for variation in sight and preference), but the baseline would be standard.
  • tonsky 6y ago
    You can set DPI correctly and match physical size, but why? Viewing distance still varies greatly, so there’s no point for a button to be 5mm tall always
• danShumway 6y ago
  > Specify it in pixels No thank you. I regularly wonder if it might not be better for the web if we got rid of pixels as a unit entirely. We can't realistically do that for a lot of reasons, and there are legitimate reasons to use pixels sometimes, but resolution independent font-size and container sizing should be the default. If you are using pixels on the web for font sizes, consider this a public intervention that you need to stop. The fact that `em` units are not related to physical size attributes is intended. We don't want them to be related to physical size -- what `2em` is saying is that you want a piece of text to be twice as large as the "default" size of the specific font on the platform/device. That is a superior way to think about text size, because as a user I don't want you to try and figure out what the pixel density or screen ratio or resolution of my device is. Size your fonts with `em` and `rem` units, and size your containers based on the number of characters you want to fit in each line. Don't use pixels. It doesn't matter if your fonts are bigger on Mac or Windows. It is intentional that platforms can size their fonts differently, and your interface designs should take that into account. If anything, native platforms should be moving more in this direction, they should not be moving away from it. There was a period where you could decide to only care about responsive design on the web, but increasingly you should be thinking about responsive design on native platforms too. And resolution-independent font-sizes based on the user/platform are part of that process. EDIT: Yes, I'm aware that pixels on the web are not necessarily 1:1 ratios with physical pixels on a screen. That doesn't change anything, pixels are still bad to use on the web. Tying font size to resolution, whether that's browser window resolution or physical resolution, is still equally problematic. And it certainly doesn't mean that we should move in the opposite direction on native devices -- the web's pixels are the way they are because the alternative, being tied to literal physical pixels, would be even worse.
  • deleted 6y ago
    [deleted]
  • jancsika 6y ago
    Essentially, you've made svg text a special case. So diagram-based languages and frankly any graph-drawing framework that let you specify text labels go out the window. I think svg `<glyph>` was meant to be the answer to this question, but that was an answer for people who don't care about readability. So now it is rightly deprecated. Unfortunately, that leaves essentially no answer except guessing and checking with pixel-sized fonts to make sure font-rendering-stack development troglodytes haven't screwed up my diagrams. So don't touch my pixel sizes, bro.
• enriquto 6y ago
  I long for the time where we used crisp, non-scalable, beautiful bitmap fonts. So called "anti-aliased" fonts look always irremediably blurry.
  • Gualdrapo 6y ago
    I'm still using custom bitmap font for monospaced things (text editor, console and such). No antialiased thing has made me changed my mind - bitmap fonts just look so crisp and sharp and readable.
  • opan 6y ago
    Agreed. I changed terminal emulators from Termite because of pango dropping bitmap support. Alacritty and foot both support bitmap fonts and Wayland. Unfortunately many many more programs still can't use bitmap now. Sway, swaybar, waybar, wofi, mako. Pango is everywhere and it sucks. I can make my terminal and emacs look crisp and clear, but a lot of other things look blurry now.
• jahewson 6y ago
  This has basically always been the case for typography. The point size of physical type refers to the height of the slugs, not the letters on them. You can't just grab two 12pt fonts and expect them to be exactly the same size. The standard solution is to use x-height, rather than cap-height and I agree that it would be nice to be able to select a font based on that instead of the em-size (font size). Line height on the web is indeed broken, as it's measured from the center of the em-box and I agree it would be nice to be able to specify baseline distances instead but the catch there is that you really need to know the content of the text being typeset, as soon as you start adding words with diacritics (ÅÀÄ) your lines collide.
  • tracker1 6y ago
    Agreed, I think that the font based on line-height would probably be more appropriate... ex: 12pt means you get 6 lines per inch (or whatever the os/device uses) regardless of font. As long as the font scaling shows lines per the designer's desire. Then there could be some variance, but you get at least closer to desired output.
  • tonsky 6y ago
    Comfortable line-height usually has enough space for any diacritics. If you want to go tighter, you’ll need to know you won’t have them. But that’s true today too.
• fuzzer37 6y ago
  Does anyone really... care? I can't remember ever getting upset about font sizing. If it's too small to read make the font bigger, if you wanna fit more on the screen make it smaller.
  • tonsky 6y ago
    Clearly you have never tried to center text inside a button
• 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 ago
    I 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 ago
      Right. 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 ago
      Many fonts are designed so that you’ll set at least 1.2 line height. 1.0 barely fits the characters themselves
  • tonsky 6y ago
    Those 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 ago
      That 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.
• crazygringo 6y ago
  This is a fantastic article and I welcome this conversation. As the author states, sizing of fonts and line spacing is currently inconsistent across OS's, inconsistent across fonts, and inconsistent with other UI elements. It's madness. There's no good reason for any of it except inertia and lack of forethought. The author's proposal to specify cap height is really the only reasonable solution I think there is, though I'd modify it slightly: - When defining cap height, be clear what the logical obvious equivalent in other scripts, e.g. Chinese logogram height - Specify cap height in whatever unit other UI elements are specified in (the author refers to pixels, but that's arbitrary) - Then line height can also be controlled predictably and exactly in whatever unit UI elements are specified in End result: zero inconsistencies. Text shows up exactly where it's meant to no matter what. How do we get there? Browsers should adopt it first, with something like a CSS "font-cap-size" property that can be used instead of (and override) "font-size", as well as something like "cap-line-height" overriding "line-height". (And for units, recommend using "px", or "rem" ultimately based on a root "px", and never touching "pt".) Then OSes can migrate similarly with new function calls/parameters based on cap height, and also try to phase out "pt" sizing in preference of the logical "px" sizing used in the rest of interfaces. I really think this is the way. I really hope browsers and the W3C can consider something like this. It's decades overdue.
  • nybblesio 6y ago
    <sarcasm heavy="true" comedy-intended="true" do-not-hate-me="true" smiley="true"> What do you mean!? Forethought!? That's BDUF! YAGNI! This is the problem with you damn tech weenies: all you want to do is fix things and think! There is no business value to fixing this problem. Ship! Ship! Ship! Ship! We need to float the IPO or SPAC or...something so we can all get RICH! Who cares if the damn font system is broken!? I don't remember seeing a story card or epic for that in Jira. Now, there has to be -- like -- hundreds of blockers in Jira you should be working on right now instead of futzing with the tech bullshit. </sarcasm> On a serious note: is it possible there's a reason why everything is just slightly shit?
    • QuantumGood 6y ago
      Very effective tagging ;) I've trained actors for decades, and people understand character descriptions (the 'spec' in a commercial) more and more as essentially persona tags.
• dukeofdoom 6y ago
  I was working on Display an Event Title, across devices. Sine the title can very dramatically, from just a word, to as many as 10+ words. Its hard to size this properly, so that it displays on phone and computer screens. Not really sure which approach I should have taken, but I ended up using if statements to change font size based on word count. Wish there was some way of setting the font size so that it fills to the end of the screen. But its no larger so that title is longer than two lines. Its really easy to spot a title when its too big or too small, so that its not aesthetically pleasing. But don't really know how to do that in code. Seems like a font size that is tied to the line length might help.
  • perardi 6y ago
    Perhaps using… http://fittextjs.com http://fittextjs.com
    • dukeofdoom 6y ago
      Thanks, looks great
• barry27 6y ago
  I thought this was going to be about webapps. Surely anyone who has a hankering to do some work just fiddles around for a few minutes with their editor until they get something they like and then gets on with it and doesnt ever think about it again.
• SamBam 6y ago
  I have a similar issue on the web. I have a library, which adds DOM elements and some text to the page. The library expects a certain font to be loaded on the webpage. (This is an internal project, so is usually the case, but not always.) Obviously there are fall-back fonts if not, but those fallback fonts happen to be a different size given the same font-size specification, and so everything looks like crap. The obvious solution would be to throw away the custom font. But if we really want to keep it, the only solution is to load the page, then measure the width of the text, then we know if the right font is loaded, and if it isn't then tweak the styles so things line up better.
• 8bitsrule 6y ago
  relevant XKCD: https://xkcd.com/1273/ https://xkcd.com/1273/
  • tonsky 6y ago
    too much pictures?
• swiley 6y ago
  Pixels are meaningless unless you're an artist, especially with modern graphics APIs where it's often difficult to actually draw individual pixels. IMO: everyone who's used font size outside college knows what an em is. Just standardize a point size in terms of a physical measurement (maybe stick with 1/72 inches since everyone except Microsoft apparently uses that) and make the "font size" a coefficient that maps ems to inches. Furthermore: cap height doesn't capture as much as an em does: there's spacing between letters which has little to do with cap height. Everything about this is wrong.
• neura 6y ago
  I can't be the only person looking at the top of the article, thinking "but if you just add the descender and ascender values together (the total height of the character, not the block space that it occupies), you get almost 32." I'm guessing if you even slightly tweak the way the measurements are being taken, you'll get 32. even if you just assume "always round up", you get 32. This is one of the strongest cases of manipulating data by providing a bunch of data points to obscure the one point, enabling belief in "well, they provide all this data and none of it is 32, so they must have a solid point here!" This misleading opening really just makes me want to avoid reading the rest of the article. I hope there wasn't any real information hiding behind that facade. :x
  • setr 6y ago
    That’s an absurd take... the article’s first paragraph is quite clear he’s going to tell you exactly where that 32 ran off to, and despite your random arithmetic that happens to find the number with no double-checking whether it works on any other font-size or font (equivalent to finding your birthday in license plates, by arbitrary manipulations of the numbers available), it turns out the 32 is in fact missing from any visible artifact of the font.
    • exporectomy 6y ago
      The author could have also mentioned, among the other not-32 heights, the distance from ascender to descender being 31.19 and explained how that's not it either. Instead, he just didn't mention it, as if he was trying to hide it because it was inconvenient to his narrative.
      • setr 6y ago
        He could have also mentioned that floor(cap-height + x-height + descender) also equals 32, but isn’t the answer either. And probably a few other arbitrary arithmetic combinations would work as well. But it seems it me it’d be much more efficient to just explain the real answer instead of telling you all the ways you could misinterpret it... which is exactly what he goes on to do.
• njharman 6y ago
  Whether the arguments or proposals are correct or better. Doesn't matter. Us, as in people reading blog post lack the ability to change 100's of years of conventions and standards across all the world. Change
• c-smile 6y ago
  > 16 pt text on Windows is ⅓ larger than 16 pt text on macOS. px != pt It appears that Windows and Mac browser screenshots are misleading at best. 1px in CSS is logical unit that is equal to 1/96 of inch. On any platform. And so neither 1px nor 1pt have anything with screen PPI (size of physical pixel measured by a ruler on screen surface).
  • kbelder 6y ago
    So a 12px character on a 14" 1080p screen is the same size as a 12px character on an 18" 1080p screen? I'm still somewhat skeptical, despite fifty posts in this thread claiming just that.
    • tonsky 6y ago
      In pixels, yes. In physical size, no (pixels are much smaller on 14" than on 18")
      • kbelder 6y ago
        Right... but that puts the lie to "1px in CSS is logical unit that is equal to 1/96 of inch. On any platform" It's rarely equal to 1/96 of an inch, in reality. It bounces all around.
  • tonsky 6y ago
    In browser, yes. Screenshots are of Sublime Text, which is a native app.
• kybernetikos 6y ago
  Sometimes I want to: 1. size based on how big it is in the real world - mm (but accurate!) 2. size based on user preference - rem? 3. size based on how large it appears to the eye - angle subtended on the retina (displays that don't know this can assume an average distance to the eye different for desktop, mobile, jumbotron, etc and work it out from their size) 4. size based on the kind of interaction the user will have (touch / mouse / eye / point) - some kind of new unit based on Fitts law - or should this just be a bunch of special cases? 5. size based on proportion of the available space - % vh vw I basically never need to size based on some other factors but maybe they have a use: 1. size based on the minimum resolvable size (i.e. the smallest something could be without losing definition). I guess this is much more of a concern if you're using a lot of very low resolution screens - px (but actual) 2. size based on the size of the whole document (including document that isn't visible) Of course this is all made extra complicated by the fact that sometimes containers need to be sized based on concerns bigger than them, while sometimes they're sized based on the sizes of their contents. And whatever framework you're using is probably bad at exposing key pieces of information about e.g. 'how much of this text can I get in this width' Unfortunately operating systems tend to have little clue about how big in the real world their display surfaces are, they are even less clueful about how far away the user is. Everything seems to be based on an early assumption that what was important was the dots on the screen, and as that assumption has proven false, instead of attacking the problem in a principled way, we've just created scaling fudges on top of pixels to take into account higher quality, user 'zoom' preference etc. In the hypothetical ideal world, I'd set my IDE editor font setting to a subtended angle setting and switch between desktop and laptop displays, upgrade the resolution of my screen, or the size of my screen and never have to change it.
• amelius 6y ago
  Perhaps use a different name for it, so we can have both? So e.g.: "font-size" is the old behavior, and "font-height" is the new behavior. By the way it would also be nice to be able to specify the height of lowercase letters, e.g. "font-lowercase-height".
• tomgp 6y ago
  Just look at those to two images with all the “Andy”s: In the first the words all have similar visual weight, none stand out or take up considerably more or less space. In the second image where all the cap heights are the same some fonts make the word look huge (courier new) others tiny (victor mono). That to me is a clear illustration of why this proposal is not going anywhere.
  • spiralx 6y ago
    They really don't seem very similar at all in "look" here, and their measurements are all over the place. https://s.tonsky.me/imgs/font_size.png https://s.tonsky.me/imgs/font_size.png
• deleted 6y ago
  [deleted]
• tolmasky 6y ago
  Neither pixels nor ems are the right solution, and a side-effect of an era of low-resolution screens, what we need is real physical units, and not just for fonts, but for every UI element. I should be to say that a button is intended to be an inch tall (or 2cm or whatever) -- the point is that it should have a height relative to reality, not relative to nothing. Imagine if anything else worked like dimensions in software: you asked for chair 3 feet tall but every maker of chairs had a different definition of a foot. This is how points, pixels, everything works on the web. And the most important thing to remember here is if you still like this system, you can build it on top of one that fundamentally relies on real units at the bottom. But it is incredibly difficult to do the reverse. CSS has "in" and "cm", but they don't mean inch or centimeter. On most browsers, "1 in" is defined as 96 (CSS) pixels[1]. Except, if you print, then 1 inch DOES mean 1 inch. Which hilariously means that if you want to use CSS to lay out something to print, you can't tell how it will actually look until you print, because there's no "please just render like you would when you print" mode. This has been requested, and the classic answer of "who would ever want that" was the response. You can with a lot of work (and JS unfortunately, unless you pre-generate a huge CSS media query for a wide range of screen resolutions) create yourself a unit such that 1em = 1 physical unit, but this has other issues when you start wanting to do other things in CSS. Screen UI is the only aspect of design where we pretend that precision shouldn't matter. It is stockholm's syndrome. I remember how people said that its fine (or better?!) that you can't know "for sure" what font will display on the screen on the web. MAYBE it's Times New Roman, but maybe not! You should be flexible. This is nonsense. Perhaps that's the reality we live, but it's not desirable. We shouldn't fool ourselves into preferring that. Clearly if we could make the exact font show up it would be a better state of affairs. Again, if you really believe font uncertainty is critical to the web experience, then by all means, add a script that randomly swaps in a different serif font occasionally. Boom, everyone is happy! Dimensions is the same kind of problem: we're using ideas from an age where screen were 256 pixels wide. When you design for print, you think about actual size of the produced object. Just because someone can resize the window does not mean that the height of the letter x should be some abstract unknowable quantity. And just because you can set the baseline in size to a specific physical size doesn't mean users can't apply a zoom to that. All it means is that the language with which we communicate to each other is real and not completely different depending on who is reading it.
• thayne 6y ago
  > Specify cap height, not em square size. I'm curious how that would be accomplished. There is nothing that requires a font-maker to have a consistent cap height in a font.
  • tonsky 6y ago
    The only font I’ve seen that reported cap height wrong is Ubuntu Mono. Nothing stops designers from misreporting this metric, sure, but in practice it is MUCH more consistent.
• dec0dedab0de 6y ago
  Meh, if it were up to me webpages wouldn't have any say at all over fonts or colors. When I was 14 I would browse the web with no images, and with the colors and fonts overwritten, and it was so nice. Then image maps became a thing and it was a pain, then javascript, then menus made of small images, then flash, and it's just gotten worse and worse every time around. Now there are webpages that don't work right on a 3ghz single core processor with 2 gig of ram, because of some reason that has nothing to do with what is best for the user.
  • opan 6y ago
    You might like Gemini. All styling is done in the client.
• andjd 6y ago
  >I see no reason to honor the so-called “default line-height”. It’s basically a font designer’s personal preference, imposed on every user of the font in every viewing condition. Erm... To a large extent, these details of a font _are_ the the designer's -personal-preference- professional judgement, and that's the point. We use different fonts because they have a distinct feel or quality, and how much spacing they have between lines is one of the many little details that add up to the gestalt of a font. If you don't like the line spacing of a font, don't use it. Or tweak it if you like. But don't pretend that declaring that all fonts should have a line spacing of 200% of their cap height isn't similarly trying to impose your personal aesthetic preferences on everyone else as well.
  • goodells 6y ago
    The problem seems to be that, should you want to change the font size or line height of text in a given font, it's currently difficult to get a consistent baseline and character size between different fonts. Having some default line height for a font is fine. Making it impossible to align the tops and bottoms of capital letters between different fonts in a sane way is not great.
    • mcguire 6y ago
      Going down this road, you are about to discover that visual weights, slopes, and assorted other minutia also differ, leading inexorably to the ransom note effect. Some fonts are designed to work together; those that aren't, don't. Visual height is the tip of the iceberg.
      • goodells 6y ago
        Sure, this isn't meant to make it impossible to shoot yourself in the foot design-wise if you intermingle fonts. It's more of a layout concern. If I change the font in an app or website, it _always_ leads to tweaking all the font sizes and adjusting vertical padding on things like buttons. All to get the baseline and vertical height at roughly the same spots between fonts. The author's proposal of a "cap height" (I don't like that term, though) would make that tweaking a thing of the past.
• SavantIdiot 6y ago
  I think the funniest part about this this post isn't the lack of typesetting among people who work with digital typesetting (there should be no mystery between points, em, rem, px if you do this for a living, that's 101-level stuff)... instead, it is the subtext pointing that the latter of the two complaints that spawned this is that vertical centering is still a challenge when it really should not be. And I can't help but observe that the two are tightly related. Also, I didn't know the original Mac screen was 72dpi. That is so delightful.
• kickingvegas 6y ago
  Related HN threads on a post I made in 2012. https://news.ycombinator.com/item?id=15639616 https://news.ycombinator.com/item?id=15639616 https://news.ycombinator.com/item?id=4236429 https://news.ycombinator.com/item?id=4236429 "All of this has happened before, and it will all happen again."
• JamisonM 6y ago
  I don't have strong opinions on this topic or any particular expertise but I looked at the "cap Height" vs "point size" examples rendered to support the thesis of the article and thought to myself, "The difference doesn't seem worth worrying about, the existing system looks like it works to me."
• Black101 6y ago
  How long has the solution been around?
• ejfox 6y ago
  dork finds a thing he doesn't understand, begins to understand 25% of it, and then decides to "fix it" like it doesn't have centuries of history and learnings around it that impacted the decision, write your own metaphor
• nightowl_games 6y ago
  As a game developer, I often have to write custom label layout code to make certain things fit in a certain size box across several languages. None of us have ever figured out what the font size represented, so we just have code that tells us the size of every character and we piece it together like that. That's right, we just measure every character in order to get the pixel size. Because we use pixels. For everything. Because we kinda have to. Because thats what OpenGL uses. This article finally explains why font sizes are so useless.
• chovybizzass 6y ago
  `html { font-size: 62.5%; }` `body { font-size: 1.6rem; }` all you need. now padding, margins etc can be specified in pixels but using rems 1.2rem is 12px. 1.5rem is 15px etc. and its all based on user's base font-size.
• jetru 6y ago
  Typography nerds are the best. I admire this article - merits or demerits - people who love typography always exude passion
• jwilk 6y ago
  Em was originally the width of the capital "M", not lowercase "m" as the article says.
• mseepgood 6y ago
  Why not in mm, and then use the actual screen resolution to convert it to pixels.
  • neop1x 6y ago
    Because not many people care (yet). Of course font should always be defined in physical units (be it pt, inch or mm). Pixels are irelevant. When you are printing a text, you also don't care about how many pixels are being printed - your printed page will look the same on any printer, you can print a ruler. But somehow software industry has ignored this for decades. Why? I don't know. Probably inorance, bad cooperation amd lack of standards.
• wodenokoto 6y ago
  A lot of people are saying that we can’t use cap height because of non-Latin characters and that was also my first thought. But we could say that every character is defined relative to the cap height of “M” and then it is up to the font designer to choose how big an あ or a ㅕ is relative to the M. That would however not be much of a change compared to an em, which basically just says “how big is your line compared to the tallest line available?” Unlike the author, I haven’t created a successful font, but my feeling is that it is better to have things defined relative to a max height, than have things defined relative to “a height”.
• PostThisTooFast 6y ago
  Let's fix fonts: No more fonts with capital "i" that looks like a lower-case L. The capital "i" has crossbars on it. Period. Any font that doesn't should be banished.
• joshlk 6y ago
  > 16 pt text on Windows is ⅓ larger than 16 pt text on macOS Is this why text looks smaller on Macs compared to Windows? My parents found it difficult reading text when they got a Mac because of the small text
  • aardvark179 6y ago
    Back in the day Apple decided that text on the Mac should be as close to text on the page as possible, and Microsoft thought that text on screen should be larger since computer monitors are normally further away.
• nyanpasu64 6y ago
  The font-size-adjust CSS property changes the font-size property to specifying x-height (instead of the default point size). AFAIK there's no way to specify cap height instead. And unfortunately it's only available on Firefox by default, and Chrome requires a special about:flags enabled. https://developer.mozilla.org/en-US/docs/Web/CSS/font-size-adjust https://developer.mozilla.org/en-US/docs/Web/CSS/font-size-a...
• artem247 6y ago
  To be honest, this kind of solution throws the baby out with the bathwater. What this solution effectively proposes - is to change the way fonts are designed. Font design is not just drawing letters, cap height to em size relationship is also an important decision. It doesn't have to 'align' with anything, space around letter is important. Again, there is a strange illustration in the "The Problem" section where lowercase 'm' from one font is compared to lowercase 'm' from another one. Yes, they have different x-height. Why is this a problem? The difference in cap height to em size ratio in different fonts is intentional, it is not random. In my like 15-year design career never ever I needed that fonts from different font faces would have the same cap height when the specified size is the same. Never ever I heard from my design colleagues that this is somehow bothering them. It is fine that different fonts have different "ink ratio", that's intended. And one particularly striking part - about the default line height. In fonts that are good at being used for large amount of text - you can typeset a book with it or use for body copy of a website or print magazine, the default line height is that particular height that makes it the most comfortable to read. And it's perfectly fine that it is different in different fonts - it has to be. It is not random - it is intentional. If there would be no specific default line height - then designers would have to tweak it each time for each font to make it readable or more realistically the quality of typography on Web and elsewhere will decrease because nobody would bother to do this properly. Sometimes you need sensible defaults, sometimes you need to respect the work of type designer. To discard hundreds of years of history and knowledge to satisfy marginal at best use cases feels barbaric to me, to be honest.
  • sfink 6y ago
    Hm. As a user, when writing a document I put down the text first, using the default font and whatever font size feels comfortable for writing. Then in the polishing step, I try out different fonts. My standard routine is to switch font, notice that it's now way "smaller" or "denser" (or the reverse) than before and adjust font size until it's roughly back to where it was. Some font switches don't visibly change the feel of the size that much, but most do. I guess what I'm saying is that as a user, whatever property is tied to "font size" is not working for me. I don't know if caps height would work better for me than font size does, but it could hardly work worse and the examples in the article make me think it may be substantially better. And I would like that outcome! I would like to be try out several different fonts without needing to adjust everything for each one. I'm sure font designers had some specific purpose or set of purposes in mind for their fonts, but I'm using it for my purpose and in practice the sizing mechanism just isn't right for me. We can achieve the same end result either way. You have two non-orthogonal variables you can adjust to get whatever you want. This article is arguing that one of those variables is the wrong control knob, and I'm inclined to agree.
• emipop 6y ago
  What about other languages than English and other alphabets? What's the cap height of Ä? Is it higher than A? Or the same? Will your fixed line height then make Ä intersect the line above? What about あ what's the cap height of that? CJK languages don't even have capital letters... Not to mention the other scripts I'm less familiar with. This proposal loses credibility immediately for narrowly considering only one language and ignoring the other languages of the world. Trying to "fix" fonts isn't a one person job. You need a committee of representatives for all modern scripts that are in use. And that's not likely to happen because frankly, is working well enough as it is and disturbing the status quo here is going to cause more issues than it solves, see https://xkcd.com/927/ https://xkcd.com/927/ There are other problems with the proposal, specifying sizes in pixels messes up printing where you have anything from 300 to 1200 DPI. Not to mention high DPI 4K screens. Talking about inconsistency? Try using a 96 DPI screen next to a 168 DPI screen and try to get even the same font to line up... The only way to do that is device independent units and a correct DPI setting for the screen. I posit that it's not fonts that need fixing, it's the rest of the UI (Windows etc) that need to start correctly using device independent units instead of weird scale factors... In fact I'm going to go on a rant here... All graphical UIs are doing this wrong, each individual display should use (by default, with override) the EDID reported DPI and all layout should be done with device independent units (RIP bitmaps). This makes everything on the display be the size (in SI units) that was specified and it's consistent between displays of different DPI. On top of that there should be a scale factor to make the entire UI larger for accessibility reasons or if you're using long viewing distances. Scale factor should auto detect if the DPI is too low and be set higher to compensate, this makes text legible by default on low DPI screens like old TVs and projectors that are used for media centers.
• readonthegoapp 6y ago
  typo: >Caps are what human eye actually percieves as text block should be 'perceives' ...also, cool-looking article. didn't follow the details but it def seems like fonts are always more trouble than they're supposed to be.
• teknopaul 6y ago
  Silly idea. If you fix caps height it's impossible to create a font that is say deliberately small caps, or has a consciously flamboyant F
• HelloNurse 6y ago
  Both em and px units are meant to have an absolute size (in, let's say, millimeters or real pixels of the screen). This makes both units completely different from percentages and quite similar to each other; the rather arbitrary and unimportant cases in which they are scaled differently don't have a serious impact. On the other hand, I've wasted more than enough time to debug layouts in which using both units made sizes inconsistent; I tend to use px only for ease of arithmetic. The important and interesting point in the article is that what should be sized (regardless of the units!) are line height and "cap height" (x-height + ascenders) instead of x-height + ascenders and descenders + arbitrary empty space. It isn't a very convincing argument: depending on the font and text, the apparent height of a line could be represented more faithfully by x-height or by accounting for descenders (and swashes), and specifying different sizes for different fonts isn't particularly difficult.
• ybbond 6y ago
  other interesting related article and HN thread: - [Continuous Typography / Max Kohler](https://maxkoehler.com/posts/continuous-typography/ https://maxkoehler.com/posts/continuous-typography/) - [HN Discussion](https://news.ycombinator.com/item?id=26523550 https://news.ycombinator.com/item?id=26523550)
• elpince 6y ago
  I'm a huge fan of the idea. I've also been raging for years because of those inconsistencies. Though I'm not entirely sure this is a matter which can be resolved on the short term : I'm not sure about this matter, but I think a character's alignement depends on how it's been made to be in the font's files, I don't see any clean way for a browser to change that automatically. Also, it raises another question, would font designers care if their font's default settings are tampered with (I'd guess that yes, they would).
• readonthegoapp 6y ago
  Speaking of font size HN home page font too small My browser zoom settings fix these comment pages But not the home page
• mprewitt-iiw 6y ago
  One of the factors in the font bounding box is character accents. We don't use them much in the U.S., but other countries do. Looking at Fira Code, for example, it seems the bounding box is unnecessarily tall for a capital A. But when you look at the accented capital A, it is about right (it has a little extra padding). Still, there is some inconsistency. For the example, the "Latin Small Letter L With Acute" (ĺ) in Fira Code breaks out of the bounding box (whereas the same accent on the capital L doesn't). The same with descenders and their accents. The bottom boundary accommodates most of them, but some hang just a bit below. The "Box Drawings" glyphs included in Fira Code extend well outside the bounding box horizontally and vertically (but are kiss-fit on the left and right edges). As a designer, I agree with your basic point, that more consistency is needed. But it's worth nothing that the same issues affect traditional print design. A 10 pt font in Adobe InDesign, whether in an inch, point, or mm based layout, will vary in size from one font to the next. Their cap heights and x-heights will be different, sometimes dramatically. However, the one thing that will be the same is their leading (baseline spacing). That would be a good start for a reformation with regard to browser displays. For now, it is probably a case where we can blame the browser devs or standards organizations, but they will in turn blame the specs of the source fonts, which are in fact inconsistent as I said above.