My name is David and my wife, Pat, finished her first epic fiction novel a few days ago. I'm handling the technical side of self-publishing her work as an ebook. My experience in electronic publishing and prepress stretches back over a decade.
We published her book first at Amazon because I've prepared books for the Kindle before and am familiar with mobi file creation. I'm hoping to duplicate those efforts here for the good folks at B&N.
I write directly in html and the text for Pat's book is stored in a single 4 MB html-coded file. Why one text file? Because it makes editing—especially global tasks—much easier. The file is about 1.7 million characters (approx. 385 thousand words) so it's about the size of three good-size books (roughly 1,300 pages if it were printed). And, since there is only one text file, I placed my css definitions in it so that a separate css file would be unnecessary. Finally, to keep things simple, I am using only the stock fonts in the Nook—no external fonts are used or included.
I had no trouble creating the opf and ncx files to generate my own mobi master for the Kindle from my html. The layout looks good and it paginates well. But I've run into a variety of problems trying to duplicate this feat for the Nook.
I understand that each platform has its idiosyncrasies with the way it interprets html and the default text (css) styles it imposes. So, we're not expecting the book to look identical on the Nook as it does on the Kindle. Yet I've run into such serious problems with the Nook that I'm on the verge of abandoning my effort to support it.
Here's where I am: I've successfully created an ePub version of the book that is compatible (as far as I can tell) with the Nook and passes the ePubCheck test with zero errors. But it works erratically in the Nook PC (Windows) software. Here are the problems I'm having:
The closer the reader gets to the end of the book (remember, this book is BIG), the slower it goes. Pages advance normally at the beginning but can take over 20 seconds to advance near the end.
I use the standard css "page-break-before" attribute to force each chapter to begin on a new page. When the reader stops at a chapter beginning and chooses to go back to the previous page (the last page of the preceding chapter), the Nook software will sometimes beep and refuse to advance back to the previous "page". This happens to about 5-10% of the book's 75 chapters and it consistently occurs at the same ones.
We've included a number of internal hyperlinks to aid reader navigation. For example, at the end of each chapter is a link to jump back to the beginning of the chapter and another link to jump back to the Table of Contents. When the reader taps a hyperlink that should take them to a previous ID tag in the book, it works some of the time but jumps to a wrong location other times. For example, the same hyperlink will sometimes jump to the first Table of Contents page (correct) and other times jump to the Cover page (incorrect).
I've carefully examined my html code and am convinced that these problems are the fault of the Nook software. Unfortunately, the only test platform that we seem to have from B&N is the Windows PC Nook software and it seems, frankly, very poorly implemented.
Question: Is it possible to test my ePub file with the Android app version of the Nook software? Apparently, the only way to load a user-created ePub file into the Windows PC Nook software is to drag the file from the Windows Explorer window onto the Nook software window. The Nook software appears to have no "file open" dialog or facility. Is there a way to load a user-created ePub file into the Android Nook app?
This is important because we're at the "go / no go" stage with this project and, if the Nook platform cannot handle large books reliably, then we'll have to forgo it.
Question: The B&N ePub Formatting Guide (which doesn't appear to have been updated since 2010) states that each html file should be less than 300 KB in size. Obviously, my single 4 MB file (4,000 KB) exceeds this. Could this be the reason why my book becomes so sluggish as the reader gets farther into it? Would the same problem occur if the book were divided into 14 x 286 KB html files with a separate css file? Sadly, we're unwilling to break the book into multiple smaller text files because it would make editing a nightmare. But it would help me better understand the nature of the problem.
By the way, the 4 MB size is the uncompressed file size. The file compresses almost 80% when I add it to my ePub wrapper file. The compressed html text file that the Nook software "sees" is actually 862 KB in size. The total size of my compressed ePub file is 1.23 MB.
Also, I assembled an uncompressed 4.5 MB version of my ePub file to see if it would have any effect on the speed of the Nook software and it did not appear to. The Windows Nook PC software was able to open the uncompressed version of the ePub file with no problem and it seemed to exhibit similar performance as the compressed file.
I hope you can help and I look forward to hearing from you. Thanks in advance for your kind response.
Warm regards, David (for Pat)
I don't have a direct answer for you, I've never seen an EPUB use one massive html file as opposed to splitting them up per each chapter.
For the sake of curiosity I created an EPUB just now with a single 2.1 meg html file. I managed to get Nook for PC to crash with it. I've never had Nook for PC crash on any EPUBs. I then tossed it in Adobe Digital Editions and though it didn't crash it, it did struggle with it at some parts. I don't have my actual Nook on hand right now to test it on there though I'm now somewhat curious to see how it handles an EPUB with a single large HTML file.. curious if I can crash it too or cause it to lock up.
I also created a 300k word file with no page breaks and nothing to signify any chapter breaks or new pages. I tossed it in a program that creates EPUBs to see how it would handle it and it forced separate html files all split up approximately the same size.
Not very scientific and not 100% conclusive but I'm leaning towards your problem being the one single large HTML file. Have you tested the EPUB on a Nook reader or in other EPUB readers on the PC? (Adobe Digital Editions is a popular one). Regardless of how Nook for PC handles the EPUB you should test it on a handheld Nook device.
My suggestion would be to split the the HTML to <300k files and test it. No need to perfect the book in that form, just split it up enough so that it will function in Nook for PC as a test. That shouldn't take a lot of time and should answer your question definitively.
As for editing an EPUB with multiple HTML files .. ..Once you have your final EPUB file and you come across errors you need adjusted, just use Sigil to edit the EPUB directly, I can't imagine how having one html file versus multiple (when edited using Sigil) would be beneficial.
Hope some part of this helps.
Just a random suggestion, but if the mobi works well for you, have you tried converting mobi to epub using Calibre or a similar program?
Also, no offense, but it kind of sounds like you're really overcomplicating the whole process. Are you uploading the HTML right to PubIt! or trying to convert it first? You can upload it as is without converting it, which might fix some of the errors you're having, I imagine. If you do that, you can download the converted epub before publishing and test it on whatever device you want, too.
Thank you for the thoughtful reply.
Respectfully, the reason for the single document file seems obvious to us. Perhaps we're missing something. Why would you want to break a book up if you didn't have to? It seems illogical to do so.
Have you ever written and edited a very large fictional story? As the story develops, you continually need to revisit different parts of it to update the spelling of a name or make other changes for story consistency that will be scattered throughout. This is complicated by the fact that Pat has created a number of different languages. They make a minor appearance in Book One but will become more significantly in Book Two. It was a lot easier to work on them in one place than scattered through different files.
Plus there's the fact that, when working with a large story with parallel story threads, the writer can't keep every detail in mind. You may need to find where something was mentioned by a character but you can't remember where. Again, having one file makes a search so much easier.
We're aware that some word processor and document editor programs allow the user to work on a publication composed of multiple documents as a whole. But we've been unimpressed with how well this is implemented.
Regarding Sigil, we learned about this program some time ago and wanted to try it. But we have never been able to get it to install on any of our computer systems. The installer always errors out. I'm a Microsoft Windows Developer, so my skills in this area are pretty deep. I've written a number of installers, myself. Believe me: If there were a way to get Sigil to work on our systems, I would have found it.
But even though we couldn't use Sigil, itself. We still found it helpful. This is because its User Manual is a DRM-free ePub document. As you're probably aware, an ePub file is really just a zip file serving as a wrapper for a group of folders and files containing the various parts of the publication. All you have to do is rename it by changing its ".epub" extension to ".zip" and Windows will allow you to open it and expand its contents. It gave me a great ePub sample.
It amazes me that B&N does not provide samples like this for self-publishers to examine. Amazon has a variety of great samples in its KDP area (both fixed and non-fixed layouts). It makes me wonder just how serious B&N is about self-publishing on the Nook.
I've heard from some self-published writers that they have a higher sales volume on B&N than Amazon. But I'm unsure what genres they represent. I don't want to hamper the success of Pat's book by not publishing for the Nook platform. But my time is limited and I'm not sure that I'll have time to divide the text file.
What I'd like to do first, is test our existing ePub product on an Android version of the Nook software. After all, the Nook is simply a custom Android tablet. Therefore, I expect the Android Nook app will provide a better test bed for our ePub file than a Windows PC. If the problems persist under the Android version, then we'll definitely give strong consideration to breaking our html into sub-300 KB files. But I must confess that it irks me that the Kindle is fine with our single-html-file method and the Nook may not. It makes it more work for self-publisher who want to support a variety of platforms.
Does anyone know if a self-published dPub file can be opened with the Android Nook app? If so, how?
Kind regards, David (for Pat)
Thanks for the suggestion. We were unaware that Calibre would convert a mobi to an ePub. I'll look into that further.
I hope that I'm not overcomplicating things. Thanks for mentioning it.
Let me ask you something—I mean no disrespect. How many ebooks have you read and what do you think about the overall quality of their layout and typography? I'm not asking about the technical limits of the readers and their software. I'm asking about the quality of the implementation of ebooks within those environments.
As a professional who has worked in and with the publishing industry for many years, I am appalled at the poor quality of MOST ebook implementations. Even more amazing is the fact that the quality of work seems to have very little relationship with the size of the publisher. I've seen many ebooks from well-known professional publishing houses whose layout and formatting are just as lousy as that from rank amateurs with no idea how to create an attractive, readable layout.
It doesn't take much research to discover that the converters offered by the ebook distributors (like Amazon and B&N) are imperfect. Even if you have the artistry and skill to create a great layout, the converters are likely to introduce problems.
This is why it is generally understood in the ebook industry that the ONLY way (at present) to create a great layout for your book is to control the process yourself. Whether you are a professional publisher or a self-publisher, you have to do the whole thing, yourself, if you want the best results.
The goal is to provide the distributor with a ready-to-publish ebook file so their converter doesn't touch your work. Ideally, all they should need to do is wrap their DRM layer around your file prior to publication. For Amazon, this means the publisher needs to create the ready-to-publish mobi or Format 8 file. For B&N, this means the publisher needs to create the ready-to-publish ePub file.
Unfortunately, this complicates things. Creating a great ready-to-publish file will almost certainly require some expertise with both html and ePub. Why? Because the idiosyncrasies of the way the ebook platforms interpret the underlying html codes vary. This forces the publisher to tweak the html code of their layout to fit each destination.
Consider the differences between the Kindle and Nook formats:
The Kindle tries to be more like a printed book. Its html interpreter tries to suppress the space that is normally inserted between html paragraphs while trying to force automatic indentation of the first line of every paragraph. If you need to do something different (for example, you have nested sections of quotation where a text is quoted by a text that is quoted) then you must know how to manually compensate with css definitions to circumvent the Kindle defaults.
The Nook tries to be more like a webpage. Its html interpreter tries to suppress css definition attributes which would automatically indent the first line of a paragraph as well as block efforts to suppress the space normally present after an html paragraph. This forces the publisher to take an opposite approach when editing html code for the Nook when indentation and suppression of paragraph space is desired.
The reason I wrote that both platforms also require the publisher to have expertise with the ePub format is because both the Kindle and Nook publication process require opf and ncx files.
Neither platform is adequately documented and it is left to the publisher to experiment and discover, for example, which css margin attributes are recognized and, if they are, how they are interpreted.
It's too bad that this is the state of the ebook industry today. If someone would create a world-class ebook wysiwyg editor program that is capable of creating optimized ready-to-publish files for Amazon and Nook, then much of the complexity would disappear. The user wouldn't have to know html or the details of the ePub's various standards. The only requirement then, would be talent and skill on the part of the publisher to know what constitutes an attractive and readable layout. I'd pay for such a program in a heartbeat.
I fully expect such a program to appear someday—if we're still here. In the meantime, one of the tools I use is EditPad Pro 7.1.1. It is a great html and xml editor.
In summary, the reason for the complexity is to gain control. Specifically, control over the layout with which an ebook will be presented to the reader on their chosen reader platform.
Kind regards, David (for Pat)