I’m not an HTML person, but here are a few things I picked up during this 3 hour presentation that I hope will be of use:
Top 5 misconceptions of publishers:
ebook conversions are easy because we have Calibre. No good tools available that will automate 100% the coding
ebook conversions should be cheap: No you get what you pay for in this industry, especially in non-fiction content
can keep the same formatting as in print; getting better but not there yet
Epub can be easily converted to mobipocket/kindle format: doesn’t work
have to get content into XML first: not true
Rules of ebook development:
must learn ebook design, not conversion.
automation tools make us lazy, need to deal with the code
clean semantic mark-up always makes designing easy, InDesign does not output semantic html
test, test, test on every device
ebookarchitects.com/resources.php has a lot of examples of different type of books
Optimizing your epub files
epbub files often have incomplete or wrong metadata
multiple creator tags not available in Adobe Digital Editions and this is a big issue
NCX file has stuff people don’t know about: “page list” can contain actual page numbers of every page of the book, very important to use for textbooks or scholarly books, don’t have to re-invent wheel to do page numbers; Adobe has its own system and often formatting houses use this and it isn’t part of the spec so can cause problems later. Probably want to do both to future-proof
Navlist file: not used enough. Navigation points to things in book – tables for example
InDesign uses “span” tags instead of “bold” for example. Take them out and use regular expressions, will save hours of time
prefer “bold” and “italic” to “strong” and “emphasis”
set up margins properly or text will be flush with the sides of the screen. Need to be set up properly in the CSS sheet use @page reference. Set right and left margins in the body tag.
In cover.html file: use “oeb-column” number to be sure cover image is centered and full size
How InDesign can help and hinder:
Need to upgrade if on CS3, CS4 and 5 pretty similar in terms of epub design. Quark doesn’t do epub design and if backlist is in Quark use a conversion house rather than try to hack through them yourself.
use character and paragraph styles – no manual formatting
anchor all graphics
make cover image a graphic – best to take it out all together and add it yourself later
strip out folios and indexes (or keep if you plan to link)
pros of using InDesign: single document for print and ebook; most designers understand InDesign; no other easy to use system; don’t use Calibre, it is not a professional quality tool, will mess up your html and css
cons of using InDesign: will loose small caps; all caps style may not carry over; loose styling on tables; indentations may not work, doesn’t recognize lists and outputs everything as paragraphs; program does not create semantic html; date field will never come through need to set it manually; metadata does not recognize cover image; unicode text won’t come through properly
XML is probably the future of publishing because it allows you to output to multiple formats – print, ebook, etc. Not necessary to use it now, but now is the right time to start setting up the systems
If you have a valid epub file it is already an xml file
pro: standardization allows for faster creation of ebook files; contents for print and for ebook can come form one source
con: not enough in-house knowledge; hard to set up initially and can be a major drain on resources; constant tweaking when yo run into unique styling in new books; creating from original source files can be hard to do
Kindle format is very simple, HTML 3ish. No borders, no floating images, large tables are useless. Not because of the format, but because that is the goal. Applies to Kindle on iPad as well. Amazon not going to epub, has no desire and no financial incentive to do it.
Don’t use InDesign Kindle plugin for epubs. Conversion process is horrible.
Mobipocket only supports 10 CSS commands and all others will be ignored. Need to be cautious about margins and be sure to test to see if they work. Kindle assigns certain styling by default and be sure to override if don’t want it – right and left justification, for example.
KindleGen made available by Amazon to convert to mobi, but the automated conversion has big problems – especially for non-fiction content.
Forcing Amazon to take an epub, which some publishers do, will not convince Amazon to switch to epub. It only results in poorly formatted ebooks when Amazon converts to mobi using automated processes. This happens on a regular basis. (Can’t do two column text and he don’t recommend doing 2 column text even in epub because of difficulties in displaying it on different readers.)
iBooks uses CSS code that allows you to do some stuff that you can’t do on other platforms
video and audio can be done in iBooks, uses HTML5, up to 2GB in size, media files are not DRMed
Apple uses webkit browser format and is doing some remarkable things with epub files; iBooks is using non-linear content, which is not done by ADE and so get pop up content that is scrollable; in iBooks can embed a single page pdf file into your epub file, makes it easy to zoom in and get a lot of detail (not a “valid” epub file, though)
iBooks and Adobe now support embedded fonts
Gentium is an open licensed font that is excellent and supports some unicode, also look at Liberation open fonts which are available on Wikipedia
css2.1 and some css3
SVG can be listed in the spine
DTBook support removed
Tours and Guide deprecated
NCX now part of epub3, not referenced as a Daisy standard