back
7 comments
The New Yorker digital assets are a completely technically suboptimal solution. Obviously in life other non-technical issues can take precedence.

The New Yorker online edition (archives.newyorker.com) consists of a javascript interface that displays 760x556 jpegs for browsing. Now we get to the good part: if you click on a page to zoom, it brings up a 1228x900 png overlaid on a 1228x900 jpg. The png is the high frequency information (abrupt black and white transitions) and the jpg is the low frequency information (large swathes of colour). I’m confident the data is processed by DjVu to perform this image separation (if you dive the image urls ‘djvu’ is one of the directory names). The hilarious part is that they OCR their images and this text is in the html. Even more fun is that there is a separate 1613x1181 jpg when you print from the online edition but as we know jpg is totally inappropriate for black and white text.

So to summarize the data is already passed through a DjVu toolchain to generate a djvu file but they render all of these ridiculous image sizes in various formats to fit their terrible viewer.

I don’t have an iPad so I can’t confirm but I’m pretty sure the Kindle New Yorker app runs on the same Adobe AIR platform. For the Kindle, each issue clocks in at around 100 MB and consists of a 1024x600 png for each page (I assume the iPad images are 1024x768) and a whole bunch of other HTML/XML assets. I’m running this on an android phone and the issues are stored under “/mnt/sdcard/The New Yorker/.library/The New Yorker/” so the data structure is pretty transparent.

Harper’s is much more sane: they serve gifs or pdfs. From the pdf properties it’s obvious it’s direct output from QuarkExpress.

The Economist has the best iPad experience of any magazine I've checked out to date. A great browsing experience, vector text, etc. Apparently it was done by an Australian development house; I wish more magazines/newspapers would do something this good.
That's a great technical analysis, but I think it misses the primary business reason why Conde went with images for most magazine apps - it's cheaper and faster for them to create content during each 4-week release cycle.

Oddly enough, I know a lot of people (myself and roomate included) who have been specifically waiting for an iPad version of Vogue to see Conde's implementation decisions.

> it's cheaper and faster for them to create [image] content during each 4-week release cycle.

Would you elaborate on how it is cheaper and faster for them to create content, esp. text content, by going the image route rather than simply keeping the text as text (given that the text has to start out as text in order to be rendered into any image format in the first place). I simply do not see any reasons how performing a text->image transformation can be cheaper and faster than simply keeping the text as text.

I work with a children's book publisher that faces a lot of the same challenges. They're a much smaller company in a completely different market, but their roots are providing printed product to customers.

It's easy to take for granted everything leading up to the final product. For publishers who create physical books, electronic publishing is a challenge, largely because their talent doesn't necessarily have any skills in this area. Any freelancer web designer who has worked with a print designer knows what I'm talking about. For the people who live in the print world, rendering the page to a giant image is analogous to what they do with their print books. The destination of the printing process is, after all, a rasterization of the layout on paper. They see the final product, and everything beyond that is a black box to them.

So, everything a print publisher does leads to one final resting place: rasterization on paper. When you decide to make the jump to an electronic platform, the point in the process you diverge dictates the expense. The choice, from the publisher's perspective, is to:

A) Hand off their layout to this tool that Adobe provides and be done with it

B) Create some custom toolchain and process that converts the content to a better format

Keep in mind that option B is completely opaque to many of them. The commercial printing process has been around a long, long time, and for many of the managers that work in the publishing industry, the process is as intuitive as riding a bike. They don't even think about it. This means that choosing option B is more than just changing what they do, it's changing who does it. This means hiring more help, which is expensive.

Then there's the distribution problem. Many publishers don't handle their own distribution, and publishing each title as an individual app isn't a desirable option either. Choosing option A, or something like Zinio (also image based), means not solving "yet another hard problem".

Many publishers are in survival mode. The publisher I work with is fortunate to be so small. They had some early success with web-based products that returned huge margins, so the management decided that putting resources there made sense. Their staff have attacked the electronic-publishing learning curve and are coming around. I suspect that for many large publishers, the shift in direction won't happen. Their momentum is too great, it may ultimately lead to their demise.

It depends at what stage in the process the iPad team gets the material. At a guess I'd imagine they only get the final inDesign or pdf files shortly before those files are ready for print. Taking the inDesign files, extracting out the text and images, redoing the layout in whatever you use to layout iPad magazines (html/css?), and getting the new layout approved by whoever approves layouts will take much more time and effort than simply making a couple of minor tweaks to the inDesign file and hitting Export to jpeg.
no CN are an old school publishing house with all "chalenges" that implies :-(