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?

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.

EPUB3 First look

Hyphens! SVG! Embedded fonts! Multiple Column Layouts! EPUB 3 promises some mighty nice new features.

Bill McCoy of IDPF spoke about the new standard the industry group has been working on. Formerly with Adobe, he wrote a blog about Adobe’s development of EPUB as a reflow-centric portable document format “breaking past PDF’s printed document model.”

EPUB 3 will be based on XHTML and CSS, just like EPUB 2. Mr. McCoy sees ePub as continuing to play a role in digital publishing. EPUB is more flexible, more accessible and interoperable than the PDF format, PDFs are “typeset at the factory, EPUB is typeset at the point of reading.”
EPUB 3 will include:
Video and audio support
Audio that can be synchronized with text
Embedded font support
SVG support
Limited JavaScript, with firewalls
Enhanced language support
Multiple-column layouts
Hyphenation support
Improved metadata capabilities (element level)
Math ml support
Fragment IDs, for smaller bits of a document

EPUB 3 supposed to be backwardly compatible with 2, so we won’t have to go back and update older documents when the reading systems upgrade. He expects that reading devices will be up to EPUB 3 in 2012.

More information on EPUB 3 on the idpf website.

Just start doing what you know how to do and innovate around that.

Greg Bear and Neal Stephenson of Subutai explain the natural progression from hand-to-hand combat to innovative publishing business model.

An interest in antique weaponry and a forgotten tradition of western hand-t0-hand combat led science fiction author Greg Bear to the theme and story line of the Mongoliad project. On the way, he and his partners developed PULP,  the “Personal Ubiquitous Literary Platform.” PULP is is billed as connected publishing, and in their keynote session, Bear and Stephenson contended that content as service is the only viable business model when piracy is ubiquitous: “create an experience that can’t be pirated.”

After finding a funding partner and business mentor, (and fellow antique weapon enthusiast), Bear and Stephenson began creating an online experience with serialized content. Members and fans are encouraged to contribute writing and art, all consistent with the “canon,” the settings and characters originally developed by the writers.

At first the main access to the Mongoliad was on the web, but now, one subscription price allows readers (fans? users? community members? mongols?) to use any device for access.

PULP uses open source components for quicker updates and expansion, and hosts the service in Amazon Cloud the which had a famous failure recently. Even with those efficiencies, Neal Stephenson admitted that “easy to use is hard to do.”

With the PULP platform, it seems Subutai would like us all to make a connected publishing community. The website states: “PULP transforms fiction into franchise by building bridges between publishers, fans, artists, and the stories, characters, and universes that help them define themselves.” Just add a great story, some ads, a wiki, fan fic and fan art. As the Subutai team said, “Each book is a micro business venture.”

Addendum 5/30/11: Paul Biba wrote a great review of this session:

Previous Older Entries