A question I often get asked is what kind of workflow is best for creating ebooks. The short answer is there is no best, perfect, or standard way to create ebooks. There are as many workflows as there are people. I have regular contact with a comercial company (Booknook.biz) that provides digital file to ebook creation servies (I am not affiliated with or work for this company). The company is broken down into teams and each team has a very different work flow, uses very different tools and they all produce the same quality (high) ebooks. Suffice it to say there is no one way that works best. What I want to outline is a few different ways that I have seen work well for people in common situations.

The big thing to think about is what you want to do with the final look of the ebook. There are applications like Jutoh and Atlantis Word Processor that bill themselves as the equivalent of Word for ebook creation. Atlantis even goes as far as being able to directly open Word documents. These two are not free but compared to the cost of Word itself they are not over priced. These are tools with strong WYSIWYG formatting support.

Sigil fits into the ebook creation picture in cases where a high degree of control is desired. While Sigil does have some WYSIWYG features, it excels at working on code that comprises an ePub internally. Sigil is very much for manual, do it yourself, or fine grain control needs. That said, many users of Sigil use it solely for its WYSIWYG features. Sigil also has the advantage of being free (price) and open source.

In all cases I recommend getting your book into the ePub format. As noted there are many tools for working with ePub. The internals of the format are HTML and CSS which means it’s easy to learn how to do advanced formatting. Also, ePub is an open, fully documented, and standardized format. Further, it’s very easy to convert an ePub into a variety of other ebook formats such as mobi for use with Amazon’s Kindle.

Authors starting with a Word document who don’t want to know about HTML or CSS that makes up the inside of an ePub

Often times an author has already written their book. They have it saved as a Word document or in some other similar format. The challenge in this case is going from their favored text editor to an ebook. In this case I recommend either copy and pasting the text from Word into Jutoh, Sigil or opening the Word document with Atlantis Word Processor. Use the inbuilt features to add the desired formatting and save as an ePub.

This works and can produce a functional ebook. However you are limited by what you can do with the formatting and dealing with quirks in various reading systems.

The case for manually working on an ePub’s internals

Using Sigil to actually work on the internals of the ePub allow for quirks in different reading systems to be accommodated. Two major examples I can think of that illustrate this are thumbnail images on the Nook Touch and the Kobo iPad/iPod apps. Both have very specific requirements in order for them to appear properly. Calibre, for example, takes issues like these into account when it creates an ePub but this doesn’t mean calibre handles every quirk in every reader out there. Manual intervention is sometimes required. Also, this goes back to professional digitization services (like I mentioned earlier) because they know about the little quirks of the most popular reading devices and can ensure an ebook looks the same across all devices.

Three stage ebook creation

What I can say is the best processes in my experience when using Sigil is three stage: write, convert, finish.

1. Write the book in what ever format you’re most confortable using what ever tools you’re most confortable with. The caveat is you really need to be working in a digital medium. At some point you will have to digitize and scanning in pages of paper then correcting errors is going to be a long and arduous process. In most cases simply typing your book into Word is going to save you time after you’ve finished writing if you go the pen and paper route. Most authors are going to use Word which lets them, write, edit and do basic formatting. At this point leave the formatting pretty basic.
2. Use an automated conversion tool like calibre to get your book into a format that is a bit more editable as an ebook. Word is a great editor but Word files are complex (and older versions do not have official format specifications). For Word the best advise is to have Word save as HTML. This will lead to it’s own issues but they can be worked around. HTML produced by Word will have basic formatting intact and the beauty of using an automated conversion tool is a lot will come through when converting to ePub.
3. Take that mostly formatted ePub put it into Sigil and make the necessary changes to make it look perfect. Since Sigil allows for direct access to the XHTML and CSS you can use a number of different techniques to ensure it looks exactly how you want. Also, if you are working on a number of book and want to ensure consistant formatting you can do things like easily use a default stylesheet. The best way I can sum up how the majority of people use and how I view Sigil is, Sigil is for people who know XHTML, CSS, and regular expressions and want to use their knowledge.

Three stage variation: Markdown and Textile with plain text

I personally use a slight variation of the above. I prefer to use plain text with either Markdown or Textile for basic formatting. Then conversion with calibre and final adjustments with Sigil. I use both depending on what I want to accomplish as I find Markdown more intuitive but Textile allows for things like margins and text alignment. Even without using Markdown or Textile converting using calibre with heuristic processing will get most novels about 75-90% formatted.

Three stage variation: Starting with HTML and CSS

The biggest difference with this variation is it skips right to step three. It is possible to still use calibre to take the HTML and produce an ePub but in this case I would advise against doing so. calibre is an automated tool and will make changes to the HTML and CSS. Visually it should look the same but the HTML and CSS will be different. This can be good if you have HTML and CSS that is so horrible you need it cleaned as calibre does some normalization but if you’re using your own hand crafted HTML and CSS you probably don’t want it modified.

Once you have all of your files ready, open Sigil and have a blank document open. Right click in the book browser on the text folder. Choose the Add Existing Files. Select your HTML files and import them. You should now see the Text section includes all of those files. Do the same with your CSS.

You many need to edit the HTML files to ensure that the CSS is referenced from the correct location. All stylesheets are located in the Styles directory which is one step above the Text directory. For example:

<head>
<link href="../Styles/stylesheet.css" rel="stylesheet" type="text/css">
</head>

If you have any images add them in the same way you added the HTML and CSS files. Also, make sure they’re referenced properly just like you did with the CSS.

Check the look in the book view to make sure everything looks correct. Also don’t forget to delete the Section0001.xhtml that is left over from it being a new file.

As you added each file the filename is perserved and it is added to the TOC based on the file itself. You have two options for working with the TOC. If you want to leave it file based you’re pretty much done. If you don’t like the text that displays in the TOC you can edit the toc.ncx and change the text.

You’re other option is to generate the TOC from headings. In the TOC browser (should be on the right hand side) click generate TOC from headings. Automatic TOC generation is based on h1 – h3 tags. h2 are nested under h1 and h3 are nested under h2. The only other way to deal with the TOC is to manually edit the toc.ncx by hand.

Conclusion

What I would recommend to authors is take the easiest path. If you’re  happy with the results of using Jutoh or Atlantis then your done. If you want to get a bit more involved use a variation of the three stage work flow I outlined. If all this seems like too much to deal with, pay someone to do it for you.

Toward the end of the forum thread there is a very nice set of udev rules that work perfect for me and are very clean. I put the following into /etc/udev/rules.d/85-yubikey.rules

ACTION=="add", ENV{ID_VENDOR}=="Yubico", RUN+="/usr/local/bin/gnome-screensaver-unlock"
ACTION=="remove", ENV{ID_VENDOR}=="Yubico", RUN+="/usr/local/bin/gnome-screensaver-lock"

I really dislike the scripts that are in the thread for locking and unlocking the computer. Gnome Screen Saver is a DBus enabled application so controlling it is very easy. Below are the unlock and lock scripts I’ve written. They use qdbus to send the dbus commands. This could be replaced with dbus-send but I use Qt and qdbus’s syntax is easier to work with.

gnome-screensaver-unlock

#!/bin/sh
 
user=`ps aux | grep gnome-screensaver | head -n 1 | awk '{print $1}'`
 
if [ -n $user ]; then
        GNOME_SCREENSAVER_PROC=`ps xa | grep gnome-screensaver | head -n 1 | awk '{print $1}'`
        export `grep -z DBUS_SESSION_BUS_ADDRESS /proc/$GNOME_SCREENSAVER_PROC/environ`
 
        su $user -c "qdbus org.gnome.ScreenSaver / SetActive false"
fi

gnome-screensaver-lock

#!/bin/sh
 
user=`ps aux | grep gnome-screensaver | head -n 1 | awk '{print $1}'`
 
if [ -n $user ]; then
	GNOME_SCREENSAVER_PROC=`ps xa | grep gnome-screensaver | head -n 1 | awk '{print $1}'`
	export `grep -z DBUS_SESSION_BUS_ADDRESS /proc/$GNOME_SCREENSAVER_PROC/environ`
 
	su $user -c "qdbus org.gnome.ScreenSaver / SetActive true"
fi

One thing that isn’t mentioned in the forum thread that is very important, this unlocking method is highly insecure. The locking portion is fine but unlocking shouldn’t actually be done in this way. The above udev rules only checks that a Yubikey is inserted. It does not which which Yubikey is inserted. Any Yubikey can bypass your password and unlock the computer. The unlocking script does not preform any additional checks against the yubikey. Due to this, I don’t have the unlock code enabled on my computer.

However, it is possible to make unlocking secure. You can use one of the two yubikey pam modules, Yubico’s yubico-pam and Securix Live’s yubipam. Yubico-pam requires internet access because it validates against Yubico’s servers. Yubipam does not need internet access but you will have to reprogram your Yubikey with a new AES key. The new key must be stored in the computer. Each has it’s advantages and disadvantages but using the pam module with Gnome Screen Saver (I haven’t actually tried so it might not work) will provide you with a secure unlock.

Thinking about secure unlocks there is a clever solution that allows for the Yubikey to be used with SSH without the need for the pam module. If I can find a way (I haven’t looked yet) to have an input that can capture the Yubikey’s output then it would be possible to handle the unlock in a secure manner without the need for the pam module…

I’ve added three new pdf manipulation tools. Merge to combine multiple pdfs into one. Split to split a pdf into multiple files by page. And info to show information about the pdf. Info is especially handy when you want to work with split and need to know how many pages are in the document.

To stop issue with naming conflicts (pdfinfo is used by poppler-utils) and to keep the amount of pdf* names under control I’ve created a git/bzr like wrapper for all of Calibre’s pdf manipulation tools. pdfmanipulate is the base command. A subcommand (see them all with –help) is added after.

$ pdfmanipulate --help
Usage:
pdfmanipulate command ...
 
command can be one of the following:
[info, merge, split, trim]
 
Use pdfmanipulate command --help to get more information about a specific command
 
Manipulate a PDF.
...

$ pdfmanipulate merge --help
Usage: pdfmanipulate merge [options] file1.pdf file2.pdf ...
 
Merges individual PDFs. Metadata will be used from the first PDF specified.
...