Quote:
Originally Posted by jackibar
Would this be causing things to get confused?! Is this coming from Sigil or Calibre? And which program is changing all my headers into p tags with font sizes and bolds instead?!! Looks like a big mess 
So - what on earth could cause this to happen?! And how do I fix it?! |
I also suspect calibre. FWIW we don't do the epub->epub conversion trick in calibre anymore, it makes a lot of changes both to the css and html, and you don't really have fine-grained control over it. For personal use it's fine, but I would advise against it in a production setting.
The wonderful new beta of Sigil has the features needed for splitting and TOC (make sure that your headings are proper h tags, and that things that are not headings are *not*, but it seems you already do that). You can automate most of your workflow with for instance grouped saved searches.
We use calibre for metadata (with the neat Modify Epub plugin kiwidude wrote, that guy is on fire) and storage. You *can* overwrite the epub file in the calibre directory [I know, I know
], this is actually very handy as it'll retain metadata from the existing entry.
Our workflow is currently:
Indesign -> calibre, add metadata.
Sigil: Replace the Indesign-generated CSS with a custom one.
Split files at chapter breaks (we use a dedicated p style as a marker, which we then S/R with the Sigil hr marker), generate toc, de-obfuscate fonts (if embedded fonts are needed), a few saved formatting searches (for "textboxes" and some stylistic flourishes) and validation. Up until recently we did all this with an extremely messy perl script written by myself.
We then give the file a quick page-through in ADE, and run it through ebpucheck since our distributor demands it. I haven't seen an invalid file from this workflow in a long time, though.
With this workflow I currently spend about three minutes to generate a finished epub from an Indesign document when we need to update content. The Sigil beta is amazing, I can't praise the dev team enough. I am also a bit cautious about using a beta in production, but if anything it seems more reliable than 0.5.3, and we inspect our files thoroughly.
Quote:
Originally Posted by jackibar
(BTW, please don't tell me there's no need for an inline TOC!! I realize that - but in certain books, I believe it is helpful, and this is one of them...!)
|
We also go the epub->mobi route, and you need to have an inline TOC to make a proper mobi since the KindlePreview mobi builder amazingly doesn't generate one from toc.ncx. I don't particularly like inline TOCs myself, but of course you need them for that
You can also easily style the Sigil-generated HTML TOC if you want, since the different divs are nicely classed.