Stuck inside of Mobi with the Memphis Blues Again (or Waist Deep in the Kindle Muddy)

At this age, I find when I'm learning something new, when I'm still trying to process it and maybe struggling to understand it all, whetever it is begins to make it's way into my dreams. My brain continues working on the problem even after my attention has wandered elsewhere (or surrendered to fatigue).

I still haven’t completely embraced reading eBooks, despite my enthusiasm, but that’s only because I just haven’t been able to make the time to read anything as long as a book. I’ve been avoiding building — or in my case, learning to build — an eBook for more or less the same reason, and because it seems to be more about the “building” than it is the “designing.” But you oughta start somewhere, as they say.

I work with a small (very small) publisher who has been distributing his books to Amazon’s Kindle platform primarily in PDF format, and while he’s been keen to publish more native-format eBooks, his experiences having them produced have fallen somewhere between “poor” and “a complete disaster.” So I offered to transition a few of the print books I’d put together for him into Kindle format, for a more-modest-than-usual-fee, to get the learning curve started.

There’s a reasonably simple mechanism — not foolproof, and not without it’s shortcomings — but a way to create ePub files from InDesign, and from there into the Kindle (or mobi) format. (There’s a mechanism to skip that step and go straight to Kindle format, as well, but I want to have more control over the finished product. Sort of.)

Sort of. I’ve discovered, through trial and error (mostly error), that simplification is key. Much of what I like to do with a print book cannot be duplicated in an eBook — or, at least, cannot be duplicated easily — so it’s probably more trouble than it’s worth to try. As a book designer, this takes some getting used to.

I can’t get too ambitious with some of the projects I work on (many are simple, black-and-white, print on demand books), but when I can, I like to try to have fun with the book format — I’ll occasionally design Chapter Breaks to be a bit more like a magazine than a book, or use the time it takes to physically turn a page (between Half-Title and Title Page, for example) for effect. But none of that really applies to a book read on a device. The learning curve has proven to be an occasionally frustrating exercise in learning limits.

And different devices handle different files in different ways (that’s what I’m led to understand, at any rate), so there isn’t necessarily any guarantee that what looks nifty on one device will look equally nifty on another.

Add to that, I’m constructing these books primarily for the Kindle format. That now encompasses a range of different devices, but Amazon remains stubbornly fixed on a proprietary file format that offers only the most basic options for text display on most of them. (Limited font sizes. Wait, that’s supposed to be bold? No small caps. No right-hand indents, not-really-reliable left-hand indents.) I kinda feel obligated to make sure everything works for those basic devices, and that means even my ePub files have to be simplified to sort of a lowest common denominator. Even that takes more time than you might expect.

(I tried using code that would coerce different devices to display the same book differently, but it hasn’t worked, and with Amazon's standards not entirely set, it’s just not worth the pursuit.)

The challenge now, having learned everything-I-can’t-really-do-and-shouldn’t-bother-trying, is to set up a workflow that will enable me to construct these as an add-on to the process I already employ.