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 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.

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.

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 XD 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 XD 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)