[Hitch]

Originally Posted by Psymon

I agree, that seems like such an obvious solution and I did think of that, too, but looked for an alternative solution for one simple reason: bandwidth. To do it that way, I'd have to have a separate image for each and every chapter (and this book I'm working on has 20+ chapters), but with this SVG method I only have to include a single image. It's a huge difference in the file size of the book.

That, I can understand. File-size, at least for MOBI and Amazon, matters a great deal. Of course, Amazon's going to compress those images to 128kb anyway, so.... it won't be a "massive" file no matter what you do, not with "only" 20 images. But naturally, it will be smaller with one.

Does everybody out there design just one single version of their books that works on virtually every platform? That seems like a shame, actually. While I would certainly agree that it would be ridiculous to come up with countless different versions geared to work on each and every platform, I don't think it would be unreasonable to do two versions -- a "fancy" version for those platforms that can handle the fancier stuff, and a "plain" version for those that don't.

I'm going to try to refrain from saying, "are you out of your mind?" here. We've made multiple "versions" of a book, with separate ISBN's, which is fine for putting one book on one retailer platform and one on another (say, iBooks and Nook, for example). What gets wonky is when someone tries to put two versions of a book up on the same retailer, to accommodate a retailer that has various devices that have various capabilities (e.g. Amazon).

I'd also remind you that most bookmakers are either donors of time (PD, for PG or here), authors doing their own books (like you), both of which naturally have all the time in the world, or commercial bookmakers, like me, who on average, are paid less than the price of dinner for two without booze in Los Angeles at a decent restaurant for the total conversion, start to finish. Making yet a fourth format...that's a bit much. We are already having to make an ePUB, a Smashwords ePUB, and a MOBI with a crapload of fallback styling to work "right," so we can't just make one ePUB to rule them all, any longer; not since the advent of K8. Seriously, other than embedded multimedia, it seems ridiculous to me to add another ePUB just for...whatever.

I know I'm getting a bit off-topic here (from the original subject heading of this thread), but the book I'm currently working on is only my second one, and so far I've pretty much be designing exclusively for iBooks/ADE. Naturally I'd also like to come out with a Kindle version, too (if only for the greater market share that one can reach), but I haven't even begun to look into it -- yet -- and must admit that it seems rather daunting. All I keep hearing is that "you can't do this" and "you can't do that", because earlier Kindles just won't support it -- but hey, at the same time, "you can do it for KF8!"

Yes? You'll have to learn "fallback coding," so that your book can do what Ruben will tell you can be done (ahem) for Kindle8, and a "fallback" so that the devices/readers that cannot display the K8 stuff (like background images) will still look good. AFAIK, there are not a lot of tutorials around on 'fallback coding," that's a bit of a newish thing, relatively speaking, and most of it is skinned knees and "road scholar" type stuff. I'm quite sure Ruben will be helpful to you.

Well, what the hey, how does one design for Kindle at all, then, if one wants to incorporate any kind of design? What's the point in coming up with a design that'll work in KF8 if anyone with an earlier model won't be able to render it properly? Or does amazon have things set up somehow that if your design incorporates things that will only work in KF8 (or whatever), then you need that in order to even buy the book in the first place?

Amazon's servers determine the device that is ordering the book and "ships" the correct "version." When you build a mobi, 3 files are actually incorporated inside; an archival copy of the source material (in my case, an ePUB); a K8-optimized version (mobi); and a K7 version (prc). If I were to order a book to be sent to 'Hitch's Kindle 1," it would send me the K7 version. When I download the same book to my Fire, it sends me the K8 version. All in all, it's rather sophisticated. Amazon uses "media queries" to create the fallback coding for the K7's...rather, I mean, YOU use media queries to create the fallback coding. Media queries are actually pretty simple.

I have no idea how Amazon/Kindle works -- I have no idea what format the files are in, like, if they're in HTML/CSS like epubs are, or what. I guess I should start googling it and learning about it in my spare time, of course, but in that regard if anyone can point me directly to a really good tutorial on the subject (and hopefully one that's not too confusing) that would be much appreciated.

And thanks in advance for that!

Well, I'd suggest you start with the wiki here, then the MOBI forum, and work your way out. There are scads of blogs with utterly useless and/or outdated advice, or people who say to use Calibre, yadda, so...start here. Then work outward for the bits and pieces that you cannot find here. That's my best advice.

@Ruben: I really, really, just want you to be clear when you say "works on Kindle." Not everyone who reads here instantly knows what you actually mean, or can tell at a glance that the CSS won't work on K7. I think it would be more helpful to the community on a whole if you clarified it by saying "works on Kindle K8 format." That's all I'm asking.

Hitch