ePub-a-Dub-Dub

Wizened elders speak of a time, long ago, when writers wrote, illustrators illustrated, photographers photographed, publishers published and coders (what few there were) coded.

I, myself, am not wizened enough to have lived in these magical times, but I am elder enough to have borne witness to the ongoing elimination of barriers between professions.

In the late 1980’s, if I wrote an article for a music magazine, I would type it up on my Macintosh Plus (typewriters were already anachronistic), save it as a text file, prepare a few PICT illustrations in MacPaint, then drag everything onto a floppy disk, which I’d slide into a cardboard envelope and “snail mail” to the publisher. Three months later, my article would appear in print: formatted, kerned, justified, paginated and nestled amongst several glossy ads for the latest “must have” synthesizers. Since I served as both writer and illustrator, it wasn’t quite the legendary purity of professional separation — but it was the closest I would ever come.

In the early 1990’s I was creating electronic music hardware and software and, while the coders were off coding my latest design, I would write the owner’s manuals. Unlike the halcyon magazine days, I was now my own publisher — creating templates in FrameMaker and learning all about fonts, digital “typesetting,” layout, indexing, and the mechanics of “signatures,” “bindings,” paper “weights” and other esoteric bookmaking terms.

By the mid-1990’s CD-ROMs became all the rage, and it wasn’t cool to have printed manuals anymore — you had to create interactive, hyperlinked multimedia manuals that shipped on CD (saving companies a minor fortune in printing costs). This, of course, meant it was no longer enough to be a writer, illustrator, layout designer and publisher — I needed to also become a graphic designer, an animator, and a code writer.

Time marched on. The CD-ROM died and was replaced by the internet, which required a whole new set of coding skills, along with a new knowledge of server technology and a basket full of new acronyms like HTML, CSS and SQL to wrap my head around. It also coincided with the time people decided they didn’t like to read anymore — meaning I had to learn how to create videos, plus a whole lot of nonsense about frame rates, codecs, color grading, motion graphics, etc.

While all this was happening in my professional music life, it was being mirrored in my photographic endeavors. Marketing my photography meant self-publishing material on the internet, which eventually morphed into the ULTRAsomething website, which meant indulging in numerous publications about WordPress, Search Engine Optimization, Javascript, and even more CSS. Then the world went all social-media crazy, and the internet fragmented into a million different pieces. This required duplicating, triplicating and quadruplicating my efforts so that my content could find everyone — whether they preferred Facebook, Google+, Twitter, Pinterest or some other hip but ultimately unnecessary extraction.

Then came the proliferation of mobile devices and the realization that I must further fragment and repurpose my content specifically for the different types of devices one might use to access that content… which brings us to the point of this article (and after only eight paragraphs)!

My latest article for the Leica Blog, in which I wrote about my impressions of the Leica M Monochrom, was 10,000 words long — perhaps too unwieldy for the attention-deprived tendencies of the blogosphere. I had originally wanted to publish it as a downloadable PDF, but Leica requested a three-part blog entry instead.

After fulfilling Leica’s blog requirements, I returned to the idea of turning the Monochrom article into a stand-alone PDF. Naturally, this decision meant discovering a plethora of additional things I didn’t know. Specifically, I didn’t know how to create a PDF in which photographs could be clicked and zoom to full-screen at a higher resolution. Nor did I know whether the fixed layout of my fancy and beautifully-realized PDF would actually be legible on the new breed of smaller mobile devices, like the iPad Mini. And what about the crazies who might actually want to read this on a smart phone? Influenced by years of internet-induced schizophrenia, I opted not to bother learning the answers. Instead, I shifted gears and decided to publish the Monochrom article as an ePub.

Of course, I knew nothing about how to create ePubs other than the fact Adobe’s inDesign (which I’d used to create owner’s manuals in the early 2000’s) would allow me to export a document in ePub format. So it’s got to be simple, right? Wrong. The document looked absolutely hideous on my iPad — crazy fonts, weird page breaks, and photographs that split across two pages. After some investigation, I learned that many of these issues could be rectified by creating and embedding custom CSS — but what I couldn’t figure out was how to actually get at that CSS in my inDesign file. So, rather than spend even more time learning about inDesign quirks, I decide to switch to Apple’s Pages application, which could also output an ePub file.

The Pages output looked much better, but still had numerous problems that needed to be fixed with CSS. And just as with inDesign, I couldn’t figure out an elegant way to modify and experiment with the CSS stylesheets. It seemed that Pages required that I first generate an ePub and then try to find and modify its CSS, which would require going back and manually re-coding every change each time I updated the Pages document. At that point, it seemed quite pointless to use Pages, since I’d ultimately have to hand-code the ePub anyway. So I dug deeper, and discovered Sigil — a free cross-platform ePub creator. I was able to use Sigil to create the Monochrom ePub, and I was able to fix some of the display problems with custom CSS… and that’s when I realized that, because ePubs are an open standard, no one actually wants to support them. After all, there’s no money in standards. If you’re Apple, you don’t want people reading ePubs when they could be buying iBooks. Same holds true if you make Kindles, or Sony readers, or any of a number of different dedicated devices. Everyone seems to purposely break their device’s ePub reader, just so their own proprietary (and lucrative) format becomes more enticing by comparison. It’s a crazy world.

So after spending way too much time researching work-arounds and dealing with an endless stream of formatting frustrations, the Monochrom ePub is finished:

EPUB DOWNLOAD: “A FETISHIST’S GUIDE TO THE MONOCHROM”

It’s far from perfect (I seem to have no control over orphans or hyperactive hyphenating), but it’s functional — at least on my first generation iPad. Frankly, I haven’t tested it on any other devices because I don’t own any other devices. Besides, I’d probably collapse into a blob of quivering goo if I were to discover that, like the iPad, some other device failed to support the most simple of CSS tags in their ePub reader, thus breaking the format in a whole other manner.

But hopefully, it was worth it for anyone who prefers to kick back and read lengthy articles on their tablet’s ePub reader. iPad users should also be aware of a handy feature in their iBooks application, which enables them to double-tap any photo in the ePub and make it zoom to display full-screen — an absolute necessity for examining some of the detailed image characteristics discussed throughout the article. I have no idea if this is possible on other devices.

Needless to say, I won’t be providing tech support for this. It either works or it doesn’t. If it doesn’t, there’s always the good old-fashioned, 3-part web version:

• Part 1
• Part 2
• Part 3

You know what the craziest thing is about all this? The more professions I need to learn; the more hats I need to don; the more all-nighters I need to pull; the more hurdles I need to clear just to get content into the hands of end-users — the more my income drops. How’s that for a crazy, upside-down world?