Embedded Files
In this section, the structure of our future-EPUB content is examined, maybe revised, and finalized.
This is an absolutely critical step in the process. projectx's structure dictates a lot of what happens at the ones-and-zeroes level inside the EPUB, including the file structure itself, page breaks, table of contents, and navigation.
Section Index
Section Index
ACTION list: Create A Working Copy
Before revising anything in the full_projectx file, create a fresh working copy. Name the file: prep_projectx
Work only in the prep_projectx file until we reach the housekeeping stage.
Partitions
Partitions
By partitions, I mean story portions like chapters a/o parts. Shorter works might have no partitions at all.
Though with EPUB and MOBI it is possible to have navigation and story partitions entirely independent of one another, that’s a lot of work and impractical to pursue in this tutorial.
Configuring a functional and sensible partition scheme is the number one most important factor in pre-production. Each partition header becomes a table-of-contents entry. Partition headers also determine where page-breaks will fall in the EPUB. Each partition will (almost always) become its own, separate file inside the EPUB.
Beware that the more elaborate the partition scheme, the more work is involved, and the more opportunities for problems to develop. Basically, as far as partition schemes go, there is one rule: the simpler, the better.
What You Need To Know
What You Need To Know
Above all else, remember always that EPUB and MOBI are a DIGITAL FORMATS. Digital formats face unique challenges like small viewing screens, frequent page turns and limited battery life.
In order to make the best production decisions possible, tutorial users need to know some things about how EPUB and MOBI files function for the end user. End users are your readers——You know, those trusting, innocent creatures who paid for your book.
Let's start with some quick basics about these digital formats:
HTML (what the interwebz are made of) is the base language of both the EPUB and MOBI filetypes. The rules are the same at the ones-and-zeroes level, which is why converting to MOBI from EPUB works so darn well.
An EPUB (and also a MOBI) is a compressed folder, like .zip et al. This means an EPUB is really a folder with many other files and folders nested inside.
##pending If you'd like to see for yourself, visit this supplemental page where we crack open an EPUB and dissect its insides. ##in progress.
Pagebreaks seem like a basic component of print convention, yes? Readers are conditioned to expect a pagebreak between chapters and parts, yes?
Naturally, it's not so simple to cause an EPUB file to display a pagebreak.
A new pagebreak = a new file inside the EPUB folder itself. (Okay, the new file is actually inside a subfolder, but still.)
Everywhere you need to put a pagebreak in projectx, a new file must be created inside the EPUB. That new file is the only way to cause the EPUB/MOBI reader to display a pagebreak.
We create those new files/pagebreaks later on in Sigil. For now, simply keep in mind that projectx's parts and chapters require a significant change to your EPUB's ones and zeroes.
Also, since (more than likely) a vast majority of your readers will view your content on a Kindle or a Kindle app, you need to know some things about HTML tags and the effect they have on MOBI-file navigation. This means that how you partition your novel makes a difference in what happens when readers push certain buttons on their Kindle.
Later on in this process, partition (part and chapter) headers will have HTML header tags attached. HTML headers come in different levels, or ranks, if you will. Some rank higher than others, and these ranks make different things happen on a Kindle/App.
An <h1></h1> HTML header around a chapter or part header will create an actual tick mark in the Kindle/App's navigation bar, as well as a 'stopper' of sorts that will allow the reader to skip between partitions by using their five-way navigation button.
An <h2></h2> (or lower hierarchical) HTML header placed around a chapter or part header will create only the stopper. The tick mark will not appear on their navigation bar.
ETA: Further research on this topic has shown that nested hierarchy might not even be possible due to variances between Kindle/App generations. What happens on one Kindle/App might or might not happen the same way (or at all) on a different Kindle/App. No one knows exactly why tick marks appear on some ncx navPoints, and not on others; only that it differs between devices. There doesn't appear to be any uniformity between versions. WTF, Kindle developers? Honestly. I love you despite your sloppiness. Please to fix kthx.
The trick to making solid, reader-friendly decisions is accepting the fact that something as basic as the concept of "Chapter 1" has a direct impact on the EPUB/MOBI user's experience. If you make bad decisions, projectx will not conform to standard print convention. This will fall short of your readers' expectations, and that falls under the 'epic fail' column. Or possibly the 'stop being a pretentious dick' column. (Yes, there are stories behind that statement. Buy me enough Captain Morgan, and you might hear a few.)
I guess what I'm really saying is that a partition scheme is not just important to story structure. It also impacts file function, and authors and producers have to understand that the decisions they make about this issue must be made for the readers' benefit, not their own.
Advanced users read this for a lot more awesome ncx information.
What You Need To Do
What You Need To Do
Label Wisely
Label Wisely
For chapter and part headers, the less text used, the better.
In the EPUB format, it is better to stick to standard chapter headers like Chapter 1, Chapter 2 or Part 1 or Part 2 or Part I or Part II.
Here is a very detailed explanation on why I don't recommend text chapter headers for EPUB and MOBI formats. This supplement is a must-read for all first-time tutorial users.
Numerical Issues
Numerical Issues
Think Of The Ugly Battery-Killing Children!
Please do not spell out chapter or part numbers. Use only the numeral. For those readers who read on smaller screens, ‘Chapter Twenty-Seven’ may wrap, resulting in ugliness. ‘Chapter One-Hundred-Eighty-Nine’ looks even worse. Chapter 27 or Chapter 189 work much better. (I’m talking to you, whoever produced my beloved Patrick Rothfuss’s books.)
All that chunky, ugly text takes up a lot of screen space, which means I have to turn a lot of pages to view the content, which kills my battery and makes me ornery. If my battery dies, I have to put your book down. I might not pick it back up again. Hint: This should be considered a bad thing.
Errors
Folks would be shocked to learn how often errors in chapter/part/partition numbering make it into published books from major-league publishers. Please be better than this. Check and double check partition numbering for omissions, duplications or any other errors.
(A diligently created and maintained key_projectx can save your bacon in this regard.)
Special Cases
Special Cases
There are all sorts of scenarios where a producer cannot rely on standard “Chapter X” headers to populate an EPUB's table of contents.
Anthologies
For multi-author anthologies, a reader made the best suggestion ever: use the author name as the TOC (table of contents) entry.
For single-author anthologies containing multiple stories, there might be no way around using the individual story names as TOC entries. With any hope, those titles are short and snappy. Otherwise, there might be no easy solution to the Ugly Children problem. The TOC might just have to look like crap.
Long-form Fiction
Long-form fiction can be too short for chapters but too long to go without any navigation markers along the way. Sigil allows us to put "anchors" in the text. Readers can navigate to those anchors. No pagebreak required with anchors.
This faux-bookmark business is covered at some length in the Create the EPUB section.
Using Both Parts and Chapters
Manuscripts using both parts and chapters might require hierarchical tagging. Tagging has its own section later on.
Be advised that the CSS file provided with this tutorial defines only two heading levels.
ACTION: Evaluate And Revise projectx's Partitions
Examine projectx's current partition scheme. Is it straightforward and reader friendly? Will the structure you've dictated yield a sleek small-screen and battery-friendly user experience? (Remember, this is digital publishing, not print.) Will your TOC be a garbled, confusing mess? Revise and finalize.
Examine the text used as headers. Is it accurate and concise? If not, revise, revise, revise.
ACTION: Add Partition Headers To The Key
Once the partition scheme is finalized, make sure each partition has header text of some sort. Whether that’s Chapter 1, Part I, or whatever, make sure there’s something up there to mark each partition.
If the partition scheme involves any numerical features, double check the order. Ensure there are no duplications, omissions or mistakes.
List each partition header in key_projectx.
Include all front and back matter partitions. (See the image below)
Right now, I bet you're thinking, “Hey, there’s twelve chapters in this book. I’ll just list twelve chapters in the key and call it good.”
Yeah, no. Go through the file and actually look at each header. I realize it takes time, but this is the step where numbering errors get caught. So please take the time to really look at what you’re doing before populating the key with the partition header scheme.
Previous << Gather Content | Next >> Editorial Concerns
Page updated
Google Sites
Report abuse