Expert publishing blog opinions are solely those of the blogger and not necessarily endorsed by DBW.
The screwdriver was invented for turning screws. It has features that help you turn them better, such as a tip that fits the screw head and a handle shaped to suit a hand or wrench.
Most screwdrivers lack the ability to gauge atmospheric humidity. I know of none with saw blades. They’re no good for basting a turkey.
On the other hand, they don’t drip turkey juice on your carpentry, or cut your hand and screw up your grip because the saw blade and humidity gauge had to go somewhere. A good screwdriver does just one thing, and no other tool does that thing better.
Sigil is ebook production software, created and updated by ebook developers. It’s a tool for not coding ebooks manually. It’s free and open-source, so it was slow to support EPUB3, and in the meantime I switched to oXygen. (Sigil can now generate EPUB3 files from its native EPUB2.)
The Job Defines the Tool
oXygen is XML software. In that capacity, I’d imagine it’s very good. It does not resemble ebook software, and to my ears, ebook developers touting its ebook development virtues sound like Quark users insisting they don’t need this new “InDesign 1.0” thing that the young people are talking about: Who needs efficiency when you’ve got a long list of hard-won workarounds and an expensive site license?
One reason Sigil languished was that early ebook developers claimed it changes your code. They briefly had a valid complaint; it did rearrange HTML a little. But it’s open-source, and pretty soon somebody fixed that.
But more to the point: Of course it changes your code.
If you have a program that displays a book in spine order, over on the left, where oXygen displays files in unchangeable, brain-dead alphabetical order, and you grab copyright.xhtml at the top and slide it down the column to the end, so it’ll be at the end of the book—don’t you want the new position to be reflected in the NCX?
Or do you simply enjoy manually editing multiply-nested NCX TOC navmaps, manually renumbering the navpoints, testing, finding the line you shouldn’t have deleted, retesting, finding the line you should have deleted, retesting…
Is there some reason we think that’s better than this?
And don’t we want to have a file list that’s ordered like this?
It’s a book, after all; that is its order. Shouldn’t book software show you a book? XML software doesn’t; it forces you to remember that jaoidkafuiokkasfojlkjlkdsfjlkfsj.3 is the TOC.
And don’t you want to be able to rename jaoidkafuiokkasfojlkjlkdsfjlkfsj.3 to TOC.xhtml, so you don’t have a file list that looks like this?
And when you do rename it, don’t you want to hear, “Okay, updated the NCX, the OPF and all the links in the book, and renumbered everything for you?”
And don’t we want to be able to control-click on Copyright.xhtml, choose “Add semantics” and have <item href=”Text/Copyright.xhtml” id=”copyright.xhtml” media-type=”application/xhtml+xml” /> inserted into the OPF?
And then do the same for these?
Ten seconds. Tops. For all of them.
Don’t you want to be able to choose “Generate Table of Contents” and have it make both an NCX and an HTML TOC for you?
Is there some reason we don’t want these things?
Don’t we want to add metadata this way?
When we’re working with one long HTML file, and we place the cursor at the split point and choose command-return, and now there are two files shown over on the left, and we rename the original CHAPTER1.XHTML and the new one CHAPTER2.XHTML, don’t we want those changes to appear in the OPF and NCX? And don’t we want all the links that targeted those <a names> to update to CHAPTER2.xhtml#aname?
Change Is Good
So, okay, sure, Sigil changes your code. Isn’t that why we like InDesign? Because we don’t have to hand-code vector coordinates? Yes, when you draw a box, that is what InDesign is doing; it’s changing your code! And it’s doing it better than Quark did.
We’re designers, we’re production people. We have jobs to ship. We want to just draw the damn text frame, or add wrap to an existing text frame, and have the software take care of the coordinates and the offset for us. Why would we choose to waste time hand-coding when it’s an ebook job?
Ebook developers are rightly proud of all the HTML and CSS and XML we’ve been forced to learn, and all the clever workarounds we’ve been forced to devise, but sometimes I think we fear we’ll have less value if we don’t (or can’t) type absolutely every letter of every bit of markup.
Sure, When Dolphins Fly
When I was a kid, I had a subscription to Isaac Asimov’s Science Fiction Magazine. In one story (thirty-year-old spoiler alert!), there was an elite group of people who had the technology and reflexes to fly. As I recall, it was a kind of powered wingsuit that emulated the shapes of birds. The death rate was what you’d expect for a risky, bleeding-edge sport, and the elite had pride and honor.
Then someone invented a new kind of flying suit, but this one emulated the dynamics of dolphins instead of birds, and it turned out that was much better. The new ones were less twitchy and more maneuverable, so fewer people crashed into the sides of mountains. It opened up the entire sport. It democratized.
The elite fliers hated it. They said those people weren’t real fliers—the newcomers couldn’t control a real flying machine if their lives depended on it.
I didn’t realize at the time that the story was probably intended as an allegory for command-line interface vs. the newly invented GUI.
Now that Sigil is back on the table for EPUB3, ebook developers face the same questions we’ve always faced—what tool to use, and why.
Use Sigil, use Notepad, use BBEdit, use oXygen. Use whatever gets the job shipped. On deadline, we choose the devil we know.
But it’s probably worth thinking, at this stage of ebook development, about the pain caused by using hacksaws and turkey basters to turn screws. And maybe taking another look at what makes a good screwdriver in the first place.