Monthly Archives: September 2011

Publishing for iPad: My iBooks Workspace…


My MacBookPro screen set up for iBook work
I’ve found this a great setup for working on iBooks on my 17″ MacBook Pro, and I decided to share it in case it’s of use to anyone else.
One of the problems with building and editing iBooks is that to see them displayed properly you really have to see them on an iPad. That’s a process with many steps:

  • Save your XHTML, CSS and Image files on your computer
  • Run ePubZip on the parent folder of your book to generate ePub
  • Run ePubCheck to find and fix errors
  • Delete the old version of your book from iTunes
  • Delete the old version from your iPad
  • Drag the new version into iTunes
  • Synch your iPad
  • Open the book


If you’re tweaking the CSS or the XHTML markup, having to do this every time is tedious beyond description.

However, the text rendering inside iBooks is done using Webkit – the same engine that Safari uses. While iBooks does not offer all the Webkit features, its rendering is close enough for most purposes. So a Safari window about the width of an iBook screen will let you view changes instantly.

  • Make changes
  • Save file
  • Hit Refresh in Safari


And you see the changes. It makes experimenting with styles, font sizes etc in your CSS stylesheet quick and painless.

The top window on the right-hand side holds the parent folder of the book. The window below that contains the ePub tools. 

Once you have the files the way you want them, generating the ePub is just a matter of dragging the top-level folder of your book onto the ePubZip icon.

Once the ePub has been generated, dragging its new icon onto the ePubCheck icon runs the check. When completed, that pops up a window listing errors, and also puts a text file containing them into the same folder as your ePub.

Elsewhere on my Mac, I have a “Working Archives” folder. As often as I can remember, I make a copy of the latest working ePub and drop it in there, in case I mess up the one on which I’m working. 

It’s not a very complex setup – or probably even very original. It grew organically as I worked, and is the most efficient and pain-free I’ve found so far. The process of building an iBook by hand needs all the help it can get – especially when you’re working with a book of 17 chapters, with more than 30 full-screen color illustrations so far.

Incidentally, Apple’s Publisher Guide suggests that you should use embedded fonts for short sections only – for example, to show a hand-written letter using a script font. However, I’ve proved to my satisfaction that the embedded font technology in iBooks, the ePub format and iBooks itself are more than robust enough to deal with Tanya’s 128-page, illustrated bird book, which so far is 12.8Mb in size…
Advertisements

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…