Mobiperl Mobiperl - Perl tools for handling MobiPocket files

[kevindorsey]

Still quite a few problems it seems.

[tompe]

Originally Posted by HarryT

Here's an example.

The file "book.prc" was created from "book.opf" using Mobi Creator. As you'll see when you open it, it has both a cover image, and a "Table of Contents" link which takes you to the TOC. The file "test.mobi" was created from the same OPF file using the command line:

opf2mobi --mobifile test.mobi book.opf

You will find that it has no cover image, and, although it has a "Table of Contents" link, that link takes one to the first page of the book, rather than to the TOC.

I believe that the Guide items in the OPF file are specified as you describe, so any light that you could shed on this would be most welcome.

When I open the file I get

  href="book.html%23toc"

Why do I get %23? Why do I not get a #? Is # encoded in a special way in UTF-8?

[tompe]

Originally Posted by HarryT

Minor change request:

Any OPF file created by Mobi Creator seems to start with the 3 byte sequence:

EF BB BF

immediately before the opening tag <?xml ...

These three bytes make "opf2mobi" give a "junk before XML element" error. Would it be possible to make the tool ignore them?

A little research shows that this is a Unicode "Byte Order Mark" sequence indicating that the file has UTF-8 encoding. See:

http://en.wikipedia.org/wiki/Byte-order_mark

for details.

Yes, I have not been so careful with UTF-8 support since for me it seems to cause problem each time I try to start to use UTF-8. I will look at it.

The opf file in Test.zip did not seem to have this sequence. Is this correct? Was that not generated from Mobi Creator?

[HarryT]

Originally Posted by tompe

When I open the file I get

  href="book.html%23toc"

Why do I get %23? Why do I not get a #? Is # encoded in a special way in UTF-8?

The OPF file was created by Mobi Creator, and I guess that's just the way it does it. If you load the OPF file into Mobi Creator and look at the "Guide" page, you'll see that it's actually displayed as a "#" in the GUI.

Would it be possible to change your code to recognise either "#" or "%23"? It's just that Mobi Creator provides an excellent interface for creating and viewing an OPF file, so even if I use your tool for building the book I'd still like to be able to use Mobi Creator for editing the OPF file.

[HarryT]

Originally Posted by tompe

Yes, I have not been so careful with UTF-8 support since for me it seems to cause problem each time I try to start to use UTF-8. I will look at it.

The opf file in Test.zip did not seem to have this sequence. Is this correct? Was that not generated from Mobi Creator?

I manually deleted the three bytes using a hex editor so that the OPF file was acceptable to "opf2mobi".

[tompe]

Originally Posted by HarryT

The OPF file was created by Mobi Creator, and I guess that's just the way it does it. If you load the OPF file into Mobi Creator and look at the "Guide" page, you'll see that it's actually displayed as a "#" in the GUI.

Would it be possible to change your code to recognise either "#" or "%23"?

Is the intention that it should be a hash mark?

I removed the BOM mark (which is optionally but allowed in UTF-8) but I have some other problem getting it to work at all. I teally hate UTF-8...

I have not implemented UTF-8 characters correctly in the body of the book so if you use UTF.8 there you should probably use a calibre command line tool instead. If you do not use any multi byte characters then opf2mobi should work (better after I fix the current bugs).

[HarryT]

Originally Posted by tompe

Is the intention that it should be a hash mark?

Yes. When you type a "#" into a URL in Mobi Creator's OPF editor, it writes it as "%23" (ie 23 in hex - the ASCII code of the # character) in the output file.

I removed the BOM mark (which is optionally but allowed in UTF-8) but I have some other problem getting it to work at all. I teally hate UTF-8...

Thank you.

I have not implemented UTF-8 characters correctly in the body of the book so if you use UTF.8 there you should probably use a calibre command line tool instead. If you do not use any multi byte characters then opf2mobi should work (better after I fix the current bugs).

Just to clarify, this is UTF-8 encoding being used by Mobi Creator for the OPF file itself - it has nothing to do with the encoding of the book. All the books that I create use the "standard" western European code page 1252.

[nrapallo]

Originally Posted by tompe

When I open the file I get

  href="book.html%23toc"

Why do I get %23? Why do I not get a #? Is # encoded in a special way in UTF-8?

When you see the href="book.html%23toc", it has nothing to do with UTF-8, but rather is a result of URL Encoding which removes special punctuation characters from URL's.

In Perl, there is a function that will take an already encoded URL and decode it back to simple ASCII. Please refer to uri_unescape() which converts a URL encoded string to its normal representation.

Then just post-process any URL link that contains a % using uni_unescape, if you would rather not deal with this encoding.

[tompe]

Originally Posted by nrapallo

When you see the href="book.html%23toc", it has nothing to do with UTF-8, but rather is a result of URL Encoding which removes special punctuation characters from URL's.

.
And the wikipedia page says "URI producers are discouraged from percent-encoding unreserved characters." and in this context # is an unreserved character.

But i will fix the program to handle this.

[nrapallo]

Originally Posted by tompe

And the wikipedia page says "URI producers are discouraged from percent-encoding unreserved characters." and in this context # is on unreserved character.

The # may not be a reserved character, but may be deemed an "unsafe character" nevertheless.

I guess, Mobipocket Creator adheres to a more strict handling of said characters.

You know what they say, Tommy, "If you can't beat them, join them".

[tompe]

It seems that XML::Parser::Lite is not working properly in Perl 5.10.0 (which is my new default Perl). That means that parsing of opf files will fail. Hopefully only opf2mobi is affected. When I figure out a good solution to this problem I will release a new version.

[HarryT]

Thanks, Tommy. Look forward to it. The image quality with your tool, which has the option of not rescaling images, is dramatically better than that of Mobi Creator, which insists on doing so. In the mean time, I'll manually edit my OPF files and replace "%23" with "#".

[Jellby]

Originally Posted by HarryT

Thanks, Tommy. Look forward to it. The image quality with your tool, which has the option of not rescaling images, is dramatically better than that of Mobi Creator, which insists on doing so. In the mean time, I'll manually edit my OPF files and replace "%23" with "#".

Last time I checked, Mobiperl still insisted in recompressing images larger than ~64KB (it doesn't change the height and width, but the quality). I didn't find a switch to prevent it, so I had to modify the perl code somewhere. I'd be delighted if I were shown wrong Otherwise, I thought better I'd warn you.

[tompe]

Originally Posted by Jellby

Last time I checked, Mobiperl still insisted in recompressing images larger than ~64KB (it doesn't change the height and width, but the quality). I didn't find a switch to prevent it, so I had to modify the perl code somewhere. I'd be delighted if I were shown wrong Otherwise, I thought better I'd warn you.

There is a flag "--imagerescale 0" which I think will disable all scaling. I checked th code now and from the code without actually testing I draw that conclusion (so i might be wrong...).

[tompe]

Originally Posted by tompe

It seems that XML::Parser::Lite is not working properly in Perl 5.10.0 (which is my new default Perl). That means that parsing of opf files will fail. Hopefully only opf2mobi is affected. When I figure out a good solution to this problem I will release a new version.

The version of XML::Parser::Lite::Tree in Debian stable was 0.03. Updating to 0.08 using CPAN solved the problem I had getting it to work at all.