Quote:
Originally Posted by capidamonte
stevelitt,
Strict (X)HTML source documents with custom parsers for target devices is the elegant answer, I think. Write your converters individually (Kindle 1, iPad3, Kobo, Nook, etc.) Some may require document rewriting (old MOBI image sizes, for instance), specialized splitting into various files, and of course, individualized css docs for various targets.
For your root doc structure, I suggest that you simply up your H#s by one.
H1: book element (title, cover, appendix, body, toc, list of maps, etc.)
H2: Parts within the body (eg: Book 1, Part 1, Volume 1), or glossary (eg: A, B, ... Z) or appendices (eg: Art Deco, Post-Modern) et al.
H3: Chapters within the body (mostly) or appendices (more rare) and other such elements that need them. There may be other Chapter analogues in books that I'm not thinking of. An extensive glossary may need something like Sa-Sn, Sm-Sz for instance.
H4, H5, H6: Sub-sections of a Chapter, as necessary. See above re: glossary for further refinement in non-body book elements.
Proper classes in different elements will help with divergent styling needs (<h2 class="body">, <h2 class="appendix">) either for aesthetics or for eReader compatibility.
Relatively simple and, if standardized, easy to convert to various forms of ePub or MOBI.
This was my plan, originally, back when I worked for Hitch -- but I got sidetracked by life.
I will now return to the underside of my rock.
PS: hello, Hitch.
|
Hey, kiddo!
Give me a ring next week. I'll be around, let's chew the fat.
@Stevelitt: I can attest that although he's been out of the game for some time now, Cap knows his epub-fu. He can be quite useful to you if you're developing something. He ran away to join the circus, or something akin to that, but I think he's goofing off a lot these days. He probably needs a good project to keep him out of trouble. ;-)
Hitch