Hi tkeo,
Thank you for the examples, I will play around with them. I can't believe that a Kindle device supports the spine/page spread properties by keeping and parsing the RESC section on the fly during reading. My guess is they must include or encode that information in some other way but I that is just a guess and I could be wrong.
I had never heard of the page spread properties and so searched up on them. They seem to be specific to fixed layout and comics.
Many of the spine properties you are parsing for in the RESC are not part of the official epub 2 spec at all and are epub 3 or non-universal epub 2 extensions.
KindleUnpack tries to generate a working epub that meets epub 2 specs since as far as I know there are no true shipping epub 3 devices.
Your features technically would require an epub 3 spec book or us just adding then to epub 2 and hope that the mix works just fine. I am not sure that is the right approach.
Perhaps it would be better to create a separate version of KindleUnpack that tries its best to create an epub 3 like output since current Kindle AZW3 is someplace between epub 2 and epub 3.
Quote:
Originally Posted by tkeo
Hi,
BTW, I encounter a curious phenomena. Ebooks generated by Kindle Comic Creator (ex. rtl_example2.mobi) are able to unpack; however , created epub files are not accepted by kindlgen, whereas unziped kindlegensrc.zip files are accepted. This occurs v62 too.
Thanks,
|
The kindlegensrc is always a zip of what you input to kindlegen and so it can always be used and will work with that version of kindlegen.
The epub 2 like structure we generate is not from kindlegensrc but instead from reverse compiling the AZW3. If you have access to kindlegensrc then you should not need KindleUnpack unless you want to explore just how the raw AZW3 text is generated or interpreted by kindlegen.
Many times the user only has access to a shipping AZW3 or a stripped AZW3 (these will not have the SRCS section) and KindleUnpack will do its best to decompile the AZW3 back to something usable.
KindleUnpack will not generate an exact replica of the input sources nor is it even guaranteed to generate a working epub! But in most cases, if a valid verified epub2 is input into kindlegen, then KindleUnpack will generate a valid working epub2.
If the user inputs old/broken html or even old mobi 6s onto kindlegen, it will create the mobi/azw3 but when it is unpacked using KindleUnpack this software will do its best but will most likely not generate a valid epub2.
So ignoring fixed layout books for the moment and comics, do you have any test cases that show a valid epub 2 being given to kindlegen that KindleUnpack unpacks to a non-valid epub 2?
If so, I would consider them bugs and so would love to have a bug report with a testcase that shows this behaviour.
I will look closer at what you have done but as Kindlegen supports more and more epub 3 as valid input, we will need to create a new version of KindleUnpack that unpacks to an epub 3-like container and not an epub 2.
Frankly after studying the epub 3 spec, it seems the people who created the spec don't really understand what ebooks are all about and are completely missing the fundamental concept that simpler is better for all things. What a mess!
Unfortunately, right now with the various private extensions supported for fixed layout, comics, and multi-media ebooks all differing by epub vendor (Apple vs ADE/Kobo) and Amazon and the huge overhead and unnecessary complexity of epub 3, we are in some no-man's-land between official epub 2 and some fantasy epub 3.
KevinH