Comments on Font Hinting and the Future of Responsive Typography

18 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:
    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. 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.
  6. 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.
  7. 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.
  8. @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.
  9. 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.
  10. Nice article, definitely a good read : )

    Copy & paste the code below to embed this comment.
  11. 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.
  12. 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.
  13. >> 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.
  14. 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.
  15. 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.
  16. This article wasn’t exactly what I was looking for in terms of answering a question - which browsers do not support Font Hinting (although now I can see Safari probably rates…) and I will answer that question for myself in a sec…

    Nevertheless compelling discussion. I can see that Nick cares about Typography and has experienced the inevitable issues that arise from managing and developing practical use cases.

    I am not sure what qualifies Mr. Fink to undermine the relevance here, or even what the qualm is.  In my work, which is systems architecture, I have used or even exploited issues with fontage to suit the needs of the client. First and foremost, before anything even remotely tricky begins to happen (such as my adaptation of Cufon’s early software to provide non-copy&paste;-able text while rendering a typographically custom look and feel to the site), there is the serious problem of the way certain browsers distort custom fonts.

    This is not just vanity. You can always say “Well who says one should get custom typographic choices online that render universally (or even acceptably?”

    ...right, and I can say “Hey PC’s and the Internet haven’t been around until the last 40 years, so who really needs them?” Both positions have equal import.

    To approach a discussion that way- it’s non-functional.

    The issues present are clear- as a developer I’ve struggled on the top 5% of the issues, spending enormous amounts of time beyond that research scheming ways to solve these issues- not just the fringe cases of pure vanity, but very fundamental questions like “if I get @font-face how do I actually make it look acceptable across the top browsers, and major Mobile OS’s?” Just that one issue requires special treatment. That doesn’t even begin to approach the needs of publications (eBooks or other PDF type applications), Kindle,  print collateral as media (online) which is a workflow issue, etc.

    These are real issues affecting thousands of people whom my clients represent. So yes, what ARE the fundamental issues? If this point isn’t obvious then perhaps it isn’t up to the author of this article to supply the necessary experience to make it relevant.

    Copy & paste the code below to embed this comment.
  17. Sorry, commenting is closed on this article.