eBook Design and Authoring: Back to Hammer and Chisel…

Font embedding in an iBook

Been a while since I posted anything here, because I’ve been pretty busy for the past few months…
First, I had a two-month full-time contract, working on a project I can’t talk about but which was definitely pushing forward the future of reading on screens.
Second, I started work on a iBooks version of a book my wife Tanya’s been working on for years. It is the result of years of research, and also years of painting the wetland birds on the island of Kauai. Tanya’s an amazing artist – I’ve posted examples of her work on this blog a few times.
I’ve always wanted to publish the book, but I felt it was time to try to “walk the talk”, and publish the first version for the iPad.
I picked iBooks on the iPad for a number of reasons:
  • It uses the open ePub format
  • It supports color
  • At 133ppi, it has enough resolution to do a decent job of the text
  • It supports eBooks with embedded fonts
Fonts in eBook readers or devices are still pretty primitive:
  • iBooks: Offers six reading fonts. Only two – Georgia and Palatino – are worth using.
  • Kindle: You can have any font you want as long as it’s PMN Caecilia.
  • Stanza: Any of the iOS fonts (which again leaves you with Georgia and Palatino)
  • Nook: Seven or eight fonts, all of them poorly rendered.
However, the saving grace of iBooks is that it does support embedded fonts. Its lovely color screen makes Tanya’s color illustrations sing, and if the rumor mill is to be believed, iPad3 will have a 266ppi display which will set a new standard for onscreen readability (I’m ignoring the Retinal Display on the iPhone. It’s beautiful, but so small it’s not the screen on which you’d want to read a work like this).

We Need Power Tools, Not A Hammer…

Authoring eBooks should be easy. After all, Pages (Apple’s word processor) and InDesign both offer “Export to ePub”, while Word lets you output HTML. I’ve been bitten by Word’s HTML before – it’s incomprehensible to humans. And it’s revealing that Liz Castro’s book: “ePub: Straight To The Point” seems to spend the first 168 of its 228 pages explaining exactly why output from InDesign and Word sucks, and what you need to do to fix it.
It’s worth using one of these tools for one reason – they do generate a unique identifier for your book, and the skeleton structure of an ePub, with its TOC.ncx and content.opf files, etc, all in the correct places.
But I’m afraid that’s about it. Both seem to generate XHTML that’s verbose and hard to follow, and a CSS style sheet with at least three times as many styles as you need – again, all with incomprehensible names.
I tried my best with each of the tools, outputting ePub, using ePubUnzip to break that apart into the editable files and editing them. But it was just too painful. Eventually I ended up retaining only the skeletal structure, falling back to a text editor (I’m using TextWrangler) and doing the whole process by hand. At least that way I might have some chance of understanding what’s going on.
It took me a while, and a lot of experimentation. But I eventually got embedded fonts working. I’d experimented in Pages and InDesign – easier places for prototyping than XHTML and CSS – and settled on ITC Korinna. It comes in four weights, and you can use them to build a nice set of styles. Korinna isn’t the face I would use for all-text books. But it has a nice character which I liked for this particular, nature-based, content – and the headings look great in red.
I had been experimenting with a three-line chapter heading style: a strap line in the roman, a main heading in bold, and a bottom line in italics, used for the Latin name of each of the birds.
Once I had something I was happy with, I created an XHTML page and a set of CSS styles. I played around with the leading of the main heading, to try to tuck the Latin tightly underneath it.
I’m pleased with the result so far – although it doesn’t work if the reader makes the iBook text too big. If the heading wraps to two lines, the negative leading causes ugly problems.
This raises an interesting philosophical question: Does a designer have to create a design that works for all sizes? Just because iBooks supports ten text sizes, does your book have to? My design works for about half of the size choices. I plan to do some more tweaking to see if I can improve on that. But the very largest and smallest text sizes in iBooks are, in my view, unreadable. The five or six “middle” sizes give an adequate range of “large print” options, without forcing design compromises. Of course, I could always specify a single fixed size for all the text – but that would defeat one of the best features of an eBook. It would be nice if the designer could disable some of the reader’s text size options, retaining the ones that worked for the design.
My contention is that Apple is not a “book design” company. Just because you can give the reader ten or more text sizes, that doesn’t mean you always should.

Full-page illustration in the iBook © Tanya Hill, 2011

I began the book with a single XHTML file containing all the text. I knew that was not practical in the long term, but it let me get started getting the text formatting right. However, debugging a single huge file is painful.
In addition, I wanted to use Tanya’s illustrations full-page, as large as possible. I’d found a Public Domain version of the Arthur Rackham-illustrated edition of “Alice In Wonderland”. The text of this book, and the way it’s wrapped around some of the black-and-white illustrations, leaves a lot to be desired and breaks badly when the reader scales text size.
However, it had a nice trick for creating full-pages of the full-color Rackham illustrations, so I poked around until I found out how it was done. It involves creating a separate XHTML file for each illustration, and using the ePub’s NavMap and TOC to call them in the right order, between chapters.
Some of Tanya’s longer chapters have up to five illustrations. So I guess I’ll be breaking those into sub-chapters…
Today, I got the first 17 illustrations into place – one at the start of each chapter. And I also ran the excellent ePub Validator at http://threepress.org/document/epub-validate/ – many, many times, until I’d killed off the last of the initial 96 errors the first run found.
Then I put the ePub into iTunes and synched my iPad. The illustrations worked great! But in the process of breaking my initial single XHTML file into 17 parts, I somehow broke font embedding again. So it’s back to debugging until I get that fixed.
If you hadn’t already gathered by now, this post looks like being the first in a series – the book is a work in progress.
It shouldn’t be this hard. If Tolstoy came back today, and wanted to write War And Peace as an eBook, he shouldn’t have to become an XHTML and CSS jockey in order to do it. Writers should just be able to write, without needing to learn scripting or programming.
Watch this space, as the saga continues…


4 thoughts on “eBook Design and Authoring: Back to Hammer and Chisel…

  1. Bill Hill

    LATE-NIGHT UPDATE: Got the embedded fonts working again! There's a necessary step that's documented in Apple's iBooks Publisher Guide. Involves creating an XML file with half a dozen lines, and adding it in the right location in your ePub structure.I'll be more specific in the next full post.

  2. Alain Pierrot

    Good to read you, again! Thanks for finding the time!We should organize and gather evidence on the need of ways to express (in CSS?) recommanded or mandatory limits to fonts resizing or substitutions.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s