Editing EPUBs in the post-Sigil world

• Tweet
• Email
• Sumo

• Tweet
• Email

Editor’s Note: Today’s guest post comes from Anthony Levings, who runs the SketchyTech blog. Today he has a look at the bumpy post-Sigil environment for EPUB creators.

The Sigil editor was not used by everyone in the #eprdctn world and there are those who wouldn’t admit to doing so in public even if behind the scenes they used it to fix things up once in a while. The truth is, however, that with its official demise  it marks yet another #eprdctn tool that has failed to move from EPUB 2 to EPUB 3.

As commonly happens with small open source projects, the weight of development ended up falling on the shoulders of one person, and no doubt the overwhelming task of deciding how to handle the many facets of EPUB 3 forced the development to a standstill.

The past

When EPUB was first on the scene, tools popped up in gold-rush fashion and it seemed that before long reliable EPUB creation would make our technical skills irrelevant. But over the years we’ve seen Writer2Epub plug-in for OpenOffice left without an update for over 2 years we’ve seen projects like Mylyn for Eclipse left in obscurity, and promises of EPUB editor suites go unfulfilled.

Meanwhile, the once celebrated FlightCrew has befallen a similar fate to all the rest, and BookGlutton source code was posted to GitHub in 2011 with the hope that “other developers [would] use and improve it as a basis for creating Epub 3 workflows” but this simply didn’t happen. The code has languished for two years without being forked and instead of being updated sits like a museum piece in a glass cabinet.

Sigil: The Golden Years

Sigil provided convenience to the user when InDesign let them down. For instance they no longer were required to unzip and rezip for every revision of the file, and by using Apple’s Book Proofer every save in Sigil would send the book to a connected iPad for re-checking. It also took away the necessity of changing the OPF and TOC code manually. But with support gone, annoying bugs in OS X Mavericks unfixed, and EPUB3 support not scheduled to arrive it is time to move our workflows forward.

Note: Those who didn’t use Sigil must be warned that the subtitle to this section is a little tongue-in-cheek. It was, in my view, an ambitious project that is to be respected and congratulated. At the same time, it was the cause of frustration to people who were not in favour of its tidying of files and code creation.

The present

So we’ve exported our EPUB 3 from InDesign or Pages, or some other app, and there’s some errors that have arisen in epubcheck. Or perhaps there aren’t errors, but we want to change the way that the app has arranged something for us, something which we weren’t afforded enough control over.

Working on a Mac, the options are thus:

1. we unzip with StuffIt Expander, open in a text editor like TextWrangler and get to work on the markup, then rezip in the Terminal
2. having paid £30+ we own a copy of BBEdit and don’t need to dirty our hands with unzipping, we also have the luxury of live preview, but we still need to understand the ins and outs of the IDPF documentation so that we know how to fix things when they go wrong
3. we look to Calibre, whose developer (Kovid) was passed the baton by the final Sigil developer (Schember) to continue development of a similar tool inside Calibre’s existing app
4. we decide we can’t live without the luxury of Dreamweaver-style editing and handholding, so put down £200+ for a copy of oXygen Author and it assists us with construction of the OPF and the EPUB 3 Navigation Document and feels like the most sophisticated option on the market today

Missing in most of these solutions, with Sigil gone, is the structure and organisation that guided us into approaching EPUBs in a way that reflected their form, and for the most part kept us out of trouble, especially thanks to the assistance of in-built FlightCrew checks.

The parallel present (and associated anxieties)

In the parallel present, there are those who have turned their backs on what has become the tradition of book production that embraces the Word -> InDesign (-> EPUB) mindset and focus instead on getting the XHTML5 prepared first and automate its transition into electronic and print forms.

Online tools like PressBooks exist to assist us in this type of creation, but there remain a number of sticking points. The foremost of which is that we lose the ability to page by page edit and manipulate in the way we do in InDesign and rely instead on CSS (or other programmatic) transformations for our final layout.

Of course, we already depend upon CSS for websites and electronic books, but it troubles our minds when it comes to the print side of things that we must hand over so much control. Print aims for perfection. We worry about widows and orphans, word breaks and rivers, not to mention excessive white space of the kind forced upon us in EPUB and Kindle by figures and headings. And although we might have expected back in 2011 that by now the print book would’ve largely had its day, it is still a major part of publishing and the possibility of a print version cannot be ignored in most workflows.

For CMS and XHTML first options to become the norm for publishers, we need them to achieve two main goals:

1. to match the abilities of current tools (or come very very close to matching those tools)
2. allow us to retain control of our content beyond the lifespan of the system

In essence what publishers demand is freedom and flexibility in the handling of content. If those are missing, it is very difficult for economic incentives to compensate for their loss.

The future

It’s hard to predict what the future holds, but one thing is certain and that is no matter how many versions of a book we produce we want them to remain in sync with one another in terms of corrections and revisions, and we want to reduce the amount of work required as much as possible so that with the print book finished, the ebook is as well, or vice versa. It is also clear from past experience that we cannot rely on open source tools to meet our every need.

One logical answer for those publishers currently using Adobe apps would seem to be that once an EPUB is created in InDesign we should be able to open it in Dreamweaver, and without unzipping have an oXygen like experience of editing and adding interactivity. But then maybe it’s time we all put the money down on oXygen and stop holding back, stop waiting for Adobe to make everything we demand, or something free and fabulous to arrive.

This said, I have a few issues with reliance on GUI editors for editing EPUBs in general:

1. when our dependence on them grows, knowledge of the underlying mark-up is quickly lost. We find this with designers using Dreamweaver, who might know how to use the app and have a superficial grasp of HTML based on it, but who don’t understand the overall structure, conventions and pitfalls in programming websites
2. there is room for typos and changes to occur that mean the electronic version differs from the print version of the book

In the idealised world GUI and WYSIWYG editors are not required, because outputs are perfect, but in the real-world it is convenient to have EPUB editing tools. The question is: Are we willing to pay for the convenience in the real-world? YES/NO/MAYBE

The other question, given that people complained quite a bit about Sigil’s eagerness to change their markup (as noted, even during the golden years), is whether we are willing to trust developers to write the tools we need in the EPUB editing space. After all, a bad tool can create more work than it saves and we’ve had to tolerate a good deal of imperfection, even from the big names, over the course of the last four years.

And then there’s the parallel present, maybe we should embrace the vision that is being set out and let the sophisticated computers on our desks and living in the clouds do more of the work for us rather than imprisoning ourselves in the laborious task of print thinking in a digital world. But it takes time to learn systems and build trust relationships, and who do we trust to stick around while all this happens? We don’t want to jump from one latest and greatest system to the next like over-eager coders. We need reliability and to know that we are not being sold hype, as is so often the case in the world of technology, but systems that really cover all of our needs.

Conclusion

There is no conclusion, some of us sit and wait for Adobe and Apple to meet our every need, some pray for Sigil to come back, some save their pennies for a copy of oXygen, others wander around looking at ways to create their own workflow solutions or embrace the forward-thinking solutions of others.

My prediction is that EPUB will go one of two ways. Either we’ll create EPUBs of the future in the same way that we create PDFs with ease and gone will be the inconsistencies of display and variation of markup. Or, pushes to evolve the standard and what it is capable of doing will lead to features being inconsistently supported, as is the case with HTML5 and modern browsers, and we’ll forever have our heads under the bonnet trying to figure out how to make the damn thing work.

Anthony Levings (@anthonylevings) is Managing Editor at Gylphi Limited, an academic publisher focused on the arts and humanities of the twentieth century and beyond. He writes posts for the sketchyTech blog and has provided technology training and consultancy to publishers and authors in the area of eBooks (ePUB and Kindle). Recently he was the architect for an iOS app called The Waking Prince.

You can follow the @sketchyTech blog on twitter.