Font Hinting and the Future of Responsive Typography

by Nick Sherman

17 Reader Comments

Back to the Column
  1. Great article, Nick! Can’t wait for more!

    Copy & paste the code below to embed this comment.
  2. What I think would have a rather big impact and is considerably easier to implement were for all browsers to finally support hyphenation.

    Copy & paste the code below to embed this comment.
  3. Thanks, Nick. Very interesting read. I am really curious to see this concept in action.

    Copy & paste the code below to embed this comment.
  4. Article starts:

    “some of the most fundamental and important elements of typography still can’t be addressed with the web of today”

    Oh yeah? Well first let’s ask: the elements of typography that are fundamental and important to whom?
    The question isn’t rhetorical. One of the big questions that the move away from reading off paper to reading off networked screens has made us ask anew is: Exactly what ARE the fundamental and important elements of typography?
    Despite articles that decry the web’s poor typography, the web grows and grows and grows even as print magazines with presumably superb typography continue to close up shop.

    Frankly, in the list of problems facing web designers these days, ascenders and descenders that dynamically shrink when the line height is reduced seems a rather low-priority concern.
    And I humbly submit that people who make web sites don’t need to concern themselves with typefaces offered in a range of “grades”—subtly different versions that allow for a high level of consistency across printing processes, paper stocks, and even humidity levels that affect ink spread.
    Who cares?

    This article is of an ilk where type, as it can be made to appear on paper, is held up as some kind of a goal for type onscreen.
    But we’re never told why this should be so.
    Why should type onscreen try to emulate type on paper?

    Far from being in any way “fundamental”, most of the features listed are parlour tricks in comparison to the magic that type onscreen has already achieved.
    Things like:
    zoom,
    language translation,
    audio read-back,
    and, of course, everybody’s favorite – that ‘instant universal distribution’ thing that the web and its traveling roadshow of letterforms does so well.

    That’s my take, Nick. Thanks for making me think.

    Copy & paste the code below to embed this comment.
  5. Richard, you asked: “Exactly what ARE the fundamental and important elements of typography?” I believe size is a good place to start – as in actual physical size. I don’t want the design of websites to focus on any one size configuration, but when it comes to type, size (and, tangentially, resolution) has a huge influence on the success of any one design – regardless of if the environment is digital or analog, or if the size is specified in fixed or relative units.

    You also asked why I mention the concept of grades for type in the print realm. To me, the problems that grades address are very much so related to the problems of one font looking bolder or somehow different depending on the OS, browser, user settings, etc.

    The point of this article is not to decry poor web typography, nor is it to make a case that print typography should be the model for onscreen typography. In fact, a large part of my point is that type on screens has the potential to be vastly more flexible/effective than type in print. But this isn’t an issue of print versus web – it’s all typography to me. It is simply an issue of allowing typefaces to adapt to their circumstances.

    Copy & paste the code below to embed this comment.
  6. Great piece, Nick. I think Richard is right to ask the hard questions he does, but my take on it (without being able to defend it at length just now) is this: Bad typography raises the cost of being a reader. Zuzana Licko may be right that we can get used to reading practically anything, but that doesn’t make the costs any less real or improvement meaningless.

    And why not paper as a model, since we know it’s a good one? Readers aren’t moving to the web because they’re tired of clearly rendered type. Any reasonable chance we have to address what was left out of browser and markup code when the web was born, we should take advantage of.

    Copy & paste the code below to embed this comment.
  7. Nice to have stumbled on this Nick. Good start to a loooong discussion. The added complications which mobile devices bring to the picture are daunting. e-Paper screens vs. LCD; Retina displays which render some typefaces so sharply as to become nearly unreadable; wide variations of rasterizers+hinting on mobile devices makes things 4x as complicated as the desktop was 4 years ago.

    You are correct – the importance of hinting is not going away – I’ve compared atrocious results of Adobe autohints on 250dpi e-readers vs. crisp ‘delta-hinted’ type with amazement… good hinting DOES matter even though the screens are getting better.

    I’m working on tooling typefaces to enhance contrast on devices – but since each device has different display characteristics it’s always a moving target.

    And to the question of ‘why do we care about paper’… well there was a time when we got paper typography right. And if we simply ‘get used to reading anything’ we don’t advance the ease or aesthetic of written communication. We are not ‘there’ yet with screen typography and I am happy to be part of a movement working to make it better. Keep up the good work!

    Copy & paste the code below to embed this comment.
  8. Hello Nick, interesting article. Looking forward to read the next ones in the series.

    I think the main problem with TT-hinting is the same as MultipleMaster: it requires a ‘smart client’ which can read and process instructions in a ‘smart format’. I don’t think this will work, because it’s not backwards-compatible, and most clients will remain dumb.

    The best solution (IMHO) is to bring TT-hinting functionality (and other gridfitting methods) into the font editor, and use it to generate ranges of static fonts – just like we do today with big font families for print.

    What is still missing to make this model work smoothly is A. a format which can contain a bundle of fonts, and B. a simple API to access individual fonts in this bundle.¹ But it is already possible to achieve something like this with pure JavaScript/CSS (no smart clients required).

    I’ve tried to address these issues here and here, without much impact. I wish you good luck!

    ¹ In the discussion that followed my post to the W3C list in 2009, it was suggested that the size feature in the OpenType format would be the ideal place to store this kind of information. But this feature has never really been supported by font clients, and there are other parameters besides size (for example rasterization mode and screen resolution).

    ² See also this follow-up discussion on Typophile.

    Copy & paste the code below to embed this comment.
  9. @Maurice – yes, some of the worm cans Nick has opened would take considerable time to mull deeply through.
    But here’s a little stab of an idea I’ve been wanting to blog about for awhile that’s apropos.
    Nick writes:
    To me, the problems that grades address are very much so related to the problems of one font looking bolder or somehow different depending on the OS, browser, user settings, etc.

    OK. If it’s that the mix of different text rendering engines and pixel densities that we have today is kind of like dealing with ink spread, or more generally, with the different print processes used for different publications, I’m with you on that. It is similar in some ways.
    The rub, to me, is that whereas the type makers of yore were able to take steps to keep variation to minimum, the font maker or web designer of today can do next to nothing to do the same.
    Live with it. Get used to it. Go buy some popcorn, rent the movie Dr. Strangelove, and stop worrying and learn to love the bomb.

    I like to explain the situation using the metaphor of working with “silent” partners versus working with “active” partners.
    It goes like this:
    When I take a PDF down to the local print shop to turn the PDF into a printed document, as partners with me in the endeavor, I count on the print shop to be as silent a partner as they can be. The less deviation there is between the PDF and the finished, printed product I am expecting from it, the better.  And almost always, I have no problem getting that.  The print shop stays out of my business and transforms the PDF into the print equivalent that I expect. (Ironically, the application of digital technology to the field of print over the past thirty years has made an enormous difference in this regard.) My PDF-to-Print “partners” turn my PDF into a flyer, a book, or a whatever, and they deliver exactly what I expect. There is seldom a suprise, and when there is one, it’s usually trivial.
    On the web however, you don’t have passive silent partners like that, you’ve got active hands-on partners – a lot of them, too – and these partners are constantly meddling with what you do. They make stuff bigger, make stuff smaller, they change color shades, they fatten up the font at smaller pixel sizes (Apple, I’m looking at you), and there are few areas into which they won’t intrude.
    Apple, Samsung, Microsoft, Amazon, the teams at Mozilla, Webkit, and Opera, and oh so many more – they are my partners and they’ve got something to say about what gets delivered to the user based on my HTML/CSS/JavaScript instructions.
    They just won’t stay out of my hair like the local print shop does.
    But when I look at the overall result, I’m thankful for these meddler-partners, because the result is a lot richer for that collaboration.
    And if the price, to me, is learning to live with a design that is visually uncertain and subject to great variation depending upon the browser, the device, etc…. then a great bargain has been struck and we are all much richer for it.

    Copy & paste the code below to embed this comment.
  10. With “Hairlines that are always exactly one pixel,” what pixel are you referring to? Device pixel? CSS pixel?
    A pixel is not a pixel is not a pixel
    Master CSS pixels for Retina displays

    Copy & paste the code below to embed this comment.
  11. Nice article, definitely a good read : )

    Copy & paste the code below to embed this comment.
  12. There are some really interesting ideas here about how type could be improved for the web, but I think there’s a major problem: education.

    The more choices a web designer has, the more typographic education they need to make the right choices. The rise of web fonts has brought much better typography to the web, but I’ve also seen it horrendously abused by those without a decent understanding of the ‘laws’ of typography.

    Perhaps what we need is more intelligent systems that take the choices away from the designer; but then, of course, you’d be introducing a slew of new problems.

    Copy & paste the code below to embed this comment.
  13. Steve — Thanks for the encouragement! As I said, I know this won’t happen overnight, but we have to start somewhere.

    Gustavo — I understand your points about TT hinting, but most of the ideas I’m thinking of aren’t possible with the existing implementation of TT hinting anyway. I’m trying to push the discussion far beyond just size-specific adjustments and grid-fitting, to allow for much more flexibility and contextual variation.

    As far as backwards compatibility, the great thing about responsive design on the web is that you can detect – and design – for inequalities in support. Universal support isn’t necessary for it to be useful with the smart clients.

    You are right in pointing out the lack of an ideal format (or other kind of reference method) for the variations of a typeface. I don’t see this as a collection of static instances though, but more as parameters that can be interpolated on the fly as needed (like Multiple Master typefaces). Otherwise, if you store binaries for every possible situation of size, weight, width, resolution, OS, browser, etc, etc, you will quickly be drowning in data bloat. This is basically what we have now with the “detect and serve” method, but it is not scalable for anything advanced or fluid.

    Thanks for pointing to those older links, they are all good food for thought.

    Gunnar — Like you, I am painfully aware of the different concepts for what constitutes a “pixel” (I’ve even <a >commented about it on ALA</a> before). To answer your question of “What pixel are you referring to? Device pixel? CSS pixel?”, my answer is: both! We should be able to detect and respond to either one as readily as the other.

    Oli — Your idea of “intelligent systems” is along the right tracks. I don’t see it as taking choices away though, I see it more as providing better defaults, or offering more flexibility to adjust to the environment.

    Copy & paste the code below to embed this comment.
  14. Hey, Nick, thanks for pushing this discussion up front.
    @Gustavo: Bringing hinting into the font dev program would help, but as Steve M mentioned, it’s a lot more complicated than it used to be. In order to really make the best hinting decision, you’d need to have every rasterizer available to the program, which isn’t possible now. (Beyond the versions of OSX and Windows, consider the versions of Freetype and iType you’d need to cover everything).
    I think what Nick’s suggestions run up against is a fundamental problem with TT: it’s decisions are based purely on pixel size (and to a lesser extent, screen ratio), which were the determining factors 20 years ago. but they are one of many factors today, where it would be better to have information like luminance, pixel density, tracking and line height as determining factors as well.

    To address the nuts and bolts issue here, the problem with TT hinting, and therefore, it’s tools, is it’s reliance on point numbers. When you have a family of 24 or 32 weights/styles, you have to do base hinting for each of them separately, as the point structure is naturally different due to condensed curves, weight changes, etc. To have the commands not address “point # such and such”, but instead address “extreme left point of contour #1” would make the commands transferable and save a lot of development time.  [I know some of you have heard my rant before, apologies where necessary]

    Copy & paste the code below to embed this comment.
  15. >> Gunnar Bittersmann 1:31 pm on February 25, 2013

    With “Hairlines that are always exactly one pixel,” what pixel are you referring to? Device pixel? CSS pixel?
    <<
    In the case of TT hinting, you only can control device pixels. Hence the issue. Although hairlines of vertical stems are controlled in windows by the CT subpixel modelling, while the horizontal stems will be forced to full device pixels, if you hint “that way”.
    See my struggles yesterday as reference… ;)

    Copy & paste the code below to embed this comment.
  16. Jason, your rant most certainly don’t need an apology. There are people working on improving the tools available for hinting. There’s also work being done on incorporating hinting-like methods in type design, a tiny step in the direction of Nick’s ideas.

    Copy & paste the code below to embed this comment.
  17. It sounds like what you are looking for is something like MetaFont, but incorporated directly into a browser’s text rendering system—a Turing-complete, fully-parameterized font renderer.

    Outline fonts like Type 1 and TrueType largely displaced MetaFont because they are simple enough to be rendered on the fly (instead of in the batch operation that MetaFont uses) by devices with 1980s computing power. But maybe the time has come to revive the MetaFont concept (perhaps with a less-strange syntax).

    Copy & paste the code below to embed this comment.