Font hinting has been the source of countless headaches for type designers and users. Meanwhile, some of the most fundamental and important elements of typography still can’t be addressed with the web of today. Rather than being seen as a tedious chore whose demise will be celebrated, hinting might actually provide the essentials for truly responsive design, and vastly expand the possibilities of digital typography for designers, publishers, and readers.
The fundamentals of hinting#section2
Type and web designers usually think of “hinting” as instructions built into digital fonts to improve their rendering on a grid of pixels. Hinting pushes the points of a font’s Bézier curves around according to contextual conditions, such as the font’s rendering size. Though it’s now associated with type on screens, hinting was first used in the 1980s to improve rendering on low-resolution printers.
Thinking about it in these terms, hinting is responsive type that existed before the web: The font performs a media query of sorts to learn its size, then responds by repositioning points in each glyph according to built-in instructions, or “hints.”
In other words, hinting is to fonts what responsive layout is to websites. It allows a single font file to adapt to a variety of contexts, the same way CSS allows a single HTML file to adapt to a variety of contexts. In fact, Håkon W. Lie used the term “presentation hints” in 1994 to summarize his original proposal for CSS.
Hating hinting#section3
Developing hinting instructions can be extremely difficult, expensive, and time-consuming. Automated hinting tools have begun to ease some of this pain, but for smaller body type—often the most important type on any page—there’s still no substitute for the quality that can be achieved through tedious manual hinting. That’s why most people who deal with hinting today eagerly anticipate a future when they’ll no longer need to worry about it. They optimistically cite advances in display resolutions and rendering software as sure signs that hinting will be obsolete within a few years. (Such claims have been made for the past twenty years, and will probably continue to be made for some time to come.) But this ardent desire to see the end of hinting is based on a narrow understanding of what hinting can be.
I used to be among the impatient hinting haters, cursing Apple (yes, Apple—whose rendering engines now all but ignore hinting data) for popularizing the concept of hinted screen fonts with their TrueType spec in 1991. And I would be lying if I claimed that the issues currently related to hinting don’t still cause me trouble. However, I’m very reluctant to dismiss the general concept of hinting just because current implementations of the idea are limited and hard to deal with.
Pushing toward macro-hinting#section4
The hinting that people know and use today only represents a small sliver of the possibilities for contextual typeface modification. Considering that it’s impossible to query a font’s absolute size—never mind things like font smoothing conditions or physical pixel density—many of the most basic fundamentals of typography, typeface design, and readability are still lost on the web.
With better media query features in place, typefaces could be endowed with what I call macro-hinting: intelligence to modify a typeface according to variables beyond the nominal size. Such modifications could happen automatically according to the instructions of the type designer, or they could be adjusted by the specifications of the typographer.
A few contextual typeface modifications that could be possible with macro-hinting include:
- Ascenders and descenders that dynamically shrink when the line height is reduced.
- Glyphs that condense as column width is reduced.
- Hairlines that are always exactly one pixel, gradually increasing the overall contrast between thick and thin strokes as the size increases. (This would be a hit with fashion magazines.)
- Subtle weight adjustments to give a consistent feeling across different rendering environments, without needing separate font files.
Other context-specific typeface modifications#section5
The idea of modifying a typeface’s letterforms for different situations is nothing new. As far back as Gutenberg, each size of a letterpress typeface has traditionally featured “optical size” variations that altered the spacing, proportions, weight, and other details for optimal results. This concept has been applied to some digital typefaces that are offered as “Text” and “Display” versions, for example.
In addition to optical size variations, some typefaces are 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.
Adobe’s Multiple Master (MM) technology allows users to change a typeface along multiple axes such as weight, width, and optical size. Though MM technology is now mostly obsolete in typesetting software, it’s still used by type designers to generate font families, and—interestingly—in Adobe Acrobat for scaling generic fallback fonts to match the proportions of missing fonts.
For another example of contextual typeface modifications, applications like InDesign can tweak spacing or glyph widths for better copyfit. These automated modifications to a typeface have a very limited range of acceptable use, but they afford typographers that much more flexibility when needed.
As with hinting, these methods of varying a typeface’s design exist to improve performance in context. The interesting twist is that, like hinting, they all come from the relatively static world of print typography, but are still largely absent from the otherwise dynamic world of web typography, which seems like their natural niche.
Static fonts floating in the seas of dynamic layout#section6
In Tim Brown’s Universal Typography presentation (go to 15:50), he describes contemporary web typography as a practice in abstraction, determining limits, and defining ranges of acceptable solutions:
We used to think about typography as a set of fixed decisions, but now we understand it as a continuum of conditional logic.
I completely agree with him, but I wish the continuum didn’t end when it reached the base level of the typeface. In the current world of web typography, defining a typeface is still very much about fixed decisions. Web browsers can automatically interpolate the position, shape, and size of any element on the page, yet when it comes to the most basic typographic forms, there’s no instrument for adaptation.
We are beginning to see cases where designers will detect the users’ conditions and serve different font files accordingly. This method, which I call “detect and serve,” shows that there is still a need for context-specific typeface modifications on the web.
Indeed, until there is universal support for WOFF, even a single static type style requires an array of fonts in different formats just to match the requirements of different browsers. Providing real-world solutions for larger type families, or even the lowest level of contextual optimization, can require dozens or even hundreds of mostly redundant files.
As you can imagine, generating and serving individual font files for every possible situation quickly gets out of hand. The same way that web designers shouldn’t have to maintain multiple HTML files for every conceivable viewing condition, a broader implementation of the concepts behind hinting would allow a single responsive typeface to dynamically provide optimal results across a multitude of contexts.
Evolution, not extinction#section7
In a series of follow-up columns, I’ll address the relationships between typefaces and media queries in more depth. For now, let it suffice to say that many pieces are still missing from the puzzle of responsive typography on the web.
Solving this puzzle will take time. Inventing new standards is not easy, never mind getting them widely supported. Bringing these ideas into practical reality will require new tools, coding languages, working groups, and public education. It won’t happen overnight.
In the short to medium term, we’ll see increasingly complex hacks to achieve similar results. The “detect and serve” method will likely become more popular in the near future, with font vendors generating arrays of distinct variations on each typeface. Some may even develop systems to spit out font files on demand to match each user’s situation. People will still complain about hinting, and hinting will continue to be a struggle.
However, at the end of the day, I don’t expect to see the extinction of hinting anytime soon. Instead, I foresee it evolving toward more advanced methods of describing digital letterforms. It may sound like science fiction, but typefaces will eventually gain more awareness of their internal structures and external surroundings. The concepts that underly hinting will only become more relevant as the scope of responsive design continues to expand.
Great article, Nick! Can’t wait for more!
What I think would have a rather big impact and is considerably easier to implement were for all browsers to finally support hyphenation.
Thanks, Nick. Very interesting read. I am really curious to see this concept in action.
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.
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.
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.
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!
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
sizefeature 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.
@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.
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
Nice article, definitely a good read : )
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.
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 commented about it on ALA 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.
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]
>> 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... 😉
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.
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).
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.