View Single Post
Old 07-31-2015, 12:25 AM   #27
mattmc
Connoisseur
mattmc can program the VCR without an owner's manual.mattmc can program the VCR without an owner's manual.mattmc can program the VCR without an owner's manual.mattmc can program the VCR without an owner's manual.mattmc can program the VCR without an owner's manual.mattmc can program the VCR without an owner's manual.mattmc can program the VCR without an owner's manual.mattmc can program the VCR without an owner's manual.mattmc can program the VCR without an owner's manual.mattmc can program the VCR without an owner's manual.mattmc can program the VCR without an owner's manual.
 
Posts: 89
Karma: 185923
Join Date: May 2015
Device: iPad 1/2/Air, K3/PW2/Fire1, Kobo Touch, Samsung Tab, Nook Color/Touch
I happened to find this thread on Google when looking for something else...

Quote:
Originally Posted by dgatwood View Post
Here's a list of differences between my Kindle EPUB and my production EPUB:

...

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.
Wow. That's an impressive list! And scary.

Quote:
Originally Posted by dgatwood View Post
For KF7, Kindlegen converts the CSS into HTML markup, but does it very badly, with a CSS parser that doesn't properly handle selectors containing multiple elements, multiple class names on single elements, lists of selectors applied to a single rule set, etc., resulting in all sorts of joy for those of us who routinely use nontrivial CSS.
I wasn't aware of that. I'm dealing with CSS from InDesign, and I did see rules with multiple selectors--I guess I need to blow those apart with a script.

Quote:
Originally Posted by dgatwood View Post
Of course, if I were producing a general-purpose solution, I'd use a different approach, using a WebKit WebView to render the content, walk the DOM tree, and blow in tags based on the computed styles for each node. It would probably take only double-digit lines of code in total, and it would put Kindlegen to shame by being 100% correct in its interpretation of the CSS every freaking time.
One thing I did do, when I was working with iBooks and doing some fancy stuff with popovers, was I had to inline a bunch of styles onto the contents of the <aside> elements. Basically, iBooks was throwing out all the CSS that should have affected the contents of those elements.

I'm already doing all of my processing with NodeJS, and the NPM ecosystem is vast, so I easily came across Juice, which is a library originally designed for inlining CSS styles for emails (which can have just as archaic rendering systems as the original Kindles). It worked great (uses another library called Cheerio, which is a browser-less DOM parser and jQuery re-implementation). Anyway, that sounds like more or less what you were talking about with your WebKit WebView and DOM walking.

...Would you recommend doing style inlining for all of my Kindle files? I didn't want to Juice the whole file, because it's going to bloat it with style="..." attributes on practically every tag, but if it's necessary for KF7, I could make it part of my Kindle workflow...
mattmc is offline   Reply With Quote