Kindle for iPad - CSS for tables broken?
 

Has anyone seen this odd behaviour in Kindle for iPad app (also iPhone)?
I'm working on a project that needs moderately complex tables and also multiple table types. BUT the CSS formatting is screwing up on this particular app. The CSS is fine in a browser and ALL OTHER eBook readers I can test for including the Kindle previewer.

Here's a super-simple example.


Using 'normal' css:

All cells show BLUE. It looks like it's ignoring everything after "table.table1" because if I delete the table.table1 td.r line, then everything renders GREEN.


Here's the closest I can get:

TD: shows green (correct)
TH: No BG colour (WRONG)
TD.r: Shows blue (correct)

That's suggesting that indeed it's ignoring the first type and class part of my CSS identifier and just to add insult to injury, it's ignoring TH. That kind of scuppers my multiple table formatting plans.

I've beaten my face against Amazon for MONTHS now and can just BARELY get them to understand that this is a developer question rather than a customer complaint about an eBook that's been purchased. I managed to get to a tech person but now they're crashed in a loop of apologising for the problem and asking me to send my source code.

Driving me NUTS!

Did you generate an .azk file with Kindle Previewer and sideload it to your iPad? (If you sideload the mobi file generated by Kindle Previewer, the Kindle for iOS app will only show the Mobi7 part.)

Nope. Sent the MOBI to iPad via the "send to kindle" app. Not sure what that then does to the MOBI, but I'd like to think that this would be a good method of getting a close to consumer test of the file.

That's actually not a good method because the kindle for iOS apps don't fullly support AZW3/KF8 and the old Mobi7 format that you sent to your iPad definitely doesn't support the styles that you're having problems with.

For more information on the AZK format see this thread.

To be more explicit, Mobi7 supports no CSS or inline styles at all. Everything has to be done with tag attributes, not CSS. The KindleGen program (and Calibre) will make a "best endeavours" attempt at converting CSS into tab attributes for Mobi, but if you have a need for Mobi7 it's a much better idea to do the job manually.

If, however, you send a "dual Mobi" book to Amazon's Cloud, the iPad will download the KF8 version of the book. Best thing to do is follow Doitsu's advice and use Kindle Previewer to generate an AZK file.

Aha... this is starting to make a LITTLE sense now, and I'm seeing the dual-format nature of my MOBI too: KindleGen says "Approximate Standard Mobi Deliverable size 712kb, Approximate KF8 Deliverable file size: 741kb" and the resulting MOBI is 1439kb... cool: So it contains BOTH Mobi7 and KF8, which would explain why it looks just fine on Kindle Previewer and some other readers that are able to pull the KF8 out.

SO, you're saying that Kindle for IOS uses the Mobi7 part? (that's pretty cr@ppy tbh) I know about Mobi7 not using CSS, so that kind of makes sense.

I guess that then means that unless I change my formatting to be more conducive to the 'best attempts' at putting styling in tags that I'm going to have to forget this looking right on IOS then? (Or wait until they release a major revision)

Not over the moon with that, and also not entirely happy that whoever developed the IOS reader has taken that decision.

(Oh, and by the way guys THANKS for helping -I've gotten closer to the cause of this in 24 hours than 6 months of hacking away with Amazon tech team!)

If you "sideload" your Mobi to the iPad it will use the Mobi7 version of the book. If you send the book to Amazon's Cloud and then download it to the iPad from the Cloud it will use the KF8 version.

If you're sideloading a Kindle Previewer/KindleGen generated mobi file. Kindle for iOS will display the Mobi7 part.

Since Kindle for iOS doesn't support AZW3 files Amazon came up with the AZK format, which supports some AZW3 features and mimics the actual file format that Kindle for iOS users get if they buy Amazon books.

(For the most part AZK files look like their AZW3 counterparts.)

I.e., the book that you tested by sideloading the KindleGen generated mobi file might actually look OK on iPads if bought from Amazon because Kindle for iOS users get the AZK file equivalent.

Yep, I'm not sideloading but going through "send to KIndle" - which you're saying results in the KF8 version appearing on the iPad.

.... so that's the explanation of the failure of formatting then? Is it then just down to a bug or omission in the app rather than it picking up Mobi7?
Doitsu, you said that Kindle IOS "doesn't fully support KF8". Does anyone know the extent to what they do or don't support? (again, I'd frown at them for seemingly half-doing the job of writing a reader).


(yay 100 posts)

Since iPads don't fully support KF8 you can't send AZW3 files. Send to Kindle most likely sends the mobi7 version to the iPad. (I haven't tested the Cloud option as HarryT suggested.)
You can easily test this yourself with an ePub with media queries for Mobi7 and AZW3.
For details see the Kindle Publishing Guidelines.

AFAIK, the only way to find out what works and what doesn't is to sideload AZK files.

Joy.

Okay, looks like this is going to be a bit of a long haul then.
But, as they say what doesn't kill us makes us stronger. I'll add some media query goodness to the standard CSS files while I'm there too.

That is not true for iPad. Amazon creates an AZK file for Kindle Reader on an iPad. AZK seems to be a prelude to the KFX format now being used by Amazon as its most advanced format, but it is not compatible with AZK either. I suspect, at some point KFX will roll out for iOS but KF8 never will.

Dale

Are you saying that if you have a dual Mobi in the Cloud, the iPad will download the Mobi7 component of the file?

Most probably (Is the cloud automated?) but if Amazon knows you own a iPad they will deliver an AZK version. Amazon has been mum on what is going on here.

Dale