Times Reader take two

The Times Reader 2.0 released this week is a newsreader powered by AIR (Adobe Integrated Runtime) that was developed by Adobe in partnership with The New York Times Company. I contributed to the project; more about that later. It is a groundbreaking application that feels like a breath of fresh air amid all the unfortunate news affecting many newspapers across the country and worldwide.


Being a Print & Graphic Arts graduate and a typophile, it’s quite disheartening for me hearing stories of century-old publications ceasing their activity almost overnight. I am hopeful that the new Times Reader will help revitalize the news publishing industry and contribute to the increase of its readership. I’d go so far as to say that this new version is currently the best example of what a digital newspaper should be.

What I like about version 2.0 of the Times Reader is that it’s quite easy to read, it’s intuitive to navigate, and it looks very much like the printed version of The New York Times. In addition, the newsreader application makes good use of the capabilities that become possible with the adoption of a rich media environment, such as video, content update, and search. Also noteworthy are the ability to read off-line, the seven-day archive, and the interactive crossword puzzle. (It wouldn’t be The New York Times without it, would it?) Being a visual kind of guy, I very much enjoy using the “News In Pictures” section and eventually click through to the related article whenever an image gets me interested.

There are two other features that rank high on my list of favorites. The first is the “Browse” mode; it allows you to get a bird’s eye view of the content. This is great for quickly scanning the articles and jumping through sections, just as how you might do in a printed newspaper. The other nice feature is the adjustable layout; when you change the size of the window, the content (text and images) reflows and readjusts to the available area. And all of this happens while preserving the design characteristics of the layout. It’s simply brilliant! (You can tell that it wasn’t developed entirely by engineers…) All in all, I think that the Times Reader 2.0 greatly improves the user experience of reading the news on a digital screen. It did for me and got me hooked to reading on screen more often than before.

I was fortunate enough to have been a beta tester of the Reader, but more than that, I actually contributed directly to its production. The teams at both Adobe and the New York Times in charge of developing the Times Reader wanted it to have a similar look and feel similar to the printed edition, so part of that meant that they needed to use the same fonts. The problem was that the fonts were in the old Type 1 format (a.k.a. PostScript) and AIR does not support it, so they needed to be converted to OpenType. Luckily, Adobe has a Type Development team; they got in touch with us and asked if we were able to do the job.

I have enough things on my plate to keep me busy full-time (and then some), but as soon as I knew about this opportunity my first reaction was to volunteer for the task. How could I have passed on such a high-profile project that will be seen by millions of people? And how could I have ignored the possibility to contribute to improving the reading experience? At this point I had already seen some mock-ups and prototypes and they looked fantastic. So after getting legal clearance we got the conversion started, and this is where things became interesting.

Initially I did a straightforward conversion from Type 1 to OpenType, since we wanted to change the fonts’ data as little as possible. But the Adobe team developing the Times Reader came back to us saying that the text set with the new fonts didn’t look very good. (I didn’t have access to the actual app to test the fonts in context, so they sent us some screenshots and the text needed improvements indeed.)
First test after conversion
First test after the fonts had been converted from Type 1 to OpenType. Notice the ‘v’, ‘w’ and ‘y’ in Franklin Medium. The window is a basic AIR app.

I took a closer look at the fonts, and that’s when things started to make sense. The alignment zones, the standard stems values, and the glyph hints were completely out of whack. It looked like they belonged to some other outlines, not the ones in the font. When fonts are rasterized at large size (e.g. 72pt) and/or high resolution (e.g. 600dpi), having bogus hinting data is not that much of a problem. But if the fonts need to be used at small sizes in low resolution environments — as is the case of the Times Reader app — they definitely need to have good hinting data, otherwise it does more harm than good to the rasterization result.

So I corrected the hinting parameters, re-hinted the fonts, rebuilt them and delivered the new batch to the Times Reader developers. They acknowledged that the text looked better, but there were still a couple of new problems. For instance, the bars on the lowercase letters ‘f’ and ‘t’ were not aligning with the serifs of surrounding letters like ‘n’, ‘u’ or ‘y’. The difference in height was just one pixel, which doesn’t seem much. But if you consider that a lowercase ‘x’ is only seven pixels high when the text size is set to “Small” on the Times Reader, one single pixel is quite a lot. It’s definitely enough to be noticeable and distracting when you’re trying to read the news, that’s for sure. In this case, to correct the problem I had to do minor tweaks to the outlines of the glyphs ‘f’ and ‘t’; their bars where raised to match the x-height.
Lowercase t
Sample article and text enlargement showing the misalignment of the crossbar on the lowercase ‘t’.

All these adjustments confirmed once again that if something works for print it doesn’t necessarily mean that it’ll work for screen. What application developers often don’t realize is that they cannot just use any font for their project’s UI or its content. Some designs lend themselves better to that usage, but as you can see from the example above, the design alone won’t guarantee that the font will perform well on screen. So here’s a shout out to all you type designers and font developers out there: You need to realize that the fonts you put out should work well on screen, because the screen is increasingly the primary environment where your fonts will be seen.

One last thing the designers of the Times Reader struggled with was how fonts embedded with the new DefineFont4* format rasterize differently when compared with the previous format. The differences are often negligible, but in some cases the results are indeed noticeably different, especially when the text is set at small sizes. I’ve put together a little Flex app that tries to demonstrate it. The font used is Minion Pro Regular. Compare for example when the font size is set to 14 ppem. The x-height of the TextInput that uses the DefineFont4-embedded font is one pixel higher. What happens is that the x-height alignment zone that controls the top of the lowercase letters is forcing them to snap (i.e. to grid-fit) to a whole pixel. This ensures that the glyph features at the x-height stay aligned and don’t look fuzzy, but unfortunately has the side effect of somewhat distorting the proportions of the glyphs.
Hinting off and on
Sample article where the text is displayed with hinting turned off (top) and turned on. Enlarged words (bottom) displayed with hinting turned off (left) and turned on (right).

This effect was something that the designers were not happy with, and their first reaction was to turn hinting off completely. I sympathize with them, since I don’t like to see distorted designs either, and I understand that this doesn’t happen with fonts embedded using the DF3 format. But at the same time I value DF4 hinted text more because the rasterization is superior, and generally that makes text more legible. In the end, what we all found out was that by simply using fractional font sizes we could have the best of both worlds: hinted text with virtually no distortion.

Check out the video with😄 Senior Experience Design Manager Jeremy Clark and Senior Experience Developer Daniel Wabyick where they discuss their collaboration with the New York Times on the AIR-based Times Reader. And for further insight on creating a next-generation desktop news reader, watch the video with Jeremy, Daniel, and😄 Senior Experience Designer Justin Van Slembrouck which provides a behind-the-scenes look at their work on the Adobe AIR-based IHT reader.*Embedded Font Subsetting Using DefineFont4SWF file format specification (version 10) | (PDF, 940K)

4 Responses

  1. Narration says:

    A very interesting article, Miguel, and I am glad you got a chance to contribute to the future of the NYTimes. I would like to say that the mysteries you ran into on screen font appearance are not new ones at all. I think very strongly that Adobe needs to address all aspects of this in the ordinary commercial realm, where we buy fonts to use in PDF documents, for example. There, we find just as you say, that fractional font sizes are often the only way to get good appearance — and that the appearance could be better.Further, the PDF can be displayed at different sizes, so it is a compromise usually involving setting the document opening size to optimum(?), sizing the fonts, and choosing only those fonts which look reasonable at other sizes. You can see this is a pretty narrow box — and there is no particular acknowledgement from Adobe, although some fonts have much better screen hinting – the more expensive and the new of course. I would think that a lot of contribution can be made by pairing designers and engineers, to get proper solutions within the constraints of present screens.Publishing optimal font sizes in fractions as may be appropriate, step-locking in allowable PDF or Flash document resizing, etc. are the kinds of optimizations that come to mind. This then hints who can work in this best: designers and engineers who have to do with PDF being used on screens, and on Flash etc. applications.I hope Adobe will take this on with the intensity they’ve reserved for print documents. Screens are the present, much less the future, of much text. We can make the looks so good for paper, due to your work, and now we need the same on screen. Some quick work would be much appreciated, as the need for good looking screen documents has actually been present for recent years, and really restricts what we can use in the way of fonts.Kind regards,Narration[Adobe is always improving on-screen rasterization in its products. Try opening a PDF file in Acrobat 4 and then reopen it in Acrobat 8 or 9, and you’ll see what I mean. Improving text rendering on the Flash platform has also been a big priority for us, and a lot is being done on that front. Adobe’s approach has always been to put most of the “intelligence” on the rasterizer rather than the fonts; the hinting data on the fonts is used as guidance, not as enforcement. This means that improving the rasterizer benefits all the fonts and PDF files already out there, even if they’re ten or twenty years old – MS]

  2. Thanks for this post. I must say that I find Times Reader 2 to be much less readable than the previous version, for two reasons. First, the large font setting is still not large enough for me. As with all Flash apps, it ignores my platform (Vista) DPI setting, which is 120, making the app teeny-tiny compared to native ones.[That’s a good point. Unfortunately, the flash.system.Capabilities.screenDPI field is hardcoded to 72 or 0 on all platforms, except Linux. So it’s currently not possible to make an AIR app adjust to the DPI setting on Windows. – MS]But the real ugliness is that the fonts use grayscale AA instead of subpixel. On both Vista and OS X. But the enlarged screenshots in your post show subpixel AA. What’s up with this?[I took a couple of screenshots yesterday of the Times Reader running on Vista and the Times Reader running on OS X, and as far as I can tell the text rasterization is the same as in the images posted above. – MS]Thanks,Jonathan

  3. Jeffrey Skinner says:

    The promotional material is pretty vague. It says that there is access to 1 week’s NT Times. What about archives, (ie prior to this week) Is there any way to access that?[As far as I know, the local database keeps stored only one week worth of news. For older news you might have to go to NYT’s website – MS]

  4. Chris says:

    Hi,
    I like the design refresh, but the link to Miguel’s handy Flex app seems to be broken (?)
    [Thanks for telling us Chris. It’s fixed now. — MS]

Comments are closed.

Miguel Sousa

Team Lead of Type Development at Adobe Typekit. Responsible for devising solutions that get things done. Mostly font developer, but also typeface designer, time permitting. Deeply fascinated by the symbols that represent the spoken word. Hates the cold and thrives in the face of challenge. Chocolate junkie & t-shirt aficionado. @forcebold on Twitter

A new face for Adobe

David Lemon · May 5, 2009 · Making Type

Introducing Typekit

Jeff Veen · May 27, 2009 · Using Type