

Great breakdown on what's wrong with most iPad magazines - Brajeshwar
http://www.justatheory.com/computers/apps/conde-nast-ipad.html

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

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

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

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

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

