Quote:
Originally Posted by Doitsu
However, based on mattmc's K4iOS, AZK, The Latest post it looks like Amazon delivers a file format to K4iOS that is very close to the format that AZKCreator.exe generates.
I asked mattmc to chime in on this, however, since he hasn't visited in MR in weeks, we might not get an answer. |
Perhaps it's not so bad that I play necromancer on this thread--it's only been dead three weeks or so. Not even enough time for rigor mortis to set in!
Sorry for my absence, Doitsu. I actually still have some more comments to put in that other thread...I'll get to that.
On the current topic, this is actually an important subject for me right now. I do wish that Amazon provided figures for device & firmware versions on the market, at least in terms of what's accessing their stores. Apple provides this data to iOS developers, in terms of who is using what operating system.
Anyway, when I started off in eBook development, I specifically purchased a Kindle Keyboard to preview old KF7 files...but I've begun to suspect that it's a K3, and started looking around for a used DX, just so I can be totally sure about what I'm seeing. (I think I'd heard from @Hitch that her company employs DXs for KF7 checking...maybe not.)
On the subject of the Kindle Apps, I can't speak for KDroid or KCloud, but I have investimagated K4iOS some, so there's a few things I do know:
First, to be clear:
AZK is an intermediate file format, between what comes out of Kindlegen (compound KF7/KF8), and what K4iOS actually reads. Based on my testing, when you give an AZK file to K4iOS, it converts it into a .KCR file. So it's just a bridge.
Secondly: Some eBooks that are delivered from Amazon to K4iOS are KCR, while others are AZW. I'm not sure why.
Thirdly: Given that KF7 is a file format, specifically a binary mobipocket database format, K4iOS is definitively not a "KF7 reader", for the simple reason that it reads KCR files as well. I'm not sure if there's a way to tell if the AZW files that I saw in there were KF7 or KF8 or what, but if they are KF7, maybe K4iOS can read both KF7 and KCR?...
Fourthly, if we assume that K4iOS can read both KF7 and KCR, it's possible that what Hitch has seen with K4iOS in terms of formatting weirdness could be related to the KF7 format rather than the K4iOS rendering engine. What you get in the screen is the product of an interesting dance between the content in the file and the rendering engine, and K4iOS is most
certainly a different rendering engine than K1, K2, and DX.
Fifthly, and as an irritating note: IIRC, I did see some minor differences between the KCR files downloaded from Amazon, and the KCR that was created by sideloading an AZK file. That might account for Hitch's perception that AZK -> K4iOS != KDP -> K4iOS. Frankly, I wouldn't be surprised if Amazon's content delivery backend handled things different than AZKCreator and/or K4iOS's AZK -> KCR converter. They're just a large enough company with enough on their hands to not handle delicate things like this well.
Anyway, my summary concept would be that the KApps are not "KF7", but are perhaps not KF8 either. Perhaps they are just...KCR. (Hooray, perhaps the most untested file format!)
=====
P.S.:
I did claim in another thread that fonts carried through from EPUB -> KF8 -> AZK -> K4iOS, refuting Hitch's assertion that K4iOS was KF7-only, upon which she asked for screenshots, and I never delivered. So I will try to post those here and/or there.
P.P.S.:
Most of my testing and viewing into the underbelly of K4iOS has occurred on an iPad 1, running iOS 5.1.1, with K4iOS 3.9.2.