Thread: Joshua Tallent on the Single Epub Challenge
View Single Post
Old 06-04-2015, 12:02 AM   #23
dgatwood
Curmudgeon
dgatwood ought to be getting tired of karma fortunes by now.dgatwood ought to be getting tired of karma fortunes by now.dgatwood ought to be getting tired of karma fortunes by now.dgatwood ought to be getting tired of karma fortunes by now.dgatwood ought to be getting tired of karma fortunes by now.dgatwood ought to be getting tired of karma fortunes by now.dgatwood ought to be getting tired of karma fortunes by now.dgatwood ought to be getting tired of karma fortunes by now.dgatwood ought to be getting tired of karma fortunes by now.dgatwood ought to be getting tired of karma fortunes by now.dgatwood ought to be getting tired of karma fortunes by now.
 
dgatwood's Avatar
 
Posts: 629
Karma: 1623086
Join Date: Jan 2012
Device: iPad, iPhone, Nook Simple Touch
Quote:
Originally Posted by Hitch View Post
Dag:

Aren't you just using KF7 fallback, rather than trying to use old HTML to work around that?
Where possible, yes, but I don't blow all that KF7 fallback crap into the master EPUB because I was having problems with some readers rendering the fallback content.

Here's a list of differences between my Kindle EPUB and my production EPUB:
  1. ASIN instead of ISBN.
  2. Larger art files because I don't have to deal with Apple's restrictions, and kindlegen scales them down anyway, so it is better to start from a higher quality, larger image.
  3. Extra paragraph after the chapter title for KF7 purposes.
  4. Very different CSS markup because kindlegen misinterprets CSS selectors too badly to be usable as soon as you do anything more than 1:1 paragraph to style correspondence in either direction. I end up using more tags on Kindle to allow more opportunities for blowing in styles, and use tables for certain formatting that would normally be handled by left margins on elements, because otherwise KF7 won't indent. And it doesn't make sense to include two copies of a chapter heading for KF7 purposes, so I just made it work for KF8 with the KF7 markup and different styles, but the markup is too ugly for me to ship it for EPUB readers.
  5. The use of the <nobr> tag in various places because Kindle doesn't respect the white-space: nowrap CSS property. (That might only affect KF7, but because the tag is not actually in the HTML specification at all, I can't ship that workaround in a proper EPUB or it will fail validation.)
  6. Use of &nbsp; entities to force left indentation in certain spots (shown only on KF7).
  7. Use of <center> tags to force centering on KF7. That tag is deprecated, and is considered unsupported in HTML 5, and hence EPUB 3, so I'd get verifier errors if I shipped an EPUB 3 book with those workarounds.
  8. Nested <blockquote> tags to force sufficient indentation of certain blocks on KF7. To avoid repeating those blocks of content with fewer tags for KF8, I use different CSS on KF8 than EPUB so that the nested blockquotes won't cause KF8 readers to indent too much.
  9. An added &nbsp; at the end of every paragraph to ensure that KF7 readers don't fail to display empty paragraphs.
  10. Fewer workarounds for old iBooks bugs.
  11. Extra <span class="kf8only">...</span> around zero-width joiner entities to avoid KF7 devices rendering them as a "missing glyph" rectangle.
  12. Title pages, part pages, and other SVG-based special pages contain an extra HTML version of the content, with the SVG content wrapped to be visible only on KF8-compatible devices and the non-SVG content wrapped to be visible only on KF7-compatible devices. (I don't think KF8 readers support the <epub:switch> tag, so the non-SVG fallback markup will continue to be different even if I start shipping non-SVG fallback markup in my EPUB content.)
  13. Soft hyphen entities (& #173;) replaced with <wbr/>, because KF7 readers support the tag, but don't support the equivalent entity. I don't do this in the general EPUB because it wasn't an officially supported tag until HTML 5/EPUB 3, so it risks breaking older readers. Amusingly, older ADE versions would probably do the right thing entirely by accident because of their infamous "wrap at tag boundaries" bug, but....
  14. Font sizes in SVG are translated from CSS properties into attributes on the elements to work around a bug in KDP ingest.
  15. Fewer -ibooks-* styles and other platform-specific bits in the Kindle CSS.

It is not a small list. For KF8 readers, the EPUB content would probably be survivable, if a little quirky in spots for lack of testing. For KF7 readers, it would basically be a fireball. And as previously noted, several of the KF7 workarounds require tags that would be illegal to ship in an EPUB book, so I can't make the Kindle version be the base version, either.

Bear in mind, of course, that my formatting is pretty complex, coming in just shy of 30k in the main CSS file alone. Not everyone will need or want to go quite that nuts.

Fortunately, that is all automated. I start out with DocBook XML (with a few custom extensions). So there is a single source for both books (and for my print editions); it is just one level of abstraction farther away from the final content.
Last edited by dgatwood; 06-04-2015 at 12:05 AM.
dgatwood is offline   Reply With Quote