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