Will opf2mobi convert an ePub to Mobipocket?

I tried another mobi file with mobi2html with the raw option and everything worked fine. Perhaps there was something wrong with the firs file I tried. Thanks for the fast responses!
Bob

Is there anyway to import a cover that has a resolution of 510x680 without changing the resolution? If not, then I have a bug to report.

I've found a bug that really needs squashing.. the cover... when adding a cover I get the following...
CREATING COVER IMAGE WITH ID: 7307727
Reading data from file: cover.jpg - 510 x 680 - JPG
SCALE GD: 510 680 -> 480 640

I don't want it scaled. I want it in the original resolution.

Is there anyway to import a cover that has a resolution of 510x680 without changing the resolution? If not, then I have a bug to report.

I've found a bug that really needs squashing.. the cover... when adding a cover I get the following...
CREATING COVER IMAGE WITH ID: 7307727
Reading data from file: cover.jpg - 510 x 680 - JPG
SCALE GD: 510 680 -> 480 640

I don't want it scaled. I want it in the original resolution.

The documentation say --imagerescale 0

Thanks!

Trying mobi2html on WinXP, I first installed ActivePerl 5.8.9 and the required packages. I added the .pl file extention and tried it but the script aborted at line 25:

C:\Documents and Set
tings\Owner\Desktop\New Folder\mobi2html.pl line 25.
BEGIN failed--compilation aborted at C:\Documents and Settings\Owner\Desktop\New
Folder\mobi2html.pl line 25.

UPDATE: I found the html2mobi.exe version and tried this and it work FAR more easily than this other approach with ActivePerl, etc, etc.

Thanks for making this application!

Toby

Trying mobi2html on WinXP, I first installed ActivePerl 5.8.9 and the required packages. I added the .pl file extention and tried it but the script aborted at line 25:

C:\Documents and Set
tings\Owner\Desktop\New Folder\mobi2html.pl line 25.
BEGIN failed--compilation aborted at C:\Documents and Settings\Owner\Desktop\New
Folder\mobi2html.pl line 25.

UPDATE: I found the html2mobi.exe version and tried this and it work FAR more easily than this other approach with ActivePerl, etc, etc.

Thanks for making this application!

Toby

Did you copy the MobiPerl directory and put it in the same directory as mobi2html? It seems like it does not find MobiPerl::Util but the error message is a bit confusing.

Or maybe you have to run it with "perl mobi2html..."

This is going to sound completely stupid, but I had never seen such a thing as perl before. So if you could help me... :)

This is my request:

I run on Windows XP, and installed the newest version of ActivePerl.

Then I installed these packages:
* p5-Palm
* TimeDate
* Getopt-Mixed
* Image-Size
* XML-Parser-Lite-Tree
* GD
* Encode
* image-BMP

Then I went to preferences and wrote this repository:
http://theoryx5.uwinnipeg.ca/ppms/package.lst (though it has 0 packages...)

So, what do I do next to install MobiPerl? I want to use Lit2Mobi, but I can't execute anything yet...

Can anyone help me, please?

I run on Windows XP There are pre-built Windows binaries that don't require Perl, here (https://dev.mobileread.com/dist/tompe/mobiperl/). You want mobiperl-win-0.0.41.zip.

Note that Calibre (has its own Forum here) can also convert from LIT to MOBI, and it does not require any other software (it is written in Python, but comes pre-built) and also comes with a GUI so you don't need to use the command line (although Calibre's any2mobi --compress ebook.lit will work from the command line like MobiPerl's lit2mobi).

Hi Tommy,

I've just tried "opf2mobi" for the first time, and I have a question. Apologies if this has been asked before, but I really don't want to read all 50+ pages of this thread :).

The end result is excellent, but I've found that it doesn't appear to use the items in the "Guide" section of my OPF file, which work fine with Mobi Creator. I don't get a cover image unless I use the "--coverimage" option, and the "Table of Contents" link in the resulting file takes me to the first page of the file, rather than the "TOC" link defined in the "Guide" section of the file.

There are pre-built Windows binaries that don't require Perl, here (https://dev.mobileread.com/dist/tompe/mobiperl/). You want mobiperl-win-0.0.41.zip.
Note that Calibre (has its own Forum here) can also convert from LIT to MOBI, and it does not require any other software (it is written in Python, but comes pre-built) and also comes with a GUI so you don't need to use the command line (although Calibre's any2mobi --compress ebook.lit will work from the command line like MobiPerl's lit2mobi).
Thank you very much!! I've just tried Calibre and it works right, and without so much trouble!

Hi Tommy,

I've just tried "opf2mobi" for the first time, and I have a question. Apologies if this has been asked before, but I really don't want to read all 50+ pages of this thread :).

The end result is excellent, but I've found that it doesn't appear to use the items in the "Guide" section of my OPF file, which work fine with Mobi Creator. I don't get a cover image unless I use the "--coverimage" option, and the "Table of Contents" link in the resulting file takes me to the first page of the file, rather than the "TOC" link defined in the "Guide" section of the file.

As I remember the implementation is a bit limited in functionality. Looking at the code now it seems like it does use the guide section only for TOC and cover image. If you give me an example file with more tags I can probably add more functionality to a future release.

That TOC and coverimage does not work is probably a bug or a limitation. The code looks like:

if ($type eq "toc") {
$self->set_toc_href ($c->{"attributes"}->{"href"});
print STDERR "TOCHREF: ", $self->get_toc_href (), "\n";
}
if ($type eq "other.ms-coverimage-standard") {
my $href = $c->{"attributes"}->{"href"};
$self->set_cover_image ($href);
}


So if the identifier is not "toc" and "other.ms-coverimage-standard" it will not work. And example file that does not work would be good to have...

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.

Thanks!

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.

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.

Yea, that is pretty standard for a text file to specify encoding. I think if a file doesn't have them it is assumed to be ANSI something or other.

The XML dom processor that perl has should certainly be able to support this accordingly. But I do admit I don't use perl at all...been quite a while.

BOb

Still quite a few problems it seems.

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?

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?

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.

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".

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).

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.

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 (http://en.wikipedia.org/wiki/Percent-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() (http://www.perlhowto.com/encode_and_decode_url_strings) which converts a URL encoded string to its normal representation.

Then just post-process any URL link that contains a % using uni_unescape (http://cpan.uwinnipeg.ca/htdocs/URI/URI/Escape.html), if you would rather not deal with this encoding.

When you see the href="book.html%23toc", it has nothing to do with UTF-8, but rather is a result of URL Encoding (http://en.wikipedia.org/wiki/Percent-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.

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" (http://www.blooberry.com/indexdot/html/topics/urlencoding.htm) 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". :smack:

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.

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 "#".

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.

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...).

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.

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...).

It does work. For maps, etc, I get dramatically better quality in the final book by using "--imagerescale 0". That's one of the reasons I wanted to try out "opf2mobi", because in Mobi Creator there's no way to stop the image quality being degraded to get the image under 64k.

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...).

I think you are wrong.

In MobiPerl/Util.pm, there's this:

# pdurrant
# do not resize large images if the filesize is OK,
# even if pixel dimensions are large
if ($filesize < $maxsize and
((not $rescale_large_images) || ($x <= $maxwidth and $y <= maxheight))
and $type ne "PNG"
and (not defined $scale_factor or $scale_factor == 1.0)) {

# No transformation has to be done, keep data as is
...
}

That's where I want the program to enter, but the condition is "if $filesize < $maxsize" and other things. I want that even if the filesize is larger, so I had to modify the if and make it:

if (($filesize < $maxsize and
((not $rescale_large_images) || ($x <= $maxwidth and $y <= $maxheight))
and $type ne "PNG"
and (not defined $scale_factor or $scale_factor == 1.0)) or (not $rescale_large_images)) {

which is not perfect (it won't touch PNGs, which it should), but it works for me.

I think you are wrong.

Jellby, you are right! Not that I'm taking sides... :snicker:

In my modified html2mobi.pl file that I call from within PDFRead, I sort of disable the automatic Palm image quality reduction which "fits" images within its maxsize (60K) by upping the maxsize to say, triple, that i.e. 180k.- In MobiPerl/Util.pm, changed bold part:
my $maxsize = 61000*3;


It is a nice tradeoff between too high quality in .mobi ebooks and inferior .jpg quality artifacts. Obviously this "fix" will break for Palm devices.

This is strange. My memory says that I allowed larger images in term of number of bytes but the code as you point out seems to say something else. I remember being very unwilling allow it but thought I gave in... I might just add a new flag...

This is strange. My memory says that I allowed larger images in term of number of bytes but the code as you point out seems to say something else. I remember being very unwilling allow it but thought I gave in... I might just add a new flag...

Your memory is correct; you allowed larger images NOT to be resized/rescaled with that flag, but never took care of the secondary .jpg quality reduction to "fit" the Palm maxsize resitriction. At least, this is how *I* remember it. :)

Curious. Why is it I wonder, in that case, that my maps, which are >64k in size, look so much better with "imagerescale=0" set? It really is a huge quality difference; text which is "blurry" with the default setting is clear and sharp with the flag set.

Curious. Why is it I wonder, in that case, that my maps, which are >64k in size, look so much better with "imagerescale=0" set? It really is a huge quality difference; text which is "blurry" with the default setting is clear and sharp with the flag set.

Perhaps they are larger than 640x480 pixels too?

There are these maxima:

Dimensions: 640x480 pixels, it can be disabled with "--imagerescale 0"
Filesize: 61440 bytes, it cannot be disabled with a flag (yet).

If you want to test, run mobi2html on the generated mobi, and you'll see whether the image files were modified or not.

Perhaps they are larger than 640x480 pixels too?

There are these maxima:

Dimensions: 640x480 pixels, it can be disabled with "--imagerescale 0"
Filesize: 61440 bytes, it cannot be disabled with a flag (yet).

If you want to test, run mobi2html on the generated mobi, and you'll see whether the image files were modified or not.

Thank you, yes, that will be the reason. They are 800x600 images.

Dimensions: 640x480 pixels, it can be disabled with "--imagerescale 0"


I think the bug is fixed in the Cybook so I will change the default to disabled.

Since I have fixed some "bugs" I did a version 0.41 which is available at

https://dev.mobileread.com/trac/mobiperl/

Let me know if I broke something (I have not tested it so much...)

Changes in 0.0.42

Added flag --allowtts to mobi2mobi

Added flag --deleteclippinglimit to mobi2mobi

Enhancement and bug fixes in Opf.pm (goto toc now works and it recognize more cover image tags)

Opf.pm: Removed BOM (byte order mark) from opf file data

--imagerescale default is now 0 (disabled rescaling)

Added flag "--imagemaxbytes n" to specify the maximum size of image data included in the mobi file.

Anybody feel free to build Windows binaries and upload them here...

Changing user name to 'Anybody' in 5, 4, 3, ... :-D

Changing user name to 'Anybody' in 5, 4, 3, ... :-D

Thanks :)

Changing user name to 'Anybody' in 5, 4, 3, ... :-D

Either that or 'Always'... :snicker:

Thanks a bunch!!!

If someone could build Windows binaries I'd be grateful - I don't have PERL installed on my PC :).

Edit: Ignore me - I'm overlooking what's right in front of me :D.

Since I have fixed some "bugs" I did a version 0.41 which is available at

https://dev.mobileread.com/trac/mobiperl/

Let me know if I broke something (I have not tested it so much...)

Changes in 0.0.42
...

Is it 0.0.41 or 0.0.42? And how are we supposed to download it? The download link only gives a changeset zip file, with README and Makefile.

Ah... I see, it's the other link.

You may want to revise these lines in mobi2mobi:

if ($len > 65535) {
print "ERROR: Record $id - Image data size definitely too large: $len\n";
} else {
if ($len > 61000) {
print "WARNING: Record $id - Image data size might be too large: $len\n";
}
}

I ran mobi2html on a nondrm book that I had bought online. It worked fine and I could open the html version on Firefox; it consisted of text mixed with jpg files of figures. However, I could not see any source code and when I opened the html with CoffeeCup editor, there were only two lines of text - long but not enough to cover over 200 pages of text.

Is there some way the author can hide the source code?
Bob

Is there some way the author can hide the source code? No. The "soure code" is the single HTML file. My guess is that the entire 200 pages are in the two lines you see, but the editor is truncating them.

Thanks for the info! I finally opened the html with MS Word and then looked at the source code and it all showed up. I was interested in precisely how the author formatted the book and how he use styles and css in general.

I'm working on an ebook and have done some simple html work before but haven't really used css, so I'm trying to learn by examples. The source code was useful because the author obviously hadn't used the overly complex automatic code generator results such as produced by MobiCreator for the html.

Bob

Mobipocket HTML is not a good way to learn CSS. Mobipocket formats flattens out all the CSS. I've found using Google to search for what I want to know helps. And then there is asking on MR as well.

I was interested in precisely how the author formatted the book and how he use styles and css in general. As JSWolf says, MobiPocket Creator and mobigen.exe import a limited subset of HTML+CSS and produce a highly simplified HTML for the MOBI file. A better place to look for examples would be an ePub ebook. These can be "exploded" by renaming the .epub to .zip and unzipping. Another possiblity is Kindle Formatting: The Complete Guide (http://www.mobileread.com/forums/showthread.php?t=44141). In fact, there is a DRM-free ePub version of the Kindle Formatting ebook, which might itself be a good example of ebook layout.

You may want to revise these lines in mobi2mobi

And adding the --imagemaxbytes option in mobi2mobi as well (for setting a large cover image).

And adding the --imagemaxbytes option in mobi2mobi as well (for setting a large cover image).

I just added it to the subversion version. The mobi2mobi code is really starting to get ugly due to the incremental adding of features...

I just added it to the subversion version. The mobi2mobi code is really starting to get ugly due to the incremental adding of features...

:thumbsup: ...and that's a good thing as it has steadily become much more useful! :2thumbsup

:thumbsup: ...and that's a good thing as it has steadily become much more useful! :2thumbsup

Hopefully more useful. I did not bother to test the new code :)

What is the proper syntax in mobi2mobi to add in a cover image that does not get resized and replaces what is currently the cover image or the first image wich is not linked as a cover? Also, I'd like mobi2mobi to not recompress the cover. Thanks.

I believe with the latest version you could use:

mobi2mobi input.prc --imagemaxbytes 9999999 --outfile output.prc

This version should not resize images by default anymore, and if the max-bytes is larger than the image size, it will not recompress it either. I don't think it replaces an image not linked as cover, though.

I don't think it replaces an image not linked as cover, though.

Sound plausible. You probably have to add the cover index first.

Can mobi2mobi be modified to remove the first image? And is there an windows exe of the version with --imagemaxbytes?

Can mobi2mobi be modified to remove the first image?

Well, probably not since the design decision for mobi2mobi it to not touch the content of the book. Just modify the headers and the images.


And is there an windows exe of the version with --imagemaxbytes?

Yes. Look at the web page.

Well, probably not since the design decision for mobi2mobi it to not touch the content of the book. Just modify the headers and the images.
One idea I had then was to be able to modify the First Page link to after the image. As it is now, I can add in a proper cover and make it so the page after that is blank. But First Page goes to that blank page. I'd like First Page to go to the first page of actual text.

Yes. Look at the web page.
The latest version on the website is 0.42 and when I just run mobi2mobi to get what options there are, --imagemaxbytes does not show up as an option.

One idea I had then was to be able to modify the First Page link to after the image. As it is now, I can add in a proper cover and make it so the page after that is blank. But First Page goes to that blank page. I'd like First Page to go to the first page of actual text.


You have to explode the mobi file and modify the html to do this. You could probably write a clever script using MobiPerl, Calibre, or the ebook-tools (or what the name of the Perl package was) to do this.


The latest version on the website is 0.42 and when I just run mobi2mobi to get what options there are, --imagemaxbytes does not show up as an option.

Ah, it is in html2mobi but not in mobi2mobi yet. 0.43 is not released yet.

So then it's not yet in the latest release. Any idea when the 0.43 will be released?

So then it's not yet in the latest release. Any idea when the 0.43 will be released?

Well, it is easy to just put it up but you can take the subversion code yourself instead. I just felt that for one change it was not worth it troubling the people that kindly buy windows binaries.

For me a new version is just the Perl code. The Windows binary is something that sometimes is available and something that will not be built by me.

Nah, don't worry about it. Building the windows binaries isn't exactly a lot of work for me - Uploading the resulting zip file takes me longer than downloading a new release and building the binaries in the first place. So throw out a new release whenever you feel like it.

Nah, don't worry about it. Building the windows binaries isn't exactly a lot of work for me - Uploading the resulting zip file takes me longer than downloading a new release and building the binaries in the first place. So throw out a new release whenever you feel like it.

OK, there is a 0.0.43 uploaded now and the only change is:


Added flag "--imagemaxbytes n" to specify the maximum size of image data included in the mobi file to mobi2mobi.


I have not tested the flag...

Here's the Windows build. Mobils seems to work, I haven't tested anything else, though.

ETA: I lost the attachment on the first upload attempt.

Thanks tompe and Gudy!

Since a lot of people have mentioned that it would be useful to be able to manipulate meta data and to add cover image to a prc or mobi file I wrote mobi2mobi. Here is the description of the program:

A program to manipulate MobiPocket files. Author and title can be set and a cover image (thumb nail image for Gen3) can be added.

There are two kind of prc files used for electronic books. One is a PalmDOC file which does not have a MOBI header but can contain HTML code marked up with MobiPocket specific markup and it can be read by a MobiPocket reader. For this format you cannot store meta information in the header. The other format is MobiPocket and it has a MOBI header and some additional data where you can store meta information and an extended title.

This program can change the extended title for a MobiPocket file. It can also automatically convert a PalmDOC file to a MobiPocket file and set the title.

It can also add author information to a PalmDOC file by converting it to a MobiPocket file and set the author meta information.

You can also add a prefix to a title in a MobiPocket file. This does not work for PalmDOC files.

It is possible to add an image to the file. If there are no other images in the file then the added image will be used as cover image and thumb nail image for Gen3.

Just running the program on a mobifile without any flags will print some information about the file.

Since there is no specification available for the MOBI header this program might generate books that are not entirely correct. So keep the original file...

I end up creating my own Mobi books just because I need to put the Author's name in correctily (Last, First Middle Birth-Death). I follow the Dewey list, that makes sure that I don't mix up authors with the same names.

Also, to list the title without its article first
"The Wizard of Oz" becomes "Wizard of Oz, The" which means that they appear alphabetically under Author sorting. In Cybook, I can just put them in directories of the author's name and they are in order!

Non-fictions are by "category"

I just downloaded your tool, I'll give it a try. If it works, this would be so great!

I have, in the past, successfully installed (thanks to the Visual Guide) and used Mobi2Mobi on my Mac running Leopard, but I must have accidentally deleted something during spring computer cleaning.

I am getting hung up in CPAN (and I'm no coder, so I have no idea what that even means) and get the following messages:

cpan> install Bundle::CPAN
CPAN: Storable loaded ok
Going to read /Users/Joanie/.cpan/Metadata
Database was generated on Sun, 24 May 2009 05:26:52 GMT
Warning: Cannot install Bundle::CPAN, don't know what it is.
Try the command

i /Bundle::CPAN/

to find objects with matching identifiers.

cpan> install Palm::PDB
Warning: Cannot install Palm::PDB, don't know what it is.
Try the command

i /Palm::PDB/

to find objects with matching identifiers.


I tried the command i/... that it suggested, and no luck. Anyone have any ideas on what I'm missing/doing wrong/can do to fix this?

Much appreciated,

Joanie

hello, somebody can help me: i have some .prc files, and i have to convert them to HTML.
i used mobiperl for this, but now i changed my operating system, and it don't works.
can somebody convert them?
this is the link to the books : http://rapidshare.com/files/271835832/prc_files.rar.html

I have just moved computer and I'm also having the same trouble reinstalling MobiPerl.

It seems that the Palm::PDB package is no longer available.

Help?


I have, in the past, successfully installed (thanks to the Visual Guide) and used Mobi2Mobi on my Mac running Leopard, but I must have accidentally deleted something during spring computer cleaning.

I am getting hung up in CPAN (and I'm no coder, so I have no idea what that even means) and get the following messages:

cpan> install Bundle::CPAN
CPAN: Storable loaded ok
Going to read /Users/Joanie/.cpan/Metadata
Database was generated on Sun, 24 May 2009 05:26:52 GMT
Warning: Cannot install Bundle::CPAN, don't know what it is.
Try the command

i /Bundle::CPAN/

to find objects with matching identifiers.

cpan> install Palm::PDB
Warning: Cannot install Palm::PDB, don't know what it is.
Try the command

i /Palm::PDB/

to find objects with matching identifiers.


I tried the command i/... that it suggested, and no luck. Anyone have any ideas on what I'm missing/doing wrong/can do to fix this?

Much appreciated,

Joanie

It seems to be available here at least:

http://search.cpan.org/~arensb/p5-Palm-1.3.0/Palm/PDB.pm

I probably have to put it into the distribution if it is removed from CPAN.

It seems to be available here at least:

http://search.cpan.org/~arensb/p5-Palm-1.3.0/Palm/PDB.pm

I probably have to put it into the distribution if it is removed from CPAN.

Weird, I used ppm.bat (Perl Package Manager) from my ActiveState Perl installation and saw:p5-Palm
Module for handling PalmOS databases
Version: 1.009
Author: brian d foy (bdfoy@cpan.org)
CPAN: http://search.cpan.org/dist/p5-Palm-1.009/



But the link doesn't exist. However, upon searching CPAN I came across http://search.cpan.org/~arensb/p5-Palm-1.3.0/, a recent update NOT:This Release p5-Palm-1.3.0 [Download] [B]07 Nov 2002
Latest Dev. Release p5-Palm-1.009_02 [Download] [B]21 Aug 2009
Other Releases p5-Palm-1.009_01 -- 15 Aug 2009


Look at the dates of these versions: 1.3.0 (07 Nov 2002) and p5-Palm-1.009_02 (21 Aug 2009). So something is amiss... :chinscratch:

Just use http://search.cpan.org/~bdfoy/p5-Palm-1.009_02/ for now.

But the 1.3.0 version is the lates released and the PDB.pm file in that is identical to the one installed by Debian packages.

I've just tried again, using the wiki instructions as before. It seems it was a temporary glitch in the CPAN database.

All installed and working again now.

I have just moved computer and I'm also having the same trouble reinstalling MobiPerl.

It seems that the Palm::PDB package is no longer available.

Help?

I'm having a problem with mobi2hml it explodes the mobi and I get the pictures and everything except that the html file is blank there is only this in the code

<html><head><meta http-equiv="Content-Type" content="text/html; charset=windows-1252" /></head><body></body></html>

I uploaded an image of what the program tells me.

Help please!

The usual reason for this is that there is some encryption in the file. I would test if Calibre or some ot the python script floating around can unpack it since I seem to remember that they handled more cases than MobiPerl.

The usual reason for this is that there is some encryption in the file. I would test if Calibre or some ot the python script floating around can unpack it since I seem to remember that they handled more cases than MobiPerl.

Might want to get the previous version of the MPerl, and see if you can run that without a hitch.

I've found a problem in MobiPerl 0.43, specifically in the mobi2html section. When run on a Mobipocket version 6 file that has the extra data flags set, it doesn't decode the text properly, as it doens't know to ignore the extra data at the end of each text record.

I've raised an issue on the mobiperl tracker, and attached my attempt at a fix, which is working for me but could probably be a lot neater because I don't really know Perl.

I found out about this while trying to fix a problem in a certain Mobipocket DRM removal script.

I've found a problem in MobiPerl 0.43, specifically in the mobi2html section. When run on a Mobipocket version 6 file that has the extra data flags set, it doesn't decode the text properly, as it doens't know to ignore the extra data at the end of each text record.

I've raised an issue on the mobiperl tracker, and attached my attempt at a fix, which is working for me but could probably be a lot neater because I don't really know Perl.

I found out about this while trying to fix a problem in a certain Mobipocket DRM removal script.

OK, will look at it when inspired. Is this an UTF-8 think är is this another extra data flag?

It's mysterious trailing entries as 'documented' here:

http://wiki.mobileread.com/wiki/MOBI#Trailing_entries

These are in addition to the UTF-8 multibyte character overlap issue, although it works from the same 16-bit Extra Data Flags field of the mobipocket header.

ONLY for mobipocket version 6 and above - I have seen MOBI headers of 0xE8 in length even in version 5 files, and in these the trailing data entries do not occur, and trying to process them will cause problems with some files.


OK, will look at it when inspired. Is this an UTF-8 think är is this another extra data flag?

Is the server down? the MobiPerl website does not respond so I cannot download the scritps...

Is the server down? the MobiPerl website does not respond so I cannot download the scritps...

It looks like it is down. The Window version is in a message a couple of pages up.

It's back up. We had to relocate the server on which dev is hosted. See the announcement here (http://www.mobileread.com/forums/showthread.php?t=85317). :)

OK, I was able to download MobiPerl but now the CPAN install of GD fails.

Are there requirements/restriction on the nature or size of the image you set the cover to? I downloaded a cover from the net and it looks about the right size. When I use mobi2mobi.exe to set the cover to the image I downloaded, it only updates the thumbnail - the actual cover image stays blank. Any ideas?

I actually do not remember. There is a flag for enabling or disabling reduction of size so you can test that. If you give me the image I can test it and see if I have the same problem.

I actually do not remember. There is a flag for enabling or disabling reduction of size so you can test that. If you give me the image I can test it and see if I have the same problem.
I've done a bit of experimenting...I don't think it's actually the image. It seems to be something wrong with the book itself. I've tried several images of varying sizes, and they all have the same problem with that book.

Hi,

Would it be possible to make html2mobi to fetch the images from the internet (i.e. if the image is referenced with an url)?

(I'm doing it now)

It is possible but I think Calibre handles html2mobi conversions better.

But feel free to extend the code and submit the changes.

The installation instructions only are for using Mac Ports.

I have Mac OSX 10.7 (Lion) which already has Perl 5.8.8

I'd prefer to just copy Palm and MobiPerl to whichever directory the default install of Perl expects to find it.

Where is this?

The installation instructions only are for using Mac Ports.

I have Mac OSX 10.7 (Lion) which already has Perl 5.8.8

I'd prefer to just copy Palm and MobiPerl to whichever directory the default install of Perl expects to find it.

Where is this?

There is no such thing. Perl doesn't expect to find stuff anywhere.

The directions tell you to use MacPorts because there are several CPAN modules needed that aren't by default on a Mac.

Of course you are welcome to not follow them.

BOb

Perl doesn't expect to find stuff anywhere.

Well, actually, the default install of Perl on Mac OS X expects to find stuff in /Library/Perl/[RELEASE NUMBER]* and you can copy-paste from a backup of that when reinstalling the OS after wiping your boot drive due to irreparable file system corruption, without having to go through the entire reinstalling all the CPAN modules once more to have MobiPerl up and running again.

But yeah, you first need the CPAN modules installed to begin with and you can do that either via MacPorts (in which case it all ends up in a different directory) or manually.

* You will get an error message if it doesn't.

You may want to check into Fink (http://www.finkproject.org/), as well. It can be used to get many non-standard Perl modules installed on OS X... and may be slightly less aggravating than MacPorts (depending on your personal preferences, of course)

fink install <modulename>-pm588

Well, actually, the default install of Perl on Mac OS X expects to find stuff in /Library/Perl/[RELEASE NUMBER]* and you can copy-paste from a backup of that when reinstalling the OS after wiping your boot drive due to irreparable file system corruption, without having to go through the entire reinstalling all the CPAN modules once more to have MobiPerl up and running again.

But yeah, you first need the CPAN modules installed to begin with and you can do that either via MacPorts (in which case it all ends up in a different directory) or manually.

* You will get an error message if it doesn't.

What I meant was.. there is no specific directory that you put perl scripts in that you want to run. You can run a perl script from any folder. Yes, perl expects its own libraries to be in a certain location, which I think you can specify with evn variables or a config file.

That all said, I guess I don't see the problem with using MacPorts. It makes it so much easier. What difference does it make what folder the stuff is in, if it works.

I got it all working pre the Mac Ports directions, and I think they are still on the wiki.. but now all the versions are different and what works on various versions of OS x are different. So, letting MacPorts take care of all the dependencies is much simpler.

BOb

Trying to change the titles on some mobi files and mobi2mobi isn't liking some of them, even though they work with Mobi reader on Windows and Kindle reader on Android.

The error I get is
bogus database name! is this really a PalmOS file? at Palm/PDB.pm line 537.

No, not a Palm file, especially not when it opens with the latest Kindle Reader app for Android which has broken PalmDOC support. (I've gone back to a slightly older version that's not as bloated and buggy.)

No, not a Palm file, especially not when it opens with the latest Kindle Reader app for Android which has broken PalmDOC support.
A mobi file is still part of a Palm db container.

Some Amazon ebooks no longer have a Palm db name... mobi2mobi chokes on that when trying to change the title. Just use mobi2mobi to give it a Palm db name first. Then change the title.

Hello Tombe and others,

I'm planning to release a Perl-Module on CPAN (the Perl Module-Archive) which uses parts of MobiPerls code. This means that the code in EXTH.pm, MobiHeader.pm and Util.pm would be released on CPAN. Since MobiPerl is published under the GPL3, I assume that there is no problem with that. Still I would like to announce my plans here so that people are aware and maybe point out some issues I have not thought about. I myself would like to get in contact with the author of MobiPerl (which seems to be the user 'tombe'), but I don't know how busy or interested he is (I can assure that the main work for the CPAN module is done, and I'm not interested in any contact because of technical questions).

One technical task which I have not yet solved is the fact that MobiPerl brings along its own copy of the Palm module which actually is on CPAN. As far as I know the reason for this is, because some changes to this module are made. It would be very nice if this changes could go to the official Palm module (if this makes sense), so that the design on CPAN would be more clean, meaning no local copy of the Palm module. If somebody (e.g. tombe) can give any advice in that I would be grateful.

Regards
Boris

Hello Tombe and others,

I'm planning to release a Perl-Module on CPAN (the Perl Module-Archive) which uses parts of MobiPerls code. This means that the code in EXTH.pm, MobiHeader.pm and Util.pm would be released on CPAN. Since MobiPerl is published under the GPL3, I assume that there is no problem with that. Still I would like to announce my plans here so that people are aware and maybe point out some issues I have not thought about. I myself would like to get in contact with the author of MobiPerl (which seems to be the user 'tombe'), but I don't know how busy or interested he is (I can assure that the main work for the CPAN module is done, and I'm not interested in any contact because of technical questions).


Sound OK to me. If you need to change the licence to something else just ask me. I have not big opinion about it being GPL3, GPL2 or some other similar licence.


One technical task which I have not yet solved is the fact that MobiPerl brings along its own copy of the Palm module which actually is on CPAN. As far as I know the reason for this is, because some changes to this module are made. It would be very nice if this changes could go to the official Palm module (if this makes sense), so that the design on CPAN would be more clean, meaning no local copy of the Palm module. If somebody (e.g. tombe) can give any advice in that I would be grateful.


Or you can just rename the modified Palm module. I actually do not remember why the changes had to be made. But the standard module did not work for some mobipocket files.

Hello Tombe and others,

One technical task which I have not yet solved is the fact that MobiPerl brings along its own copy of the Palm module which actually is on CPAN. As far as I know the reason for this is, because some changes to this module are made. It would be very nice if this changes could go to the official Palm module (if this makes sense), so that the design on CPAN would be more clean, meaning no local copy of the Palm module. If somebody (e.g. tombe) can give any advice in that I would be grateful.

Regards
Boris

One change that would be welcome to the Palm module is a built in function to swap Unicode and UTF-8 characters for their identical extended ASCII equivalents for output to Mobi format. For English text there's no reason at all to be using Unicode but there's a ton of HTML e-books using it, especially for punctuation.

Anyone who needs a substitution list, I have one. I also have a program someone wrote to do substitutions of text strings in any plain text file. It's a bit buggy, can only handle a certain number of swapping pairs in its list. I have the C# source code if someone wants it.