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

Learning to wiki – and one complaint

It’s here! The eprdctn wiki, a place online where we can share eBook production tips and hacks. This just might help level the playing field in an industry where accurate specs are hard to get.

Big thanks to Toby Stevenson of eBook Architects who worked with the kind folks at to create the wiki. Check in with the eBook Ninjas podcast (always a worthwhile listen), #48 is “wikilicious.”

The wiki is only as good as the information shared. So I figured I’d do my part. But first I had to learn to wiki. I am happy to report it is easier than writing CSS for mysteriously inconsistent reading platforms.

My first attempt was to add a link to, people have been saving #eprdctn links there for a couple of years. It seemed the best place to put this was in some sort of general information article, and that is under “The famous #ePrdctn Twitter Group.” (Are we famous? Wouldn’t infamous be more fun??? I’m just sayin’) It took me a couple of tries to get the link the way I wanted it:
gave me a link with “” for the text. I hope Dale DePriest, who started the article, didn’t get an email update every time I tested the link.

Next I figured I’d contribute to the Holy Grail, a table listing CSS support by device started by Robert Nagle and Nick Ruffilo. It’s simply an html table! I needed to add comments to be sure I was putting the right symbols in the right columns.

My one complaint is that I need a differnet password for the eprdctn wiki. I can’t use my existing Mobileread password and account, or link my eprdctn wiki activity with forum posts. (except an url, of course)

You can add your own article if you have information about new topic. Its surprisingly easy to contribute, and every little bit helps build our knowledge base.
So what do you know?

If Only Font Pirates All Looked Like Johnny Depp

Font issues in eBooks

Recently, #ePrdctn hour on Twitter hosted @desi_leyba, @sugarlange, @Fontscom ( 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, 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?

The Coolest eProduction Stuff I Could Find

In which I learn a fixed-width EPUB previewing workflow from an expert, and the CSS Regions demo makes my jaw drop.

Between the technical sessions, I spoke with a woman from the audience who had answered an iBooks question. It turns out she works for Apple, and kindly shared her fixed-width EPUB proofing workflow with me. I haven’t tried it yet, if you try it, let me know how it works!

<!– thanks to everyone for the feedback, steps have been updated 6.3 –>

  1. In the CSS, define dimensions for the body. Its easiest if these dimensions match the viewport dimensions. Also define a border on the body. This will outline the page, making it easier to place the elements on the page. Remove this border before publishing the book. body { width: 400px; height: 300px; border: thin solid red;}
  2. Once everything is previewing well in Safari on the desktop, preview in Safari on the iPad simulator. You shouldn’t need to change much if anything in this step. iOS Simulator is part of XCode and is available from and and the Mac App store, free to registered developers and 4.99 from the App store. Note, Mac OS X 10.6.6 is  required. (I will have to skip this step until I’m ready for a system upgrade)
  3. Finally, load the EPUB into iBooks. If you need to make iterations, change the title of the book to circumvent iBook’s cacheing.
The Future of EPUB session was eye candy.
IDPF is moving the EPUB standard forward trying to balance accessibility and the high standards of magazine creative directors with input from DAISY and IDEAlliance.
One application of adding metadata to parts of magazines would be to repurpose content. For instance, a retrospective book with all articles and images about a celebrity would be quick and relatively easy to create from an archive of digital magazines with metadata at the article level. (especially if the article is structured and uses stylesheets consistently)

Complex layouts with reflowable text and JavaScript interaction.

Take THAT custom apps!

CSS 3 Regions from Adobe looks fabulous. This article from Adobe explains further, and the WebKit-based prototype is available for download.
Any suggestions for explaining to my business partner why I can’t do billable work because I’m geeking out playing with CSS3 Regions?

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?