View Single Post
Old 09-01-2010, 06:02 PM   #13
ATDrake
Wizzard
ATDrake ought to be getting tired of karma fortunes by now.ATDrake ought to be getting tired of karma fortunes by now.ATDrake ought to be getting tired of karma fortunes by now.ATDrake ought to be getting tired of karma fortunes by now.ATDrake ought to be getting tired of karma fortunes by now.ATDrake ought to be getting tired of karma fortunes by now.ATDrake ought to be getting tired of karma fortunes by now.ATDrake ought to be getting tired of karma fortunes by now.ATDrake ought to be getting tired of karma fortunes by now.ATDrake ought to be getting tired of karma fortunes by now.ATDrake ought to be getting tired of karma fortunes by now.
 
Posts: 11,517
Karma: 33048258
Join Date: Mar 2010
Location: Roundworld
Device: Kindle 2 International, Sony PRS-T1, BlackBerry PlayBook, Acer Iconia
I hope I'm not being discouraging by saying this, but it's starting to look like one would be better off creating separate CSS and OPF files for one's books, depending on what output format one intends to produce for them.

Documenting a lowest common denominator for Kindle and ePub XHTML/CSS support and trying to find some universal formatting points that people could rely upon is a great idea, but it's kind of kneecapped by the fact that in Kindlegen's case, the low appears to be *really* low.

That said, your experiments make for interesting and informative reading, so best of luck with it.

Edit: Just curious if you've tried it - do the "larger"/"smaller" keywords in CSS work at all, or just in the same broken way that the other stuff does? Because the W3C specs say it's supposed to +1/-1 the current font size as set by the user, though if Kindlegen's already ignoring relative font size tricks, it'll probably ignore that, too, assuming it's part of the subset of CSS it seems to understand.

Last edited by ATDrake; 09-01-2010 at 06:12 PM.
ATDrake is offline   Reply With Quote