On text on the iPad

Since the launch of the newer, shinier iPad, some people are unhappy with iPad magazines. Here’s an example that’s been floating around Twitter:

One of the limitations of The New Yorker app for iOS becomes even more apparent while reading on the new iPad’s high resolution retina display.

I’ve noticed in the past that the first few articles (Talk of the Town, etc.) in each issue are text selectable and therefore able to be copied, words can be defined using a built in dictionary, and these pieces can be emailed and tweeted. The rest of the magazine is like a tiff or jpeg — everything is baked into page and there is nothing you can do with the text.

This has always been annoying and I suspect is part of the reason each issue weighs in at hundreds of megabytes (a magazine of mostly text mind you). … For some reason they don’t use rendered text for their main articles as they do for their first few shorter articles. And the baked in files, whatever they are, aren’t high res enough for the retina screen. And what’s terrible is that if they fix this, the file sizes of each issue will get even bigger. Perhaps twice as big.

I think they are scared of people being able to copy and paste their content and share it. But if they want to win over converts to the digital version of their very fine magazine, they need to get over their fear and make the best possible magazine for the iPad.  Not cripple it in order to try to lock it down.

Similarly, notable Apple fan John Gruber and co on The Talk Show* podcast: “It looks like total ass. It’s a really, really stupid way to put a magazine on screen.”

Both are commenting on The New Yorker for iPad, which is made by The Condé Nast publications using Adobe’s Digital Publishing Suite platform. But the same applies to many magazines using rival technologies, too, including ones that I work on.

At this point, a disclaimer: this post does not represent the views of my employer. It represents the views of a guy who’s spent well over a year worrying about iPad magazines every single day, to the point of near obsession. To my knowledge, my employer does not have an official position on this issue.

Rasterising text is not DRM

With that out of the way, here’s the thing: I very much doubt the people who make The New Yorker have ever considered rasterising text as a method to prevent copying-and-sharing. Preventing the copying and sharing of magazine content is depressingly difficult once you’ve printed it***. I’d put money on them having chosen it for the same reason that many others have: because they’re working on a magazine.

Let me elaborate.

There are, broadly, three ways to put text onto an iPad screen: native, HTML and rasterised. Native text is rendered by the iPad inside a textview, HTML is rendered by the Safari webkit engine in a webview, and rasterised text is rendered as an image containing text. There are very obvious benefits to the first two options: both native and HTML text can be selected, copied, dynamically resized (given the option is coded in) or even read aloud. And, if Apple releases a newer device with a higher screen resolution, it’ll render out beautifully with no amendments to the issue or app required. Over at Tap!, one of very few magazines to use native text, editor Chris Phin summarises the benefits neatly here.

And none of this is possible with rasterised text. So why do we use it?

Layout and text control.

Use native or HTML text in an app and you’re at the mercy of the engine that renders it out onto the screen. In many cases – including my own non-magazine apps, incidentally, which use a combination of the two – this is just fine. If the text is relatively short and principally functional, and you don’t really mind where the lines break, or if paragraphs end up with orphans, then it’s OK. Text in columns is a particular pain, although CSS3 has made some strides towards improving matters on this front, and we’ve managed to come up with usable solutions for news-based text.

If you’re working on a magazine with long format text, however,  where the layout of the words on the page is fussed over to a frankly obsessive degree in order to give the very best possible experience to the person reading a 4,000 word feature, this borders on the unthinkable. Let the device handle text layout and you’ll end up with nasty line breaks, widows, orphans, the works.  And if you want to wrap it elegantly around image runarounds, or tweak the tracking on headlines so that they’re exactly right, you can forget about it (obviously, giving the user text size control makes this even worse).

And this matters. If you’ve ever been distracted by a nasty break in a poorly set book, you’ll know why. Well set text is invisible, badly set text is not. It’s one of the reasons why it’s more comfortable to read, for example, an article in the print New Yorker than it is an online version: websites, which of course are entirely dependent on browser text rendering, have precious little text flow control.

Raster, man.

And so, rasterisation. You set the text perfectly in a tool such as InDesign, run that down to bitmap images (not Jpegs, in our case, as it happens, but still bitmaps), and you put it on the screen. And it gives readers the experience of a magazine, with the perfectly honed reading experience they expect. And we care about this stuff – I’ve even seen a grown man break out a type depth scale on an iPad screen to check the leading.

The iPad 3 arrived with a screen that’s twice the resolution and, yes, text rasterised  on an assumption that it’ll be shown on the iPad 2 screen doesn’t look perfect – the images used to hold text are being scaled two times by the iPad. Many magazines will have to update. You can bet that, like us, they’ve been stockpiling retina-resolution art for some time in preparation for this, and no, it’s not always going to double-to-quadruple issue filesizes (each page is not a single flat image). And we plan to deliver retina-quality images only to retina-capable devices, of course.

So while rasterising text is not a perfect system – to state the blindingly obvious, there is no perfect system – and for a few weeks after the launch of a new iPad product it’s one that can be troublesome, but there’s a simple reason that we do it: an iPad magazine should look as good, if not better than, a print one. And those who see only a few jagged edges and declaim it as the stupidest thing ever, and so on, are seeing only the technology, and missing the point: in a magazine, it’s not only the words themselves that matter.


* There’s some odd stuff said in this podcast, incidentally. “There’s a reason why the New Yorker was not included in the Newstand by default”, it says, suggesting that this was an Apple call – Newsstand status needs to be flagged by the developer. (UPDATE – Thanks to @bobrudge and @wmerrifield, who both tell me that J Gruber is referring to the titles pre-loaded, or not, on an iPad given to him by Apple).

**  Previously there was a moan here about pixel doubling. I checked with a loupe, and that is indeed what’s going on. My error.

*** Don’t ask. I’ll become even more boring.

4 responses to “On text on the iPad”

  1. luca says:

    Why not use SVG?

    • Tom Royal says:

      SVG text doesn’t offer any advantage over, say, HTML with CSS – it’s rendered out by the client according to some relatively basic style rules.

  2. luca says:

    You can export your InDesign project with well formatted text as a SVG (or PDF if you like proprietary formats) and the rendered one will leave the words in the same positions unlike HTML+CSS.

    The rendering of the single letter may still be different from the InDesign’s engine but if the main problems are widows and orphans I think it’s a viable solution.

    • Tom Royal says:

      Yes, in which case we’ve produced a flat page, no better than a PDF – I’m not convinced that’s a good experience at all on a touchscreen tablet (no better than paper, in fact).

All © 2022 Tom Royal