Who makes the epub? The author? Lazeez? Little bookbinding gnomes? I have some comments (I don't want to get into it here) about both ongoing and finished books, and would like to know who to PM
Who makes the epub? The author? Lazeez? Little bookbinding gnomes? I have some comments (I don't want to get into it here) about both ongoing and finished books, and would like to know who to PM
Who makes the epub?
I just got an answer from Lazeez on that very question. The author creates the epub and uploads it to Bookapy. Should upload 3 formats: epub, mobi, and PDF. Although there's little sales on PDF.
I just got an answer from Lazeez on that very question. The author creates the epub and uploads it to Bookapy. Should upload 3 formats: epub, mobi, and PDF. Although there's little sales on PDF.
I thought the ePub on SOL was automatically generated. They were available long before Bookapy was created.
Or so my memory says.
I thought the ePub on SOL was automatically generated.
I thought he was talking about Bookapy.
@limab, it's created automatically by SOL. You don't have to do anything except follow the Submission Wizard's formatting instructions.
Thank you everyone. I was mostly thinking of the one for SOL.
If you download a story as an epub from SoL there is software in the system that creates the pub for you. To upload an epub you need to create it yourself.
If you download a story as an epub from SoL there is software in the system that creates the pub for you. To upload an epub you need to create it yourself.
Post html/txt on SOL, download the epub and you have it to upload to bookapy (>‿◠)
I prefer to create my own epub to have one that presents as I want it to.
I know, just kidding :)
I know, just kidding :)
Knowing you and your skills, I figured that. However, I was worried that people would take it as an easy way of creating the epub for submission.
Knowing you and your skills, I figured that. However, I was worried that people would take it as an easy way of creating the epub for submission.
Ah, there's that.
To make it clear: I do NOT recommend using the SOL generated epub for sale on bookapy or any other book web shop. The SOL epub generator is a generic routine that has to work for all uploaded SOL stories while an epub for sale requires more individual attention.
The SOL epub generator is a generic routine that has to work for all uploaded SOL stories while an epub for sale requires more individual attention.
This is the dilemma I'm having with an SOL/Bookapy combination. People have suggested posting stories on SOL a chapter at a time with a link at the end of the most recent chapter to the full copy of the ebook on Bookapy.
But the SOL support for docx is nowhere as robust as what I have in my ebooks. I format my ebooks differently than my SOL stories. For example, I indent paragraphs on the former and don't on the latter because SOL can't handle indents and therefore I put a blank line between paragraphs on my SOL stories that I don't have on my ebooks. I also control spacing in my ebooks with "pixels after" so my guess is I'd lose space between lines, such as between the chapter heading and first line of the paragraph.
To edit my Word doc (the novel) to accommodate SOL is no small task and error prone.
To edit my Word doc (the novel) to accommodate SOL is no small task and error prone.
You could try this: https://www.wikihow.com/Format-eBooks, with a little luck the result works for both SOL and epub conversion. Do not use spaces or tabs, that won't work.
Apart from that there's not a lot you can do. Docx and epub are two completely different beasts.
with a little luck the result works for both SOL and epub conversion.
The SOL support for docx is limited. That's the problem. All the extensive formatting I do in Word so that Calibre can generate the epub will be ignored by the SOL Submission Wizard. The same formatting that will look good on Bookapy.
So I was wondering what people who publish on both SOL and Bookapy do. They must maintain two Word versions of their stories.
I knew I would have to break my novel into separate chapter files to upload to SOL, but not actually change the formatting.
So I was wondering what people who publish on both SOL and Bookapy do. They must maintain two Word versions of their stories.
I write in BBEdit in plain text (UTF-8). I use the text markup language when I write. That gives me basically a pristine text copy. When it's time to public, I run shell scripts on my Mac to massage the file into markdown. I then import it into Scrivener and apply a bit of manual formatting (basically text blocks), then generate ePub, mobi, and pdf versions. It's very fast, very efficient, and avoids MS Word. :-)
I then import it into Scrivener and apply a bit of manual formatting (basically text blocks), then generate ePub, mobi, and pdf versions
You format your novels the way stories are formatted on SOL: no paragraph indenting and a blank line between paragraphs.
That's what I'm doing with the novella I'm currently writing. But my full-length novels are formatted the way traditional publishers do it. That's what's causing my problem.
When I post to SOL (I format the book as I write, based on 'styles' I defined long ago), I post ePub generated by M$ Word, which I 'clean' by hand (mostly removing Word's internal commands. I then take the total per-chapter ePub season and produce separate ePubs for each distribution channel, doing the final conversion in Calibre.
Amazon and D2D have the most straightforward formatting (ie. the finished result looks like you're original). SW is a special case. Since they offer users the formatting they want, I submit the original Word file (so, they can do their own conversions), while I submit my own ePub (properly formatted, since the vast majority of SW's conversion errors are due to their cludgy ePub generations).
In the end , I generally produce 8 different versions of each revision (the .pdfs are the easiest, as Apple Mac's produce the to size with a simple command, without all the errors that everyone else introduces in their conversions.
But, as Ernest can testify, creating your own versions make for more efficient books (I.e. fewer coding errors), while also offering greater formatting options.
I generally produce 8 different versions
That's what I don't want. I want one source so if I make a change I change it in one place. From that source I don't mind creating different formats, like epub, mobi, etc., but I want one source.
I realize the problem is that I didn't take into account SOL's format when I wrote/published the novels. I never considered putting them on SOL. If all I have to do is a "replace all" to add a blank line between paragraphs, I may be okay. (The cover page has some special spacing for aesthetic reasons, but I wouldn't put that on SOL anyway. Just the story.)
I want one source so if I make a change I change it in one place. From that source I don't mind creating different formats, like epub, mobi, etc., but I want one source.
That is possible but not with using Word. What you would have to use is a format that is 'clean' and converts easily to all other formats you want. By definition that is never a Microsoft format.
The perfect editor would be LaTeX but is has a learning curve. You can do things in LaTeX no other editor can possibly do. That's why it's the preferred editor in academics: it can format complex formulas like no other editor can do. For an author is has the advantage that your actual text and the formatting are completely separated which means you can have different formatting for different outputs. I don't think many authors use it unless they are in academics and know it through their academic usage.
LaTeX isn't a editor, it's a typesetting language. You'd use vi for editing, and insert the LaTeX commands, then process it into (usually) pdf.
In college I ultimately settled on TeXnicCenter for writing my LaTeX for math/science/programming courses. One of the nice things about it being a plaintext format is that you can use whatever plaintext editor you prefer.
LaTeX is amazing and nice, but also extremely fiddly. I tried using it for some papers in other classes, and it ended up feeling like a sledgehammer to hit in a nail, so I ultimately abandoned it (in favor of Word).
One of the things I like about Markdown is how lightweight it is when writing in plaintext, and the ability to drop into other things. I do my personal blog in Markdown and use MathJAX to get LaTeX-style formatting for when I include math stuff (which I do from time to time), though in that case, it's all being converted to HTML.
Anyway. Personally, I would recommend against writing fiction in LaTeX unless you really needed something in particular about its formatting capabilities. You'll almost always be much better served by Markdown (or any of its siblings like RST and so on)
I used LaTeX extensively when I was in school.
Some simple boilerplate, and insert plain text into it, and generate really nicely laid out documents... even when term papers didn't require any formulae (which was rare for me) it still looked much nicer. And when preparing papers for math or economics classes, it was exceptionally useful.
Of course, much of that was when you were, if alive, not yet out of junior high.
LaTeX isn't a editor, it's a typesetting language. You'd use vi for editing, and insert the LaTeX commands, then process it into (usually) pdf.
Of course, but for an author who is looking for a 'generic' editor the description as "editor" works better. I wouldn't recommend vi for an author, that's plain cruel :)
For those unfamiliar with TeX/LaTeX: https://www.latex-project.org/
To use LateX you can use any plain text editor but it's way better to use one of the many editors available that support WYSIWYM. It's a matter of personal preference which fits you best: https://en.wikipedia.org/wiki/Comparison_of_TeX_editors.
Best of all: almost all are free and available for Linux, MacOS, Windows, Android,iOS, and on-line. Most even work on multiple platforms.
It has a pretty steep learning curve but once you have learned it there's no other editor that comes anywhere near the control you have over your layout. Word can't compare to the results possible with LaTeX.
By-the-way: I don't use it myself. I never needed the control over layout beyond what I can do with LibreOffice so I didn't bother learning it.
I never needed the control over layout beyond what I can do with LibreOffice so I didn't bother learning it.
Right. And most authors don't need the finely-honed control of InDesign typography and page layout document controls, either; nor the .pdf professional document layout controls of xxxOffice.
Web and ePub documents are easily churned out with a plain text editor. The simplest level is markdown. There is another level: asciidoc (or asciidoctor, a fork) that tech authors use for pre-publication construction of software documentation and technical books. And that leads to the third level, docbook, a fine-grained standards control over documentation.
But all have the same base: no word processor coding allowed. Only ASCII UTF-8 text, and very fast keyboard-entry codes easily remembered and typed on the fly. No mousing around.
The mantra is "content first; let the software handle the formatting." It works for those hundred-dollar O'Reilly books; in a simpler fashion it works for us. Just sayin'...
The mantra is "content first; let the software handle the formatting."
Absolutely right. The sole reason why editors exist from plain ascii to Word.
All the extensive formatting I do in Word so that Calibre can generate the epub will be ignored by the SOL Submission Wizard. The same formatting that will look good on Bookapy.
When I was creating SOL's EPUB building software, I looked around and asked the people who read EPUBs and found that most didn't really care about any fancy formatting that I embedded into the EPUBs.
Only one person said that he cared about the formatting and only because he didn't know he could customize the display in his software.
So I didn't bother creating a fancy stylesheet and didn't bother with many other things that I could do, but realized it would be a total waste of my time.
Most reading software, like Apple's Books and others, override most settings built into the EPUB file to display things the way that the reader prefers, from indentation, to right side justification/non-justification, to paragraph spacing, fonts, font size etc...
You can build your files whichever way you want, make them as fancy as you wish, but do realize that you would be doing it for yourself and not the readers. Most will override your fancy formatting.
On Bookapy, I built the previewer to extract the EPUB's stylesheet and display the book using it, but that's just to appease the authors. Readers would probably prefer that I display it using their own preferences like on SOL.
When I was creating SOL's EPUB building software, I looked around and asked the people who read EPUBs and found that most didn't really care about any fancy formatting that I embedded into the EPUBs.
Thank you! Speaking as a reader/customer, I am very happy with the output from SOL's epub generator. Simple, readable, adaptable (I can choose font face and size) and works well whether I'm using a light or dark theme - I usually use white text on a black background. I don't know whether complex layout could be handled - The mouse's tail/tale from Alice in Wonderland springs to mind as a case where layout control benefits the story, but such cases are very rare.
But the SOL support for docx is nowhere as robust as what I have in my ebooks.
If you use paragraph styles in your word processor the indentation is part of the style code and not the paragraph code. Thus, when SoL strips out the excess code that goes with it while the rest stays the same.
However, the best answer is to do what I do. I write the story in my Word Processor (which is Libre Office but MS Word has the same functionality) using paragraph styles. I then save a finished copy as PDF and as HTML. I then clean out the excess HTML code and check what's left complies to the CSS stylesheet I use. I copy my stylesheet into the front of the html file and save the file. That file is then used in Calibre to create the e-pub. A copy of the file is used to create the SoL submission file after a simple global change to remove the stylesheet codes I want in the epub but doesn't fit for SoL. I get a perfect result for both.
Edit to add: I do use a lot of extra style code that most authors don't, which is why it's a bit more complicated for me than others.
Thus, when SoL strips out the excess code that goes with it while the rest stays the same.
Except it will end up as one large paragraph. There's no blank line between paragraphs in my manuscripts. In fact, I don't use blank lines for spacing. I use "pixels after" or "before" for that.
I guess I could do a "replace all" of the paragraph symbol with two of them, thus creating a blank line. But who knows what other unwanted changes would be the result?
Could you create a second paragraph style definition, which inserted blank lines rather than tab indents or pixel spacing?
Could you create a second paragraph style definition, which inserted blank lines rather than tab indents or pixel spacing?
Changing the paragraph style is a major effort. I just went through it with one of my novels, changing the justification from "justified" to "left", changing the size of the indent, etc.
I couldn't simply highlight the entire document and change the paragraph settings. Different paragraphs have different settings. For example, I don't indent the first paragraph in a chapter or scene. And of course the chapter headings are H1 and the "***" (for a scene change) is centered.
Except it will end up as one large paragraph.
If that's happening then there's something extremely wrong with your word processing software. By default, html will have a line between every paragraph, thus each paragraph will show with space between it and the next paragraph. That's assuming you're using a paragraph end command and not a carriage return command.
That's assuming you're using a paragraph end command and not a carriage return command.
At the end of a paragraph (in Word) I press the "return" key. That inserts a paragraph marker and goes to the next line (which is indented per my styling). I would have to hit the "return" key twice to get a blank line. That's why I said I can do a "replace all" to replace the paragraph marker with two paragraph markers.
Now when I'm talking about a paragraph marker, it's not the HTML < p >. I let Calibre create those when it creates the epub.
Now when I'm talking about a paragraph marker, it's not the HTML < p >. I let Calibre create those when it creates the epub.
Ayep, that's how it does it. However, every browser adds space between each delineated paragraph unless that's altered by a css stylesheet command. Thus, by default, there's space betwee each paragraph as shown by < P > in the code of the html and the epub file.
However, every browser adds space between each delineated paragraph unless that's altered by a css stylesheet command
I handle spacing in Word and then Calibre uses that to create the HTML. There are two kinds of spacing in a paragraph:
1. line spacing: Things like single, 1.5, double. I use multiple at 1.15 so it's a little more space than single spacing (.15 more).
2. before and after the paragraph spacing: I set the before at 0 pt and the after at 6 pt so there's more space between paragraphs (6 pts) but not as much as a line (hitting return on the keyboard).
And I have first line indented on all paragraphs but the first in a chapter or scene.
So the SOL Wizard will ignore all that formatting and I'd end up with single spacing with no indenting. And if I don't do anything (like changing the paragraph mark to 2 paragraph marks), it will be one large paragraph.
if I don't do anything (like changing the paragraph mark to 2 paragraph marks), it will be one large paragraph.
No, it doesn't do that.
In Libre Office I use a number of paragraph styles where I set the two spacings you mention, then I select the type of paragraph for what I'm typing either as I type it of just after I type it. The paragraph styles also include the alignment and the amount of indent in them. The bulk of the paragraph styles I use relate to the different types of headings I use.
With the master document I do have an extra paragraph to create space between the paragraphs for the ODT and PDF versions for my own ease of reading while working on the file. When I save the master file as HTML it has extra code for the empty paragraph in it, but the extra paragraph isn't needed as the default display option for HTML is to provide a space between the paragraphs as designated by the < p > < / p > command. Thus HTML will show a space between the paragraphs enclosed within the commands above, unless you have a stylesheet in place telling it not to. This is because the basic setting within the HTML is for a space to be left after the < / p > code.
I've a script I run to remove all of the excess format code not needed in the HTML file, and that includes stripping out the code for the blank paragraphs. This script also removes the indent code while leaving in the paragraph style type title. I then use the stylesheet CSS file to provide the paragraph format instructions like the indent and alignment. The CSS file for SoL is a lot shorter than the one for the other HTML file uses.
The ODT is the master file because I prefer to use the capabilities of the word processor while working on the file.
The PDF is to have a print ready file for those who want a print copy, it is also a common e-book variant some people prefer.
The HTML file is for my website, create the e-pub in Calibre, and the SoL / FS / SFS files. While I could use the same HTML file for all of these because the SoL Wizard strips out the excess code, I do create my own stripped version for SoL to give me greater control over what it looks like.
I then use the stylesheet CSS file to provide the paragraph format instructions like the indent and alignment. The CSS file for SoL is a lot shorter than the one for the other HTML file uses.
I think this is the key. You're working off HTML where you can have a separate CSS for SOL from a CSS for Bookapy. Needed because the formatting is different between the two (doesn't have to be, but in my case the formatting for my ebooks isn't compatible with SOL). So there'd be a CSS for SOL and one for Bookapy.
But I don't do HTML. I coded my own HTML for my first novel. I'll never do that again.
I've never tried saving my Word doc as HTML and uploading that to the SOL Wizard. Maybe the space between paragraphs would be created. I don't know. I do know that when I first wrote a story on wattpad I copied my Word doc to their site and it ended up as one big paragraph. I had to go in and manually add a blank line between paragraphs. That's why I assume SOL would do the same (if I upload a docx to the Wizard, not HTML).
I'm not proposing this, but if the SOL Wizard sees a paragraph indent in the docx, it not only would ignore the indent but put a blank line before it. After all, there are two ways of formatting paragraphs: 1) indent with no space between paragraphs, 2) no indent and a space between paragraphs. The first is typically print while the second is business letters and webpages. An ebook is really a webpage, but since it's a book the traditional publishers made it look like print.
I'm not proposing this, but if the SOL Wizard sees a paragraph indent in the docx, it not only would ignore the indent but put a blank line before it.
Submit your .docx file to SOL, you may be surprised by how simple it may make you life.
Since SOL's engine ignores most formatting, it will pick what it can from your Word document and work with it.
By the way, the first paragraph indent is supported on SOL as a reader-selectable option.
After all, there are two ways of formatting paragraphs: 1) indent with no space between paragraphs, 2) no indent and a space between paragraphs. The first is typically print while the second is business letters and webpages. An ebook is really a webpage, but since it's a book the traditional publishers made it look like print.
First line indent is used in the print industry because it saves on paper.
Space between paragraphs is easier on the eyes, but wastes paper.
Webpages and packaged webpages (EPUBs) don't have any limitations on paper quantity and can use the more visually preferred method of displaying paragraphs — spacing vs indenting.
Webpages and packaged webpages (EPUBs) don't have any limitations on paper quantity and can use the more visually preferred method of displaying paragraphs — spacing vs indenting.
I actually agree with that. That's why I add a little space between paragraphs (6 pt).
But if you browse ebooks on Amazon, all the traditionally published ones and most (if not all) of the self-published ones, use paragraph indenting with no space between paragraphs. When I got into self-publishing I didn't want my ebooks to look amateurish so I formatted them like the traditional publishers.
The problem is mine. Like I said, I'm writing a story now that was intended for SOL so it is formatted the way SOL formats stories (no indenting and a blank line between paragraphs). But it got longer than I thought so I'm considering putting it on Bookapy as well. And the Bookapy formatting will be the same as the SOL one. The only extra step I'll need is, when posting the chapters to SOL, create a separate docx for each chapter with the heading the Wizard expects up front:
Story Title
Author Name
Chapter #
And the Bookapy formatting will be the same as the SOL one.
Don't worry about SOL. None of the formatting you actually use (except italics and bold) will affect SOL. Format it however you want it for Bookapy, and submit that to SOL. We'll take care of things for you.
The only extra step I'll need is, when posting the chapters to SOL, create a separate docx for each chapter with the heading the Wizard expects up front:
Story Title
Author Name
Chapter #
That would be helpful in making sure we don't screw things up.
Format it however you want it for Bookapy, and submit that to SOL. We'll take care of things for you.
Thanks, but the last thing I want is to give you extra work. I'll work it out.
But if you browse ebooks on Amazon, all the traditionally published ones and most (if not all) of the self-published ones, use paragraph indenting with no space between paragraphs. When I got into self-publishing
Because they are using a very generic set of settings for the "reader" behind that function. Once it gets on an individual user's e-reader, that gets ignored in favor of the user's local settings.
You're working off HTML
the CSS code is part of the html file and is right at the start of it. If I didn't designate the css code the e-pub creation software (all programs) will create a css file of its own as it's a required part of the e-pub.
you can have a separate CSS for SOL from a CSS for Bookapy.
Technically that is true. However, what I do is use the same css and cut most of it for SoL.
If you can't buy beer at an epub they should change the name.
It's an epub, you'll have to settle for ebeer or eale.
It's an epub, you'll have to settle for ebeer or eale.
Couldn't I order my epint of ecider?
we've had the i-things, and the e-things; now one's got to wonder what the next fad-ulent vowel-thingy will be? Or will we go back to x-thingies? I vote for 'p'... it's got a nice explosive entry with a reverberating "eeeeee" tail to it. even better with an 'ewww' tacked on.
yeh, we're cooped up waaaay too long.
If you can't buy beer at an epub they should change the name.
To this poor Aussie, that sounds like a business opportunity in these trying times of lock down. You could run two aspects to the business (sadly I'm too poor to fund a set up of it):
1. set up a video chat room where regulars can log in and chat while drinking during their drinking time, and
2. the local clients place orders for beverage which you supply to them via a drone operation once they pay by card or cash in advance - cash collected by a separate drone operation unless you trust them to pay on delivery.
edit to add: Fair warning, anyone can use the ideas, but I'm already using it in a work in progress for meals from a restaurant in a locked down area.
To this poor Aussie, that sounds like a business opportunity in these trying times of lock down.
Sounds to me that even without the corona lock down it can be a good business opportunity. Many people can't afford regular visits to a restaurant or don't feel comfortable in a crowded bar.
My goal is to have a single source for each novel whether it is on Bookapy, Amazon, or elsewhere. I never considered having a novel on both Bookapy and SOL.
I'm writing a story now that's intended for SOL so I'm writing it in Word but I don't indent paragraphs and put a blank line between them. It's one document, but I can break it up into separate files for each chapter when submitting to the Submission Wizard. The only formatting I'm doing is supported by SOL (italics and centering).
However, I may also put this story up on Bookapy. I think it will end up being novella length. But on Bookapy, it will not have paragraph indenting and will have a blank line between paragraphs (just like SOL does). So this is not a problem. It's my full-length novels that I published elsewhere that's the problem.
It's one document, but I can break it up into separate files for each chapter when submitting to the Submission Wizard.
Why don't you use a master document with sub-documents for each chapter? The master document acts like any 'normal' document but you can use the sub documents like a 'normal' document too. No need to split them or create a new document just for posting to SOL.
Word is good at a number of things, but in my opinion, writing a text that will go to multiple other formats is not one of them. Word documents are basically designed to stay inside of Word and that's it.
I have various things I've written that I just did entirely in Markdown (with Byword), and then used the standard Markdown things for making it into a webpage, PDF, etc. I didn't, however, do any ebooks with this.
These days, I'm using Scrivener, and it's so superior a solution to every other "word processor" I've used it's not even funny (at least, for me). I can write my story in a format that makes sense; it stores it as RTF which is essentially a plaintext format so it works nicely with source control for backups and won't be unsalvageably broken by future software updates; it allows me to organize my work and do a lot of great authorial things; and I can export in multiple different formats with either the basic templates or (in practice) slightly modified templates.
Easily the best money I've spent as an author.
However, one of the extremely interesting things is that if you ask a group of authors what tools they use, everyone figures out the right tools and workflow for them. I listened to a podcast at some point with a bunch of well-known authors—several of whom had won Hugo awards and the like—and they were asked this question, and it was all across the board from "Word" to "Google Docs" to "Scrivener" to "Ulysses" and so on.
Printed paper pages and monitor screen displays are two different forms (duh!) of text display, but if it's so obvious, why do so many folks ignore the difference?
MS Word was always intended to produce a paper print page. Always, that is, until MS tacked on what was arguably the world's worst HTML code interpreter. But that's beside the point. Along came John Warnock of Adobe who gave us the postscript printer language (and much else happened, like XML, etc.)
Then MS Word could print a paper page in digital form which was, of course, PDF. Which is NOT popular as an eBook format because it's about as flexible as a paper print page. Flexible, it ain't. It won't adapt itself to your four-inch Magic Phone screen or your Smart-Mickey Mouse wristwatch display.
So why am I boring you all with this?
Because digital pages must be universal for a whole lot of devices from postage stamp-size screens to that wall-mount 144-inch by 96-inch monitor screen in Trump's bedroom! And it must look good & legible on those and all sizes between.
Not easy. Impossible with PDF; and MS Word was NOT designed to produce such output.
The solution, as Geek of Ages and others suggest, is really quite simple.
Write a minimal-format document to produce universal digital output: HTML, XML, or RTF to make => ePub. Find the software tools that suit. And accept the result, knowing that digital documents are dynamic and flexible; not rigid in form or formatting. Accept the difference or face endless struggles.
Most folks with a Kindle don't give a rat's ass about drop caps of 36-point Bodoni Ultrabold, butted against exactly 3 lines, followed by paragraphs with indents of 3 ems, with 12.5-point type and 2.5 point leading, and 6 point leading between paragraphs, seen just as the author intended! Do they? How does that work on a 4-inch screen?
That's easily accomplished on paper, and printed to PDF. PDF is really big with academia. Rigid format fits their formal needs and they view them on big screens or print them out for distribution. But PDF sucks on a Nook!
Try for simple, clean, uncluttered and minimally-formatted master final draft to produce HTML or RTF output to make clean products: ePub or Mobi or Web documents. When its time for revisions there's only one master draft to change; then it's into the grinder to spit out new product.
And maybe stick to Adobe InDesign for beautiful dead tree book pages in your next blockbuster novel. That's the place for that beautiful 48-point Bodoni Ultrabold drop cap!