View Single Post
Old 12-10-2011, 03:56 PM   #229
sourcejedi
Groupie
sourcejedi ought to be getting tired of karma fortunes by now.sourcejedi ought to be getting tired of karma fortunes by now.sourcejedi ought to be getting tired of karma fortunes by now.sourcejedi ought to be getting tired of karma fortunes by now.sourcejedi ought to be getting tired of karma fortunes by now.sourcejedi ought to be getting tired of karma fortunes by now.sourcejedi ought to be getting tired of karma fortunes by now.sourcejedi ought to be getting tired of karma fortunes by now.sourcejedi ought to be getting tired of karma fortunes by now.sourcejedi ought to be getting tired of karma fortunes by now.sourcejedi ought to be getting tired of karma fortunes by now.
 
sourcejedi's Avatar
 
Posts: 155
Karma: 200000
Join Date: Dec 2009
Location: Britania
Device: Android
Round-trip failure with mobiunpack & kindlegen v1.2 on linux

[If this should be a new thread, please do ask mods to move it]

This is not a support request. Just to let you know I noticed a round-trip failure using mobiunpack, kindlegen 1.2 for linux, and a Mobipocket edition of one of the Young Wizards books. I'm curious whether this is a known bug.

I unpacked it, edited the "HTML", and invoked Kindlegen on the OPF file. (That's generall expected to work, right?) No problem so far; FBReader seemed happy with the new MOBI file.

But then I tried to verify it by unpacking the new MOBI and checking for differences. This happened -
Code:
<p height="0pt" width="0pt" align="justify"><a  filepos=0000008568 ><font color="blue"><u>Consultations</u></font></a></p>
i.e. a number of links are output as filepos= instead of href= - here's the original:
Code:
<p height="0pt" width="0pt" align="justify"><a href="#filepos8519"><font color="blue"><u>Consultations</u></font></a></p>
I double-checked the new MOBI in FBReader, and that specific link is working fine. mobiunpack does seem to find the matching anchor; it's just the links that have gone weird.
Code:
<mbp:pagebreak/></div><div><a id="filepos8568" /><a id="filepos8568" /> 
<p height="1em" width="0pt" align="center"><font size="5"><b><font color="red"> Consultations</font></b></font></p>
ISTR hearing that having multiple anchors next to each other in MobiPocket can be bad news... I think mobiunpack generates them because there are two links to the same location (from two different tables of contents)... but if that were the problem, I'd have thought it would show up as KindleGen dying, or a loss of functionality in the MOBI file, which hasn't happened...

FULL DISCLOSURE. The original MOBI also includes some "dead links" (href="../Text/#filepos6634"). After the round-trip, these appear as filepos=XXXXXXXX. So, it's possible these dead links are confusing mobiunpack, although I'm not sure how. [KindleGen warns "Warning(prcgen): Hyperlink not resolved", but continued anyway. I don't see any other warnings. Ideally mobiunpack would provide a similar warning during unpacking, so you can tell something odd has happened.]

Second disclosure. From the above evidence, I believe that the "original" MOBI has already gone through at least one MOBI->EPUB->MOBI conversion. (Presumably edited in Sigil in between). I have a copy of what I assume is the EPUB version. The EPUB also has "calibre" written all over it (class="calibre"). So it's quite possible the MOBI I started with was generated by Calibre's reverse-engineered code, as opposed to the official MobiPocket/Kindle conversion code.

Last edited by sourcejedi; 12-11-2011 at 11:42 AM. Reason: CODE tags preserve significant whitespace
sourcejedi is offline   Reply With Quote