More on TechnologyTell: Gadget News | Apple News
Ebook formatting from a publisher’s perspective – it isn’t easy or simple!
February 9, 2010 | 10:21 am
|
By Paul Biba
Editor’s Note: I received the following email from publisher Linda Houle and I thought it should be shared with all our readers. PB
I recently noticed there seems to be a trend toward “blaming” publishers for poor ebook quality. As a publisher I wanted to bring something interesting to your attention, with the idea you might want to explore it as a possible blog topic.
I mentioned “apps” and formatting in my subject line because I found out something about our L&L Dreamspell ebooks. An ebook that I had formatted perfectly in Mobipocket .prc came out either beautiful, or awful, depending on which “app” that was being used to view it on a smart phone.
My experience is only with my son’s “Droid” phone from Verizon. I’m not sure if this same thing happens with the IPhone and other smart phones. When I asked my son to download one of our books into his Droid phone so I could look at it, first he had to find an application. He found two apps and downloaded them. One of them held all the formatting, and even showed the black and white illustrations in the ebook as crisp and clear. The other application totally stripped out all the formatting, including headers and indents (no indents makes it a bad reading experience!) and it also stripped out all the illustrations. Anyone trying to read this particular ebook with the “second” app he used would have said L&L Dreamspell’s ebooks are crap, and would have put us on someone’s “Hall of Shame” list.
I understand the Teleread blog post that mentions a “Hall of Shame” refers to editing and typos. Our books are very well edited and we try to catch all the typos. To me the formatting issue is a huge problem that we have less control over than I’d like.
And to address the other part of the formatting problems we face, as a small press: the book distributor “meat grinder” system of converting the files we send into other formats. The Fictionwise site requires a pre-tagged Word RTF file, which they then turn into many different formats. What comes out the other end of that meat grinder may be truly awful, and we can’t do anything about it! Our files at Fictionwise also get transferred over by Barnes and Noble for their Nook reader. That’s double trouble!
Our books on Amazon for the Kindle are converted from our Mobipocket files. The files we publish at Mobipocket are checked and double-checked for quality. But what happens when Mobipocket turns them into Kindle? I had one author receive a lot of complaints about how her book looked on her friend’s Kindle. All I could do was apologize, show her our nice Mobi file, and tell her the process we have to go through. Perhaps when Amazon changes to their 70/30 split in June, favoring authors/publishers, they’ll have us go directly through the Kindle DTP and not use Mobipocket any more, where we currently get a 50/50 split. I wanted to keep 50% for us and our authors and not take only 35% that Amazon offered when they opened up the Kindle DTP for authors and publishers.
These are interesting times for publishing, and I’m glad that we are already established with ebooks, and we’re about to expand into other ebook markets. Now that we have the current Adobe InDesign CS4 we can convert directly to epub. But that isn’t as easy as it may sound. The InDesign file must be formatted carefully or the epub that comes out the other end is awful.
I don’t think the average reader has any idea how much work goes into book production, whether it’s for trade paperback, or multiple ebook formats.
Thank you for your time – keep up the great work on the Teleread blog!
Linda Houle
L&L Dreamspell
|
Related Posts:
Previous
SUBSCRIBE TO RSS
Comments:
Linda is correct that much of the problem lies in the application used to view the ebook. I noticed that with a series of books I was reading on my Sony 505. On the Sony there were lots of formatting errors but if I looked at the same file using Calibre, none of those errors appeared.
This is not to suggest that publishers are blameless; they aren’t. It brings me back to my suggestion that publishers band together to create a repository where there is only a single format available and where bookbuyers go to download books they have purchased at booksellers. (See my blog post suggesting this at: http://americaneditor.wordpress.com/2010/01/21/a-modest-proposal-iii-dying-days-of-giant-publishers-part-2/).
Look at this like TV. Every TV sold in the U.S. can display the picture correctly because there is a single standard. In pbooks, every pbook conforms to a single standard. Publishers need to enforce a single standard, no conversions, and a single DRM scheme, just like TV.
As regards InDesign CS4 and ePub, again Linda is correct. Although ID CS4 is a leap forward, Adobe still has a long way to go to make the conversion seamless.
In my experience the large majority of really ugly formating problems come from the fact that the publishers try *too hard* to control the formating.
Whenever I get an ebook that looks crappy, I strip it down back to html, run it a couple of times through HTML Tidy and and strip out all the style sheets and explicit formating till I end up with a bare bones html file. Using just h1, h2, h3 (as needed) for chapter headings, and plain p elements for paragraphs and em and strong elements for italic and bold text.
At that time the file is usually down to less then half the size of the html that came out of the ebook.
After packing this stripped down html back into a prc file, all readers I got (CyBook Gen3, Windows Mobile Phone, PC) display the ebook in a very nice and easy to read format.
In the absence of specific formating instructions, the reader software uses a default formating based on the element types, taking into account the needs of the particular reader device used.
I understand the formatting issues are complex; personally I think publishers shouldn’t even try to sell ebooks that contain a lot of charts and tables. I’ve also noticed that sometimes the formatting problems (like strangely indented paragraphs) will change depending on the font size you are using.
I still contend there are more basic typos and misspellings in ebooks. I’ve often wondered if the file that was uploaded for the ebook was actually a rough draft of the book.
Just this week I finished a book where the dog’s name was spelled three different ways and another where the famous female spy was referred to as “Mata Harry.” It happens so often that I’m starting to believe publishers are not putting as much effort into their ebook offerings.
Occasionally I buy an ebook that is beautifully formatted so I know it is possible. I recently bought a cookbook that was incredibly well formatted with crisp gray scale photographs, working links to purveyors of specialty ingredients, and an excellent table of contents with links to each chapter, sidebar, and recipe. Each recipe started at the top of a new page and the book’s cover fit into the Kindle screen perfectly.
I’d add that ebook quality isn’t just formatting.
Yes, formattng matters.
Quality content matters *more*.
In fact, the bulk of ebook complaints I have and have seen online aren’t about presentation (except with PDF rendering and ePub hardwiring) but rather the quality of the *content*.
Ebooks are, first and foremost, about content.
The story.
The information.
Content quality is the publisher’s reponsibility. Editing, proofing, spell-checking, grammar checking, fact-checking (for content sold as non-fiction). Formatting might matter on print books but in the ebook arena, where errors can’t be blamed on faulty typesetting, the finger points straight to the publisher that allowed (often eggregious) content errors to flow straight to the consumer.
Yes, some apps have rendering issues.
And a lot of ebooks ship with poor formatting.
A lot of the better reader apps let the reader override the formatting to compensate for this poor formatting. But no app can fix a poorly proofed book full of grammatical errors or ocr errors. When you see complaints about ebook “quality”, odds are that 60-70% of the time the complaint is about document errors, not technology issues.
Blaming the reading app is like blaming the typesetter. (“Sorry. Itt happens. Its out of our control.”) Old hat. Except there is no typesetter to be the fall guy here and it is *easy* for consumers to verify if and when an issue is caused by the reading app and when it is caused by the ebook. Apps don’t transpose characters or paragraphs, apps don’t substitute the wrong homonym on the fly. Apps don’t mess us content. And way too many ebooks sold come with low quality content.
Blaming the reading apps can be seen as a smokescreen and an effort to actually carrying out a *core* function that properly belongs to the publishers.
At this point in time, ebook buyers are a little too tech savvy to be distracted by those kinds of excuses. Not at a time that the big publishers are flexing their oligopolistic power to raise prices and limit competition.
Forewarned is forearmed: ebooks are no longer going solely to enthusiasts and early adopters who are (somewhat) foregiving, they are going to consumers. We live in a consumerist society and consumers are all too willing to scream bloody murder and demand satisfaction.
High price + low quality = low value in anyone’s book, right?
High prices = high expectations, so the screams are only starting.
As Thorsten notes above, minimizing “control” will help. But if eBooks, eMagazines, eXXX are going to succeed (they will). We are going to have deal with complex documents and allow a level of control appropriate to the mix of content and devices.
We live in a society where the author/publisher must recognize that the consumer is in control. The consumer wants to read their content on their device in their way. Limiting the customers options will limit the exposure of the written word.
Plain text has a low viscosity, throw some figures in there and the viscosity (ability to nicely flow onto the pages) increases dramatically. The industry is in dire need of a set of tools, specifications (EPUB++) and rendering applications that can handle delivering complex documents to a wide range of devices – phones, purpose built reading devices, large monitors, devices for the visually impaired, etc.
Back in the 90′s we used to say it’s time the publishers joined the 20th century and began setting from our pristine files rather than paying (frequently) non-English-speaking people to retype (badly) that which we’d spent months perfecting. (my first page proofs were filled with upside down exclamation points.)
Seems to me it’s time for the e-book distributors to join the 21st century and figure out a way to accept files already vetted. That meatgrinder operation sounds ridiculous, and frustrating.
Much of it comes back to the old DRM nonsense. If readers had the ability to manipulate the files to adjust to their readers, they’d be a lot happier, and the publishers would have a lot less work.
Thorsten hits most of the key elements in his post, a topic that I dealt with recently at my blog The Secret Life of eBooks. We’ve got three really huge obstacles in front of us as publishers producing eBooks. Devices and desktop or mobile reading software all have their own algorithms for laying out content. The quality of native layout, even of that fully stripped down file that Thorsten mentions, can vary widely from platform to platform. Some of the eReaders are opting for user controls that let a reader set their own specifications for control of the display design. Even these do so with different degrees of success.
The second problem is that huge amounts of eBook code, especially in the ePub format, is used by the creation application to circumvent the automatic controls built into the specification and the devices. The most common that I’ve seen is the use of the “p” tag and a “class” to define every element. We want our eBooks to be read and appreciated by live human beings, but we have to realize that in the world of eBooks a machine has to read them first. If we circumvent the codes the machine uses to display content, then it can’t render it properly.
The third area is the fundamental understanding of design and the designer’s responsibility when it comes to eBooks. It is a new era. We can no longer design books knowing the exact size of the finished work. It might be less than 2″ wide, or it might be viewed on a 20″ desktop. The reader might be inches away from the content or feet away. There is no way possible for designers to create a “hard” design for every possible set of viewing circumstances. It was so easy when we knew the book would be a 6×9 trade paper. Now it could be any size. This requires a whole new understanding of design in a world that holds anything static as anathema. Designers aren’t being prepared to design for this world.
There is a shared responsibility for the look of eBooks on the part of device/software makers, designers, and publishers. It may seem impossible, but we made it through the conversion from hot lead to cold type to desktop publishing and good design survived. It will survive this one as well.
I strongly endorse Thorsten’s comments. For a simple book of fiction, the publisher should do as little to “beautifully format” the book as possible. Fictionwise’s “pre-tagged Word RTF file, which they then turn into many different formats” usually produces a good ebook. I’ve never experienced “What comes out the other end of that meat grinder may be truly awful…” with their titles.
Standardization of ebooks is in the publishing industry’s hands. If they can’t manage it, and if they can’t streamline their workflow so production of an accurate, simple ebook doesn’t come almost automatically, some of them deserve to go out of business. I’m beginning to suspect publishing is overproducing, leading to low margins and poor quality. That way lies madness.
Regards,
Jack Tingle
As Ms Fancher points out above, it is pretty clear that the BPH production process is *seriously* broken if the finished product is actually inferior to the authors’ submission. Which is unconscionable given how cheap and simple proper document management systems are these days (US$200 buys industrial-strength server software + a state of the art document management system).
A couple of author friends of mine actually run a home Sharepoint server they configured themselves to host their various short stories and novels-in-progress to take advantage of its versioning, revision-tracking, and backup features.
By contrast, several comments I’ve seen around here about how the BPHs manage their documents internally (PC-to-PC ftp and sneakernet) makes it clear their business model isn’t the only part of their operation stuck in the wrong century.
Odds are those folks have never even heard of Deming…
I have to agree with Thorsten here. While I am not an author or editor, I am a programmer. For most web pages, the more you try to format a web page for a particular browser, the more you end up breaking it for other browsers. I have found that the simplest code formatting gives you the most portability for different browsers and screens. While it may be hard to let go of formatting a book just so, the lightest touch gives the most portability.
Now folks, I’m just a simple-minded engineer, but it seems to me that every problem in the posts above me was caused by moving to something more complex than a dead-flat ASCII file. Of course, I use Notepad to edit HTML, so maybe I’m just an anomaly.
@D. Duck – No, there are useful, attractive ebook formats more complex than simple text. Most of them work fine, and give the author the useful ability to italicize, embolden, change fonts for emphasis and scene indication, and imbed simple graphics.
They also give idiots the ability (after great effort, thankfully) to make the ebook look “beautifully formatted” for the single case he thinks is the best, and absolutely unreadable for everyone else. Thereby hangs the complaint.
Regards,
Jack Tingle
I agree with Erik Peterson. As a web designer who also does a bit of ebook formatting on the side I know how designing for web browsers and for ereaders is similar. The best bet is to know where the majority of your readers are coming from and design/format for that (my guess is it’s the kindle) and somehow let the readers know where it looks the best, perhaps on the website. The other percentage of your readers might have a few hiccups while they are reading but as long as it’s still readable I don’t think you should worry about them. I know it’s harsh but what can you really do?
You can’t really have it both ways with so many different standards and hardware items. Either you do everything in flat files so you avoid formatting problems, or you quit crying about the ones you have.
Although, as Felix Torres points out, ain’t no format issue leads to ‘spall chick poor blames’…
On the other hand, she plainly admitted that her entire quality department consist of her son’s droid.
I thought at first that it was a joke. How do you want to churn out a decent work in that condition?
It would be like Toyota engineers admitting that they don’t test drive theirs cars, they just drive bikes and just ask their sons/relatives when they need feedback(admittedly it’s also seem possible given the recent news).
What you do is you use ADE to preview ePub and you use Mobipocket Reader & Kindle Previewer 1.6 to view your eBooks. If some other viewer doesn’t work well with your eBooks, that’s not your fault. That’s the program’s fault. Most readers use ADE for ePub. So using ADE on your computer is a good way to make sure it looks good. The Kindle is a separate beast so the previewer is a good idea to use. For those that use Mobipocket of some kind, Mobipocket Reader is what you use to view them.
And yes, some of the meatgrinders such as Smashwords do a really poor job at converting your source into multiple formats. But, If you are able to directly upload your eBook like you can with B&N, there is no reason for it to look bad.
I was looking at the latest Star Trek eBook from Simon & Schuster and the ePub is dreadful. The CSS is a mess. They have no idea how to embed fonts. The code for all o that is a nightmare. Because they botched the embedded fonts, they caused the CSS not to actually work properly in ADE. And because of this, the ePub looks very poor. This is an example of how not to do things. It’s like they just exported the document and didn’t bother to look at it.
Jack, DD and Erik as some who managed a web design business for more than three years I can say you are so so right. Leind .. I had exactly the same response !
Firstly this article is a defence of ‘formatting’ issues only. Yet the vast majority of complaints are about appalling and unacceptable editing and typos. So from the start it is a completely different issue from the one that most complaints hereabouts have centred on.
As Jack, DD and Erik have clarifies the biggest problem is with the obsession with control, a quite amateurish approach to testing and an ingrained shirking of responsibility.
Clearly there are problems with layout and formatting of works with non standard text and images. But the attitude that it’s all someone else’s fault and when customers get below standard product for their money, they should blame someone other than the publisher – is completely unacceptable.
When you offer something to the public that is sub standard is is your fault. if you cannot create an adequate standard then do not offer it for sale until you can solve your problem. Take responsibility and stop trying to pass it off to everyone else in the vicinity.