Quote:
Originally Posted by DNSB
Perhaps you missed the bytecode compiler reference? Expecting a KFX to have the same structure as an epub/azw3 is like expecting a Pascal p-code file to have the same structure as the Pascal source code file.
|
No I did not. Since I have actually WRITTEN interpreters and and compiler I'm familiar with the concepts. However it's NOT the same idea at all as p-code or bytecode as that is a program executed on a virtual machine. The KFX is a compression of DATA, it's mostly content. Text & Images. Even the styling information originating in CSS isn't instructions in the the bytecode / pcode sense. The KFX is really entirely specifying data like a Word 95 doc file, it's not instructions in the sense of VB, or Java program.
Obviously you can't open a KFX and see the same thing as in an AZW, it's encoded. However ultimately there is only storage space saving. The data has to be interpreted to produce the same results. It's originated as css, HTML, index (all no doubt in an intermediate stage encoded to XML, but I don't know). The images will be separate blocks of data. Then no doubt some sort of tokens for the non-image data and encryption for DRM.
It's absolutely not a program, just a different representation of the data.
Like bytecode/p-code to Java, J++, C#, VB or UCSD-Pascal, you can get back a human readable source, but it will have lost all non-essential to the page content and rendering information and be hard to read.
At "run time" the Kindle or Kindle app must be converting KFX data to the equivalent of text, styles, index and separate blocks of images. Nothing else makes any sense. It's ENCODING, not byte code or p-code in the sense of a program. It makes it VERY much more compact than general purpose zip archiving can and thus any encryption (DRM) is more effective.
I totally agree there in no concept of "seeing" NCX, CSS, HTML and JPEGs in a KFX, nevertheless it's encoded and thus might have a higher CPU load than AZW/KF8, epub, kepub as the aim is lower transmission cost and more security.
The original point was that kepub certainly isn't any significant reduction in reader cpu requirement, neither is KFX. Probably the reverse as they are newer formats to aid distribution.