Forum: Author Hangout

@Dominions Son

Not surprising as both .odt and .docx are supposed to be compressed HTML (or XML, not sure which)

Xml, or rather multiple xml files compressed into a zip file. Html and xml have different structures that aren't comparable by any stretch. And even though odt and docx are both zipped xml files, their internal xml schema is different.
Just for fun you can can right-click an .odt or .docx file and open it with an archive program instead of the word processor. Html on the other hand is just a plain text file.

@markselias11

Having a template to use now will be a phenomenal tool to have!

Templates rule! You can go very far with templates besides just setting the styles. Include a footer, a logo at the top, some default text. Makes it very easy to predefine invoices, quotes, etc.

@Keet

Templates rule! You can go very far with templates besides just setting the styles. Include a footer, a logo at the top, some default text. Makes it very easy to predefine invoices, quotes, etc.

Speaking of templates, I've long built both my production .docx and html files on my existing files, copying the CSS (< style> definitions) and simply replacing the actual text, rather than building each document from scratch. The main task, though, as I continually state at nearly every opportunity, is stripping out ALL of the internal WORD references to reduce the processing overhead.

@Crumbly Writer

The main task, though, as I continually state at nearly every opportunity, is stripping out ALL of the internal WORD references to reduce the processing overhead.

Like I stated in another post, Word is the wrong tool for producing epubs. However, I understand why authors want to use it anyway.

@markselias11

Scrivener, which I love, doesn't do a good job of creating ePubs obviously.

Sigh! I'm using Scrivener, also, and I can't imagine organizing my stuff without it. I had hoped the publishing part, should I ever get there, wouldn't be a big deal. Oh, well. Nice to see that there are ways. At least I'll know to ask for help!

@JoeBobMack

Sigh! I'm using Scrivener, also, and I can't imagine organizing my stuff without it. I had hoped the publishing part, should I ever get there, wouldn't be a big deal.

There are a few issues I've discovered with the publishing part, and to be fair, Scrivener is fairly easy to publish and does it fairly quickly. However, there are issues. The most glaring is that, as has been pointed out here in this thread, it adds in a TON of excess code that makes
The file much larger than it has to be. I also ran into issues while uploading to a different ebook site where the site was checking metadata and telling me I had a foreign language in it, which I didn't. It also had some issues with reading the ISBN number that I had assigned for the ebook. All of this was made more difficult because of Scrivener.

Now all of that being said, I still use Scrivener for writing and can't imagine using anything else. I just have a different approach that I'm going to take for creating an ebook with my next book.

@markselias11

I also ran into issues while uploading to a different ebook site where the site was checking metadata and telling me I had a foreign language in it, which I didn't.

You need the following html commands in your ePub:

< title>Book Title< /title>
< meta name="author" content="Author Name">
< meta content="isbn:13-digit assigned isbn code" name="dtb:uid"/>

If you include those, then Calibre will automatically load them into your ePub files so they'll support the publisher's requirements.

There are a whole slew of additional commands for publishing books (ex: language, genre, story descriptions, etc.) but the recent changes to Calibre have abandoned support for the various publishing standards. :( But there are several listings of them online, if you're interested.

@JoeBobMack

Sigh! I'm using Scrivener, also, and I can't imagine organizing my stuff without it. I had hoped the publishing part, should I ever get there, wouldn't be a big deal. Oh, well. Nice to see that there are ways. At least I'll know to ask for help!

There are several of us who regularly publish to a variety of sources (I typically create a separately formatted document for each separate distributor, as they each have their own restrictions on what formatting they allow and/or support). For all the grief people give over Amazon, their formatting and coding is the most straightforward, in that the books I produce on Amazon look exactly like I design them, while most other outlets I've got to money with the formatting (hence the multiple documents for each book).

@Switch Blayde

The problem I have with fiddling with the HTML is that it then becomes your source. If you make a change to the novel, you have to make it in the HTML (where you don't have the advantages of word processing) or change it in the word processor and then go through the manual HTML creation again. The latter being extra work and prone to error.

It's not you that is the problem. The problem is that a word processor is the wrong tool if you want to create epubs from it. Word processors are designed to create good looking documents for printing. That's the reason why they do such a lousy job when converting to html, they were never intended to do that. I don't see that changing in the near future because it would require some basic design changes.
So, you either live with it or use a different tool. There's a reason why many authors write in a simple text editor. A full word processor adds very little to what you need and get with most text editors but they do keep your text clean for conversion to html. It all depends on what you expect the results to be. The easiest would be using an html editor. Available in WYSIWYG and with spell checking etc. Oh, and free, did I mention FREE?

@Keet

Available in WYSIWYG and with spell checking etc. Oh, and free, did I mention FREE?

You didn't mention: Where? From whom? What's then name of this editor?

@Dominions Son

You didn't mention: Where? From whom? What's then name of this editor?

There are several. For example Atom, available for Windows, Linux, and Mac. Hundreds of available plugins for specific tasks. Like you have to setup your styles in Word you have to configure this to how you like it. Fortunately you can change just about everything if you want to. Plugins for spell checker, even one that uses the Windows spell checker if you're on Windows. Just searching for "WYSIWYG html editor" could have told you that. You yourself have to decide what you need and which editor offers that. Some like it plain and simple, others want a multitude of plugins to get as close to the 'Word experience' as possible. I mentioned Atom because it is very well maintained because a lot of web developers use it and contribute the project. As an author you won't use the specific html programming tools but you can create your html document just as well.
Atom is just one example, there are others, like BlueFish, you might prefer. Remember, an epub is basically a small web site contained in a zip file so it's not so strange to use a programmers tool to create it.

@Switch Blayde

I'm an author, not a programmer. I'll let the programmer convert my novel to an ebook. In my case, the programmer is Calibre. If it creates bloated HTML, so be it as long as it works.

If you are comfortable with what you work with you should stick to it. That's the most important thing. Using a html editor doesn't make you a programmer, it's a tool that is used by many people, including but not exclusively programmers.
You didn't mention any feature that a decent html editor doesn't have. Most even have better facilities for handling multiple documents, i.e. chapters. As said, use what you are comfortable with but then you must also accept it's flaws.

@Keet

Most even have better facilities for handling multiple documents, i.e. chapters.

Switch never claimed that html files didn't support multiple chapters, he complained that SOL didn't, requiring you to post individual chapters, typically one at a time, as the SOL moderators like to review what you're posting to prevent various bugs from screwing up the posts.

@Switch Blayde

I wasn't complaining. And the decision to post individual chapters is mine so that I don't post the entire novel at once but rather spread it out over time.

You can still post it all at one time (via a single post), you just have to date each individual chapter. I did it once and screwed it up so badly, I vowed never to risk doing it again. But luckily, Lazeez saved my ass once again!

@Switch Blayde

I also use the spell and grammar checkers. I find them helpful, not that I agree with them all the time.

They're actually much more useful with the more recent versions of WORD. You may also be interested in utilizing the "Start reading at" command (under Calibre's Convert feature's "Structure detection" options and insert the following command:

//h:h2[re:test(@name, "Sec11", "I")]

so readers can skip over any of your 'front matter' like your Title Page, Acknowledgment, Copyright page or other regulatory requirements.

@Ernest Bywater

that sounds real weird.

Why? That's pretty standard behavior for ebooks on Amazon from the Dead Tree publishers.

@Ernest Bywater

maybe it's an Amazon requirement for the e-pubs as the e-pubs I buy from the dead tree publishers all flow in the usual way with the title page and copyright info set out the same as for a print book.

This is also true for most Kindle books from Amazon, particularly those from traditional publishers.

It's not that the front material isn't there where you would expect it, it's just that when the Kindle reader opens most books for the first time it automatically jumps forward to the start of chapter 1.

@Ernest Bywater

Switch, I think CW meant the fine font detail.

No, I meant "front matter" (ex: Title Page, Copyright page, Acknowledgments, etc.).

I just find it easier to drop the reader right into the start of the story, and then hope they enjoy the story to back up and check out my other books before they move on to the next story (though I still haven't figured out how to do the same for my regular (i.e. non-ePub) eBooks.

@Switch Blayde

Why would I want readers to skip over my front matter? I even begin my front matter with the novel title that I define as H1 so it shows up in the ToC. I want readers to read the front matter. A list of all my novels is in the front matter.

I do too, and they're still located at the top of the TOC (for ePubs, those typically only show up in a drop-down list) but it allows readers to jump immediately into the story. Took me quite a while to figure out how the hell to activate it, though. And, of course, immediately after my story conclusion is the Preview of my next story.

But since you mentioned internal links, each epigraph includes a link to my Citations page (and links back again), and clicking on any chapter title (including the Preview chapter), immediately takes the reader to the Table of Contents.

@Switch Blayde

I removed the previews at the end of my novels. All I have now at the end (without a page break) is a list of my novels (duplicating what's in the front matter) and important links (like to my discussion group). If someone liked the novel, I want them to see the titles of my others right away.

That might be handy, but I dislike duplicating front matter in the back matter as much as I object to duplicating the same scenes throughout the story, or endless repeating the same points, over and over. It's not only kludgy, it's incredibly irritate for readers!

@Keet

The problem is that a word processor is the wrong tool if you want to create epubs from it. Word processors are designed to create good looking documents for printing. That's the reason why they do such a lousy job when converting to html, they were never intended to do that.

Except, since most of us write for serious readers who regularly consume a LOT of books, we want our books to look like printed books, as they appear more professional than a simple collection of pure text chapters.

Also, the reason why many of us concentrate on using word processors is that we base our writing on using paragraph STYLES, to guarantee that each different paragraph follows the same rules and appears consistent, again rather than just stringing one text string after another with a line break < br> between them.

Word Processors, html code and ePubs all emphasize the use of Defines Styles (CSS definitions), whereas few text-based application either allow or recognize them. :(

@Crumbly Writer

Also, the reason why many of us concentrate on using word processors is that we base our writing on using paragraph STYLES, to guarantee that each different paragraph follows the same rules and appears consistent, again rather than just stringing one text string after another with a line break < br> between them.

I don't understand the problem. That is exactly what you can perfectly do with html and css, css was designed for this type of styling! Style your < p > once in css and every paragraph will follow that style. Can't get any easier than that.

Word Processors, html code and ePubs all emphasize the use of Defines Styles (CSS definitions), whereas few text-based application either allow or recognize them. :(

That's where you are wrong. Html en epubs (basically also html) use CSS for styling where word processors each have their own system for style definitions. That is what causes the biggest problem: how well does the word processor translate it's own styles to css styles or how well does an external program convert your Word styles to css. That's mostly where it goes wrong and manual adjustments are required to get something acceptable. So far I haven't seen any program do a clean conversion from MS Word to html so it's clean for creating epubs. No, not Calibre either. It works but if you look at the source it's a huge mess with the same styles repeatedly defined dozens of times because it couldn't determine that it was a previously used style. No surprise if ever looked at the source of a docx file.

@Switch Blayde

HTML/CSS is a programming language to me. And its syntax is more complex for me than any programming language I ever programmed in. So therefore prone to error.

HTML and CSS are descriptive languages, a programming language if you will. The power is in the browser. But if you look at it objectively a word processor is also a programming editor. You have to click your way through all kinds of settings and you probably fought a few times with margins etc. No different from programming and compared to html I would say html is a lot easier.
If you have followed Ernest's posts about html and css you must have noticed how simple it actually is compared to all the possible settings in a modern word processor. For me it's easier to create a fancy html page than a complex word document. With css I see exactly what effect each style has where with a word processor I have to click through styles and I can't easily see where that style is applied. With html I find it very easy to see where a style is applied since I can clearly see the references to the CSS.
I think the problem is more like "html is programming" and "Word is writing", no matter that they are both tools to create a document that displays in a certain way.
But as I said before, I understand that authors want to use a "normal" word processor. It's what you're used to and what you are "expected" to use. It's very hard to change that even if your main goal is putting out epubs.

@Switch Blayde

At that point I decided my source would always be in Word.

And you had regrets how many times? ;)
(since you know html which apparently worked for you.)

@Keet

And you had regrets how many times? ;)
(since you know html which apparently worked for you.)

Except, creating html files is probably only 5% (very top end of the required time), while the rest in focused on writing, perfecting and refining the story (I format as I go). So, once again, focusing on the html is putting the bolts holding the cart's railings in place before the horses!

@Switch Blayde

Only recently did I convert that HTML back to docx and then feed it into Calibre to create the ebook. I had to do that because I had made changes in the HTML file for the novel itself so the latest version of the novel was in the HTML file. At that point I decided my source would always be in Word.

I prefer writing each chapter individually in a Word Processor. You don't need to search for the various commands, as I only use a very select group of options which I use in ALL of my books, so it's simply to use one document to create each subsequent one. And then, it's fairly simply to convert the text and Style definitions from the one into the other.

But Keet is right, most of us 'old timers' use WORD (or whichever Word Processor you prefer) because we used it in business for decades, and now it's second nature. Still, those tools ARE designed for writing, while html programs ARE designed for coding, NOT creative storytelling!

@Switch Blayde

HTML/CSS is a programming language to me. And its syntax is more complex for me than any programming language I ever programmed in. So therefore prone to error.

It's hardly more complex, however it is much more prone to errors, as there is NO error-handling protocols like most other programming languages!

@Keet

I don't understand the problem. That is exactly what you can perfectly do with html and css, css was designed for this type of styling! Style your < p > once in css and every paragraph will follow that style. Can't get any easier than that.

That wasn't the point. I emphasized WHY so many of us prefer Word Processors rather than either text, mark-up or html programs to write with. It allows the books published via other distributors (Amazon, SW, etc.) to look nearly the same as our ePubs (SW, Bookapy, etc.). When we generate the html, it employs the same CSS (though, as usual, I clean that up as well).

I've never been a fan of overly simplified author tools.

@Ernest Bywater

Note to add: The problems I have with images is they are the single biggest time consumer task in the conversion due to having to locate each set of image code in the file and then making sure I have the correct code for each image when I replace it. I have to ensure I get them in the right order when I replace the code and there's nothing in initial conversion code to help guide me. Thus I have to take the time to do it right. It's no major issue, just time consuming in relation to the rest of the conversion.

Ernest, if you could email me your current .sh html conversion file, I'd appreciate (though I'll probably have to convert the .ODT references to .DOCX ones). In exchange, since I typically include multiple graphic images in each of my published books, I can review the necessary html code to properly display a wide variety of images. Once you get the basic formatting, it's pretty straightforward (ex: < p class=/> < span class="centered">(required to view on Apple devices) and the usual < img src="..." alt=" image description for the visually impaired "/>).

@Ernest Bywater

Will email the file. I've got the correct image codes. It's just a little time consuming to have to go through the file to manually replace it in the file.

That's what Search and/or Replace is for. ;)

@Ernest Bywater

That only works when you have the 'exact wording' of what is being replaced and what is replacing it. Also, if each instance is different, you still have to do a manual replacement of the code to have it correct.

Of course, but the most bothersome is the formatting of the necessary codes, while the filename and alt-explanation are relatively simple matters.

@Ernest Bywater

That only works when you have the 'exact wording' of what is being replaced and what is replacing it.

If they are different but with a unique pattern you could use a regex for search&replace. If you have never used a regex a small warning: they look like the chemical name of a medicine does to a patient: making no sense at all. But they are very powerful and usually very fast.

@Switch Blayde

The problem I have with fiddling with the HTML is that it then becomes your source. If you make a change to the novel, you have to make it in the HTML (where you don't have the advantages of word processing) or change it in the word processor and then go through the manual HTML creation again. The latter being extra work and prone to error.

I've always made the changes in my source .docx file, then produce the html as a 'filtered html' and, after cleaning up the code (ex. changing the 'special characters' like em-dashes, ellipses and copyright symbols to the html &####; commands) to produce my ePubs in Calibre, rather than Scrivener.