Skip to main content

ePubs and the Future

I have been working on various ebook projects and am frustrated by the amount of "hand coding" required to make an ePub book work well with several reader applications. When a book looks just right on one reader, it looks odd on another. Yet, we know the future is digital.

Most computer users are familiar with Adobe's ubiquitous Portable Document Format (PDF). The benefit of using PDF files is that a file includes all graphics, fonts, and layout information. A file appears nearly identical on every computer, tablet, handheld device, et cetera. A magazine in PDF looks like the designer intended — and design is the emphasis of the entire Adobe product line. Adobe's Creative Suite applications are for designers, not writers.

ePubs take a different approach, closer to the original intentions of HTML and similar document "markup" formats. Yes, you can put words in bold or change a few colors, but the intent of ePub is to allow the reader, the computer user, the ability to control specific font choices and even some layout choices. Content, not visuals, are the focus of ePub files, which are coded in a mix of HTML, CSS, XML, and plain text.

Both ePub and PDF have their roles in the digital age. ePubs let a reader easily change the appearance of a text to improve readability (the speed at which text is decoded), while PDF maintains original artistic intent. For example, most magazines are visual publications and the text is somewhat subordinate to visuals. A classic novel? The words matter. One way I consider which is the better format is by asking myself if a text would be appropriate in audio format. Audiobooks definitely don't emphasize visual design.

While I can create "perfect" PDF publications using almost any application on my computer, I can't seem to create an ePub that doesn't need some tuning. It is annoying and even absurd that software companies cannot accurately and completely generate a basic document format. Come on, software developers, HTML has existed since 1992 and SGML traces its history back to GML of the 1960s. You cannot create a good ePub editor based on more than 40 years of markup history?

There is no excuse for ePub generation to be so sloppy from most word processors, layout software, and XML editors. When a program gets the actual pages right, it doesn't include proper metadata. When the metadata are correct, the order of book elements is either incorrect or poorly maintained. I've tried InDesign, Pages, eCub, Sigil, and Oxygen. Each one is almost, but not quite, standards compliant.

We know that the ePub format, along with the .Mobi/PRC (Kindle) format, is where publishing is headed. Right now, ePubs are still in the early days, similar to the first years of HTML editors. That's a shame.

Comments

Popular posts from this blog

MarsEdit and Blogging

MarsEdit (Photo credit: Wikipedia ) Mailing posts to blogs, a practice I adopted in 2005, allows a blogger like me to store copies of draft posts within email. If Blogger , WordPress, or the blogging platform of the moment crashes or for some other reason eats my posts, at least I have the original drafts of most entries. I find having such a nicely organized archive convenient — much easier than remembering to archive posts from Blogger or WordPress to my computer. With this post, I am testing MarsEdit from Red Sweater Software based on recent reviews, including an overview on 9to5Mac . Composing posts an email offers a fast way to prepare draft blogs, but the email does not always work well if you want to include basic formatting, images, and links to online resources. Submitting to Blogger via Apple Mail often produced complex HTML with unnecessary font and paragraph formatting styles. Problems with rich text led me to convert blog entries to plaintext in Apple Mail

Learning to Program

Late last night I installed the update to Apple's OS X programming tool suite, Xcode 4. This summer, in my "free" time I intend to work my way through my old copy of Teach Yourself C and the several Objective-C books I own. While I do play with various languages and tools, from AppleScript to PHP, I've never managed to master Objective-C — which is something I want to do. As I've written several times, knowing simple coding techniques is a practical skill and one that helps learn problem solving strategies. Even my use of AppleScript and Visual Basic for Applications (VBA) on a regular basis helps remind me to tackle problems in distinct steps, with clear objectives from step to step. There are many free programming tools that students should be encouraged to try. On OS X, the first two tools I suggest to non-technical students are Automator and AppleScript. These tools allow you to automate tasks on OS X, similar to the batch files of DOS or the macros of Wor

Learning to Code: Comments Count

I like comments in computer programming source code. I've never been the programmer to claim, "My code doesn't need comments." Maybe it is because I've always worked on so many projects that I need comments  to remind me what I was thinking when I entered the source code into the text editor. Most programmers end up in a similar situation. They look at a function and wonder, "Why did I do it this way?" Tangent : I also like comments in my "human" writing projects. One of the sad consequences of moving to digital media is that we might lose all the little marginalia authors and editors leave on manuscript drafts. That thought, the desire to preserve my notes, is worthy of its own blog post — so watch for a post on writing software and notes. Here are my rules for comments: Source code files should begin with identifying comments and an update log. Functions, subroutines, and blocks of code should have at least one descriptive comment.