Quote:
Originally Posted by KevinH
Hi Peter and DiapDealer,
I cleaned up the code, removed redundant pieces, formed proper classes, added debug information, etc.
So here is the release version of mergeKF8Only_v050.zip
mergeKF8Only 0.50
based on mobi_unpack.py code written by: Charles M. Hannum,
P. Durrant, K. Hendricks, S. Siebert, fandrieu, DiapDealer, nickredding.
Description:
In a dual KF8 mobi file, replaces the original mobi portion
with a KF8Only message, leaving the KF8 portion untouched.
Usage:
mergeKF8Only_v050.py -h -d infile.mobi message outfile.mobi
Options:
-h print this help message
-d use verbose debugging
The message file must be:
- a mobi html file in raw markup language format
- less than 4096 bytes in total
- utf-8 encoded
One easy way to generate a message file is to use kindlegen to create a mobi which consists just of your message and then unpack that mobi with WRITE_RAW_DATA set to be true using mobi_unpack.py. A sample test.rawml file is included in the zip archive. It can be edited with any good text editor.
Have fun!
KevinH
|
Hi, Kevin:
Can you advise as to what happens to the output after the file is run through KDP? KDP currently looks for both the K7 and K8 files in order to create a "MasterMobi" that can display properly on both Fire and e-ink Kindles. I know that if, for example, I create an old prc file and the client uploads it, they get an azw-prc, not a Fire-optimized book, obviously. If I use a mobi that I've made with fallback CSS from an ePUB, created via Previewer, I get a MasterMobi that works on all devices. (Assuming, naturally, that my ePUB's CSS is correct).
What happens when KDP encounters your--what do you want to call them--"uncombined" K8 files? I've learned that a K8 mobi "merely" viewed in Previewer isn't an adequate test; a K8 mobi that's been run through the KDP is a different animal, so I'm curious to know what happens to your betas? Display-wise, what happens to the post-KDP files?
Thanks!
Hitch