View Single Post
Old 10-01-2016, 07:39 PM   #13
slowsmile
Witchman
slowsmile ought to be getting tired of karma fortunes by now.slowsmile ought to be getting tired of karma fortunes by now.slowsmile ought to be getting tired of karma fortunes by now.slowsmile ought to be getting tired of karma fortunes by now.slowsmile ought to be getting tired of karma fortunes by now.slowsmile ought to be getting tired of karma fortunes by now.slowsmile ought to be getting tired of karma fortunes by now.slowsmile ought to be getting tired of karma fortunes by now.slowsmile ought to be getting tired of karma fortunes by now.slowsmile ought to be getting tired of karma fortunes by now.slowsmile ought to be getting tired of karma fortunes by now.
 
Posts: 628
Karma: 788808
Join Date: May 2013
Location: Philippines
Device: Android S5
@Kevin...It's certainly true enough what you say if you are talking about Sigil only -- because the only way that you can insert a TOC and create the relevant and associated XML structure in Sigil is by formatting and marking all TOC headers with h1, h2, h3 etc. But this is not the only way to create a TOC and xml structure in an epub.

You certainly don't have to format headers with html heading styles with certain other apps like Scrivener. Scrivener will generally output all text and headers with a simple indexed CSS text style name like scrivener15. There are no html header definitions (no h1,h2,h3 defs) in the scriv-generated css. The Scrivener-generated CSS doesn't even distinguish between headers, spans or para styling. Scrivener can do this because, on export to epub, it always creates a toc and xml structure using a different method that is entirely based upon the scriv Binder structure and the pre-compiler Contents settings.

But why would anyone want to avoid html heading styles in their epub? Because using pre-defined html heading styles in your epub can and will cause strange header spacing problems on conversion to Kindle within the Look Inside version. This problem is well known on forums like the KDP Forum -- lots of indie authors complaining about the Look Inside header spacing problems there. These header spacing problems -- as well as Look Inside text align and text indent issues -- are all caused by Kindle overrides(via cascading stylesheets) overriding your styling within the CSSwithin the Look Inside version. So that's really why it is advisable to use simple named para styles for all your headers for Kindle conversions because the Kindle overrides will not be able touch or change the spacing attributes on your para styles in the Look Inside html version. Lots of mainstream publishers are now also adopting this same formatting tactic in order to particularly avoid these header spacing problems in Kindle's Look Inside. All you have to do to see this true is to download a Kindle sample from a publisher's gallery and back-engineer their Kindle ebook to an epub using the KindleImport plugin for Sigil and do it that way. Try Polgarus Studio(Hugh Howey uses this publisher) or eBook Pioneers. These well-known publishers do not use html headers at all in their ebooks.

And please don't get me wrong, I really love Sigil like no other app. IMHI it's simply the best epub app out there bar none. I always use it, in the final stage, to fix errors and to put on the final touches to my epub styling.

Last edited by slowsmile; 10-01-2016 at 08:43 PM.
slowsmile is offline   Reply With Quote