ebook production 2014 notes
With the formal release date for Cotton’s Library less than two weeks away, I have been working to get everything finalized and into the various retail pipelines. I’m going to post some notes, here, about working with lulu.com this latest go-round, if only for my own future reference.
Preparing the print editions mostly seemed unchanged, for good and bad. Turnaround on proof copies was once again fast, despite the scare timelines presumably meant to nudge you toward premium shipping. I did learn that you can effectively “bleed” printing on the interior edge; a line across the gutter will not reveal any kind of interior margin, although the two sides may not line up perfectly. I also discovered that distribution beyond lulu restricts you to a very small number of formats, which are not really marked as such except by a cryptic little 9×9 pixel icon… so 6×9″ trade it is, I guess. Other than this, there weren’t much in the way of surprises. Their cover builder allows one to specify spine copy… but if you upload your own cover art, as I do, then it seems you’re still stuck with the full title and subtitle or, if that doesn’t fit, no title at all. Bottom line, for the most part it seems to work well enough.
Preparing the ebook…um… yeah.
I really expected this to be a mostly straightforward process. I figured it all out two years ago. I did not see what had changed. I was going to use the same version of the same software, to produce similar content in the same version of the ebook spec, and submit it to the same site. None of the “documentation” that lulu provides looked particularly different.
I’m still not entirely sure what went wrong. Thinking back, things seemed more complicated than they should have from the outset. Maybe I got my files confused, but the typography I used in what I think was the final Brilliant Deduction ebook required various modifications to get the same result in ebook software. No idea why. I added one complication intentionally; since Cotton’s Library is divided into three parts, I used the method that I found here to add some hierarchy to the table of contents. It was a bit of a pain, but it did work as intended and I believe the results were worthwhile.
So, after making these adjustments, running my epub file through a couple of validators, and examining it in two reader programs at length, I figured I was all set. Nnnooooooo-no-no-no.
Apparently, at some point in the past couple of years, I guess that lulu and/or some third-party retailers tightened up their standards for epub files. InDesign, at least the CS6 version (not sure about Creative Cloud), apparently has not.
I think that what really tripped me up, as much as any one thing, was the fact that neither of the epub validators I was using indicated any problem. As I discovered subsequently, one that I had not been using would have done so; I caught some hint that it may be a matter of displaying “warnings” as well as outright “errors,” both of which apparently cause lulu to reject your file. This seems to flag all the same objections that lulu.com does.
Of course, being alerted to these issues is not the same thing as having any useful hint about how to fix them. Both the IPDF and lulu.com spit back fairly cryptic comments. So, to the lulu.com forums that pass for “documentation,” and the wider web.
This forum post was the beginning of a solution. The advice has various shortcomings, which I subsequently tried to outline in a reply, but apparently the forum software ate it. (If anyone happens to read this and really needs details, let me know.) In any event, the key piece of guidance was that I could not correct these issues with InDesign; I would have to export my epub file and then crack it open, to directly edit the various text files within. Oh joy.
Fortunately I do enough markup for the web that this doesn’t terrify me; unfortunately the mere fact of having to open up my epub file also opened a can of worms of additional problems.
First of all, I had to find a program that would open it; I was vaguely aware that the epub file is basically a .zip archive, but for some reason the OS X file system wouldn’t open mine even after I changed the extension. Once I did get it open, and figured out how to make changes that solved the initial set of problems, then I ran into multiple problems packing everything back up.
Long story short, the instructions provided here fixed them, though it took some while to arrive there and even more before I gave up looking for some GUI alternative. I know just enough about using the OS X terminal to be properly hesitant about doing so, but this seemed to be the best bet I could find and it got the job done. (Fingers crossed, as my file filters out through the distribution network.)
Anyway, ye cripes. What gives, here? This experience reminds me of the bad old days of dealing with the web, when you could figure out how to achieve a given result, and then within several months you might have to tease out some new method, just to get the same result. Except this was at least generally tied up with the introduction of new features; the ebook spec I’m targeting has not changed. Deeee-lightful…
One possible positive, I guess; in poking around inside my epub file contents, I discovered that InDesign was saving out metadata related to my previous book, which it had preserved from the old file even after I replaced all the visible content. None of this can be entered when you export the epub file, either; whether by instinct, luck, or some faint memory, I found that it’s hidden at File > File Info. Honestly I have no idea whether correcting this makes any difference; I’d never seen the inaccurate metadata in either of the ebook programs I used to test, and couldn’t find it afterward even knowing about it. But, who knows. It might have popped up somewhere, and would have been a bit odd.