The Nook Book Look: Default Settings

About a year ago, a publisher friend went into a tirade about how eBooks weren’t something publishers or consumers wanted but were being forced on the industry by “the tech people.” I was quite puzzled by his comment but knowing that my friend is not prone to hyperbole or paranoia, couldn’t dismiss it. Now I get it. In this thread on MobileRead some eReader developers are pretty down on publishers and book designers:
It’s a discussion about defaults on the Nook:
http://www.mobileread.com/forums/showthread.php?t=165692
With the system upgrade in January to 1.4.1, Nook decided to turn off publishers’ settings on its eBooks by default. They make a reasonable argument. If a reader has carefully set their reading preferences, they shouldn’t have to reset them for each new title.
But, if the publishers’ defaults are off, the reader could well be missing part of the reading experience (even some of the non-English characters) that the writer intended, and never know what they were missing. Okay, I’m a bit ticked off that hours of my thoughtful work on a YA title may never be seen by readers. But I’m not so in love with my work that I’d want to overrule an eReader user.
It comes down to this, do you think most users take the time to adjust their settings, or expect that the book’s producers have made these settings for them? I’m far from convinced that every user thoughtfully selects their book settings, and publishers’ designs have been selling for decades. I think the default should be the publisher’s defaults, the Nook users who are most likely to set their own preferences are the ones who will know where to turn off the defaults.
Another argument for ignoring publisher’s code is that often the code is bloated. I can imagine the issues engineers face when the code vomited out by auto ePub generators is multiplied by thousands of titles.
I see this as an argument for Standards. Better adherence to standards across devices would lead to leaner code in ePubs. I feel like I have to carpet bomb my files with text-align: center; just to get a centered paragraph consistently across devices.
Ultimately, the reading public will show us what they want, buying books, apps and devices that they like best.
So let’s make cool stuff, work together on standards, and respect what we all bring to the table.

Advertisements

If Only Font Pirates All Looked Like Johnny Depp

Font issues in eBooks

Recently, #ePrdctn hour on Twitter hosted @desi_leyba, @sugarlange, @Fontscom (http://www.fonts.com) to talk about fonts in eBooks. The whole hour was taken up with the thorny issue of rights.

It was considered the publisher’s responsibility to get the digital rights to each font they’d like to embed in an eBook. If the fonts come from different designers, each designer must be contracted and a deal worked out, and payment made.

It is only fair that font designers get paid. It takes hours of work, tremendous talent, and nearly obsessive attention to detail to make a good font.

But the system of contacting each font designer is time-consuming work for any publisher who wants to do the right thing. It might not be in the font designer’s interest either  — anything that makes it hard to get paid is bad for business.

Even stranger is obfuscation. (The most appropriately named technology EVER). It seems that in bundling a font into ePub, the font is intentionally obfuscated (scrambled) to prevent someone from extracting the font from the eBook and using it. How many people can crack open an ePub or Mobi file? Unfortunately, not all reading systems will display an obfuscated font, an obfuscated font is so safe from piracy that it is pretty much useless.

Also, it seems that getting the digital rights to use the font in an eBook does not prevent obfuscation.

The easy answer is not to embed fonts at all, or use freeware fonts, and there are many fine choices. (See links below) The downside of this? Talented, obsessed font designers might not be able to make a living making beautiful fonts.

Perhaps another business model?

Could book producers/publishers pay a subscription to a font foundry or font collection, and the eBooks produced during that time could use any of the collection’s fonts? Could a font license be required in the CSS @font-family declaration or the meta tags to be a valid ePub? I know, pirates could steal that, too.  Again, how many people crack open eBooks files?

Maybe just reward the good guys, a “font seal of approval” for companies that negotiate for digital font rights. It would be even more compelling if the big retail outlets required some sort of seal or certificate to sell the book.

This is just like DRM issues. How do you protect the livelihood of creators without technology so frustrating it makes it hard for customers to stay off the high seas with a parrot on their shoulder?

Font design resources

Open-source Fonts

Sticky Wiki: What’s the Best Way to Share eBook Production Information?

Sharing is caring. 

If you haven’t already, sign in to Twitter and follow the #eprdctn tag. There are some talented and generous professionals who help each other out with eBook production. We’ve been at it for more than a year now. (Begun by @crych, we are in your debt.) There’s an hour of presentations and chat every Wednesday at 11am New York Time, you can check the schedule here.

The problem is, tweets are ephemeral. There are some ways of capturing particular hashtags from a particular time span, or from a particular person, but if you’re trying to remember that text-indenting hack you read a few months back, well, you’re likely out of luck.

There’s some links on delicious.com, tag #eprdctn. We’ve tried a wiki, personally hosted by a frequent contributor to #eprdctn. However, we are competitors also, so neutral territory is preferred. The the group parameters are:

  • neutrality, no one contributor should profit in money or reputation from the work of the group as a whole
  • free, as in no fee, access to the information
  • easy to use and maintain, because we’re all busy making a living

One sensible suggestion is to join up with MobileRead, through our own URL. (generously and anonymously donated). It sure beats reinventing the wheel.  What do you think? And why not try it?

eProduction Jumpstart

EasyPress and Adobe highlight their best features, Joshua Tallent convinces me to buy his book, and I’m guessing no one knows which workflow is most efficient without trying them all.

The morning tech session focused on case studies of eBook conversion. First up was James MacFarlane of the cloud-based auto conversion service EasyPub from EasyPress. This web-based platform looked like it did a pretty fair job of converting files, although in a one-on-one demo the day before, there had been a glitch. McFarlane suggested starting with an Indesign file with style sheets universally applied (all of your backlist documents are totally style-sheeted right?), both character and paragraph sheets are acceptable to the system. The file is uploaded to your client portal, and you map document styles to CSS styles using a point and click interface. Then the file is automatically converted for all eReaders, except Nook, which requires an extra process.

Kiyo Toma from Adobe showed off InDesign 5.5s snazzy new EPUB export features. Lots less code junk, human readable-line breaks, no more anchoring images (woot!!!), image optimization improvements, image spacing you can set in InDesign. Lots of the #eprdctn folks on Twitter have bought the InDesign update, and love it. Is it faster than starting from scratch and hand coding your document? I’m not sure. It’s certainly an advantage to have one document for both print and web, it would make corrections and iterations easier to implement and track. Many current eBook production workflows are blends of automatic conversion and hand coding-fix ups. I’ll be curious to see how the InDesign 5.5 workflow stacks up to that in terms of cost and efficiency.

Joshua Tallent of eBook Architects suggests this Kindle workflow: ePub>remove fonts>add guide to OPF>minimize CSS>remove borders>add page breaks. Joshua was also passionate about the need for good document structure and human-readable code as the best ways to a) provide accessibility and b) future proof your documents. My last note from this session is “Buy Joshua’s damn book.” So I plan to.

One participant raised the question, “Can you just write the html from scratch like a website?” Which kind of brought the panel discussion to a halt. Of course you can. I find it much easier than cleaning up the code from Adobe 4.o, especially for a fixed-width title. Figuring out which CSS tags work well in browsers but are not supported in reading system x or y or z, that’s kind of another story. Would it be more efficient and cost-effective to use the EasyPub service or upgrade to InDesign 5.5? Hard to say. Start small and fail fast? Begin with what you know and build from there?

So Are Publishers Making Any Money with this Ebook Thing?

The session in which three publishers talked about process, discipline, waltzing and the vise. (Not vice)

Liisa McCloy Kelly from Random House said that making an EPUB before EPUB 3 was “like waltzing with both hands tied behind your back and a weight on one foot.” (I think of it more as Tarantella in the dark while the stage shifts constantly underfoot) She said that Random House has 5 different eBook processes, the most complex of which requires teams of product managers, HTML coders, designers, R&D and testing. She recommends encouraging designers to keep an eye on digital conversion, to think about variable sizes.

Bob Young of Lulu stated that the core value of the internet is that it connects everyone of us to everyone else. (Mostly true, but I worry about the digital divide. More tech in libraries!) The role of publishers, he went on to say, is to match people with something interesting to say with people who want to hear it.

Ken Brooks of Cengage Learning was all business. Publishers are caught in a vise, as less cash for operations meets lower profits from products. Efficiently managing process, vendors, and technology is key. If each new project requires a different flow of process, you’re dying the death of a thousand cuts. It’s better to determine one or two ways to work, and have the discipline to stick to them, “ruthless management of complexity and standards is more efficient.”

How do you determine which projects to tackle? You aim for projects that are low in complexity and costs and high in payback, and he put up a great chart:

How to Determine Which Projects to Pursue

A loose interpretation

This is a good way to visualize this common sense approach. But in this new and rapidly evolving marketplace, where do you get the data? Perhaps the scarcity of data prompted these pieces of advice also:

-Brooks recommends that we start with the end in mind, and work incrementally rather than wholesale.
-And stick to standards. “Standards represent our collective experience, you might as well benefit from what other people know.