I’m almost ready to take the plunge into publishing to Amazon / Kindle, and looking at two options for getting my text into the right format: using compile in Scrivener; or learning to do it the hard but pure way - which is to do a proper HTML edit of the darned text as explained in Guido Henkel’s guide (guidohenkel.com/2010/12/take-pri … ormatting/).
Now, compile is bound to create issues, and I’ve checked through the boards here and seen a few that crop up. But I’m looking at just short stories and novels, with no need for any fancy formatting. I’m hoping compile will be enough. It’s got to be easier and much faster than an html edit.
But in the end, is it better to do this properly, and take the text to a dedicated html editing app? Is compile a shortcut, but ultimately not the professional way to go?
One issue I have is that I don’t have a kindle or a smart phone to check the formatting, only the Kindle for Mac application. So if there were problems with the compile function, I might never know about it.
So I’d like to ask those who’ve already been down this road their views. Is the compile function reliable and good quality? Or, considering all the time, effort and resources dedicated to writing and publishing a novel, is it better to invest a bit more time in an html edit?
Those of you who have done this… what works best? What do you do?
Scrivener’s compile should be more than capable of producing a professional Kindle novel or short story collection. You’re unlikely to benefit from doing a manual HTML edit; you might end up with some slightly cleaner HTML, but no reader is going to see that, and you would only save a few bytes, nothing that would save you download money.
I would say that the only advantage to doing things manually is if you are a professional publishers’ who wants to embed a font - Scrivener can’t do that, but then, you would need a licence for the font which could cost you thousands of dollars for permission to embed it in an ebook, I believe. Most ebooks don’t do this anyway, leaving the user to choose their preferred reading font on the Kindle.
I wouldn’t say that Compile is bound to create issues, either. For instance, if you check out the Novel template that comes with Scrivener and read the instructions included at the top of its binder, you will see that it is already set up to create a properly formatted ebook. The next update adds this for the Novel (with Parts) template, too. The only “issues” - and I use quotation marks because they aren’t really “issues” as such - arise when users are setting things up to compile a book that uses different formatting to the novel template, or a different structure. Because Scrivener is flexible enough to allow for any structure, its Compile settings have to be flexible enough to allow the user to tweak them to suit any structure, and this can mean that there are a number of settings that need adjusting. But this really just comes down to familiarising yourself with the Compile interface. There are a lot of options, so it can seem daunting at first, but once you grasp the “Separators” and “Formatting” panes, everything else is straightforward. As I say, though, compiling an ebook from the Novel template is very simple.
This isn’t an issue at all - fortunately Amazon provide a Kindle Previewer app, which can be downloaded for free here:
This is entirely different to their Kindle for Mac. Kindle Previewer shows you exactly how a .mobi file will work on a Kindle, and it allows you to switch between different devices:
Thanks for the full response and the tip about Kindle Preview. Very useful.
Am I right in thinking that if I really want to double check the html being generated, then I can do an compile to MultiMarkdown as html and simply go through the coding? I tried this as an experiment, and it all looked straight-forward and very clean.
My concern, by the way, came from various blogs and sites around the internet where people were warning about the need for clean html in case devices and formats change in the future. Clean html is supposed to be proof against such changes.
MultiMarkdown won’t produce the same HTML as is used for e-book files. If you want to check the HTML used in Scrivener’s e-book export, export to .epub and change the file extension from .epub to .zip in the Finder. Then extract the .zip file (an .epub file is just a renamed .zip file). In there, you will see all of the HTML files. You can then create your own .epub or .mobi file from the contents if you want.
That said, I would take with a pinch of salt all the dire warnings about needing especially “clean” HTML - valid HTML is the most important thing. It’s true that you could hand-code things and get “cleaner”, tidier HTML than that generated by Scrivener (which relies on Apple HTML-generation methods), as pointed out in Three Press Publishing’s evaluation of Scrivener’s .epub output: blog.threepress.org/2011/06/02/c … scrivener/ (the extra CCS files Scrivener generates being a necessity because it is really reverse engineering Apple’s HTML generation code to achieve its HTML and CSS files).
But HTML and CSS are essentially plain text that take up very little disk space, so a few extra files or extra HTML is unlikely to have any real-world impact. And as for proof against future changes, “clean” HTML has nothing to do with that - only valid HTML (which Scrivener produces) ensures that. Valid HTML will work for as long as systems support its HTML version, whether it is concise or verbose.
What you have to remember is that there are always people who get a little fanatical about this sort of thing - there are plenty of writers out there, for instance, who refuse to use anything but plain text (no rich text or Word documents for them) because they are sure that plain text is guaranteed to work on computers for as long as computers exist, whereas other formats might not. For me, life’s too short.
