Can an author create an EPUB using normal tools? Part 2: Scrivener
by Liza Daly
This is part two of a series on using author-friendly word-processing tools with native EPUB export. Part 1 was about Apple Pages.
Part two: Scrivener
I first became aware of Scrivener’s support for EPUB export in November of 2010, when they released a special edition for NaNoWriMo (and the less said about my novel-writing experiment, the better). EPUB export is now available in the latest major release.
Though Scrivener is primarily a Mac application, there are beta versions for Windows and Linux. I have no idea if they support EPUB export — please comment if you know either way!
The sample document
Scrivener’s interface can be intimidating if you have only worked with relatively straightforward word processors. It’s less of a document editor than a book authoring platform (or the way I would look at it, it’s Visual Studio, not emacs).
For this test I used the “Manuscript” style, which provides many of the utilities that an author of a novel-length book might want, rather than starting with an entirely blank document (analogous to using the EPUB sample document in Pages). For one thing, the Manuscript layout already provides obvious support for structured blocks like chapters and parts. In fact Scrivener segments documents even further into “scenes” which can be relocated easily through the document. Programmers love structured content!
As in the previous post, I set up the sample document to include all of the obvious stylistic elements that I wanted to test. I didn’t attempt to exactly re-create the Pages sample as that would be soul-crushing.
Finding the EPUB export feature can be challenging; it’s actually listed as “Compile.”
No complaints here. There are dozens of options for EPUB configuration from the menus.
EPUB-specific output options:
Select which content segments are included in the book, and in what order:
My favorite pane. Look at all that metadata!
Scrivener’s output is variable in quality. Some things are nice. It’s valid, for one thing, and I was able to produce this valid output without any special handling — I didn’t change any of the menu items beyond adding the metadata, which indeed trickles down nicely into the OPF file:
<dc:title>Creating an EPUB sample document</dc:title> <dc:identifier id="PrimaryID">urn:uuid:A54DCD13-A6E0-4ACA-8B31-4E0EBA0624EF</dc:identifier> <dc:language>en</dc:language> <dc:creator opf:role="aut">Liza Daly</dc:creator> <dc:subject>Non-fiction</dc:subject> <dc:description>An EPUB test of Scrivener's output</dc:description> <dc:publisher>Threepress Consulting Inc.</dc:publisher> <dc:rights>http://creativecommons.org/licenses/by-sa/2.0/deed.en</dc:rights> <dc:date>2011-05-29</dc:date>
Whitespace is exported as significant. While this makes the web developer in me cringe (I’d rather see CSS margins used here), it’s acceptable, especially since whitespace is semantically relevant in fiction, as when used for scene breaks:
<p class="p1"><br /></p> <p class="p1"><br /></p> <p class="p2">Hello world!</p> <p class="p2">I have lists and tables!</p>
Unlike Pages, lists are generated as the correct list elements:
<ol class="ol1"> <li class="li3">Numbered lists are numerous.</li> <li class="li3">We often have more than one item.</li> </ol> <ul class="ul1"> <li class="li3">Make love</li> <li class="li3">Not bullets</li> </ul>
Tables are fine, though I’d like for these tools to have a “table header” style that could ultimately map to
th elements. This is a little more readable than the Pages output.
<table cellspacing="0" cellpadding="0" class="t1"> <tbody> <tr> <td valign="top" class="td1"> <p class="p2">Not sure how to make headers</p> </td> <td valign="top" class="td1"> <p class="p2">Without just using colors</p> </td> <td valign="top" class="td1"> <p class="p2">Not semantic</p> </td> </tr>
Headers are curiously not optimal:
<h2 style="margin: 0.0px 0.0px 0.0px 0.0px; font: 138% Optima"><b>First, a header.</b></h2> <h3 style="margin: 0.0px 0.0px 0.0px 0.0px; font: 92% Optima"><b>A subheader.</b></h3>
Why the inline margins and font? Why the
b? And like Pages, no apparent way to generate
<p class="p2">Back to body text. But with <b>strong</b> and <i>emphasis</i>?</p>
Drag-and-drop images and internal and external hyperlinking all worked well:
<p class="p2"><span class="s1"><img src="images/droppedImage.png" width="272" alt="Image" /></span><span class="s2">Hello dog.</span></p> <p class="p4">Inline URL: <a href="http://www.flickr.com/photos/beinecke_library/5166412915/in/set-72157625240109163/">http://www.flickr.com/photos/beinecke_library/5166412915/in/set-72157625240109163/</a></p> <p class="p4">A hyperlink to <a href="body1.xhtml">Chapter One.</a> A hyperlink to <a href="http://placekitten.com">a website</a>.</p>
I pulled the image out of the Pages EPUB output – Pages renamed it to
droppedImage.png, and Scrivener retained the filename, which is a nice touch.
Room for improvement
- Scrivener seems to generate one CSS file for each XHTML file too many CSS files by default. Uncool! This could potentially generate huge unwieldy EPUB books. There’s no reason to have more than one CSS file in an automatically-converted document, and the styles should be normalized across XHTML files.
- Like Pages, there was no obvious way to add
alttext values to images.
- Also like Pages, I’d like to be able to customize the elements and class names in the outputted XHTML using simple menus.
A pleasant surprise to me was that Scrivener has a lot of options for power-users under the hood, including integration with version control tools like Subversion, use of a text-based markup format for better serialization to other formats, or low-level customization of the CSS or even XSLT: Scrivener advanced topics. This means it’s potentially a better choice for an ambitious digital-only publisher; you can start with the basic WYSIWYG layer, and gradually customize the output by diving into the lower level. This will be especially true once Scrivener is fully cross-platform.
Recommended with reservations (but mainly because of the CSS file issue).