Quote:
Originally Posted by pdurrant
Bear in mind that calibre-generated Mobipocket files might not be valid in all instances, since the code was written with reverse-engineered info, not with documentation of the format.
|
Absolutely, btw does anyone knows a way to spot calibre-generated books / identify the book generator ?
Quote:
Originally Posted by siebert
I assume that the ncx index also contains a IDXT section, why don't you don't use it to find the start and end position of each entry, so you can verify that you've decoded all bytes?
|
I was thinking about what's left to parse, and so the INDXT section at the end of INDX0 came to mind.
I didn't you what was in there when I started this, if i understand you right it contains the position of the actual index entries in the INDX1, is that it ?
If someon didn't already do it, I'll look into it...
Quote:
Originally Posted by DiapDealer
Your latest (mobiunpack_testncx_onemore.zip) still has a bit of a bug if the mobi doesn't have an ncx. You're building the opf so that the spine always indicates the toc="ncx" bit.
|
You're absolutely right, and the worse is I new about it but had never fixed it
That's what happens you release proof of concept code in a haste
...
About the TAGX / mask stuff thanks for all your input and shaping this code into something correct, I knew too little about the mobi format to figure that out quickly...
About the refactor bit go ahead KevinH if you feel like it, perhaps you could share here a skeleton of the class structure, so that other can comment / improve on it ?