Mobiperl Mobiperl - Perl tools for handling MobiPocket files

[tompe]

Originally Posted by JSWolf

Burt for those of us using your software so we can do a conversion from Mobipocket format or not using a Gen3, the rescaling is not needed. Can you make an option to not rescale?

The rescaling is not done when going from MobiPocket to something else. The rescaling is only done when generating MobiPocket files.

[wallcraft]

Originally Posted by nrapallo

Just a note, I use your 'opf2mobi' to convert .html with images of default size 520 x 640 (in a .opf) to .prc as output from my PDFRead 1.8.1 conversion software.

I think the images are being limited in size somehow and result in a large white border (wasted space!).

One option would be to use mobigen instead, although it is for Windows only.

[JSWolf]

Originally Posted by tompe

The rescaling is not done when going from MobiPocket to something else. The rescaling is only done when generating MobiPocket files.

So if I use Mobi2mobi to fix metadata and there are images, does that cause images to maybe be rescaled? What if I was reading on Mobipocket Reader or an iLiad? I would not want the images rescaled. As I don't have a Gen3, and if I ever did get a portable reader that handled Mobipocket format, there would be no image size bug, can you make image sizing an option and default to off?

[tompe]

Originally Posted by JSWolf

So if I use Mobi2mobi to fix metadata and there are images, does that cause images to maybe be rescaled?

No. Or only if you give a flag to fix images.

What if I was reading on Mobipocket Reader or an iLiad? I would not want the images rescaled. As I don't have a Gen3, and if I ever did get a portable reader that handled Mobipocket format, there would be no image size bug, can you make image sizing an option and default to off?

NO! It is idiocy to make a tool that produces files you know crashes on a reader if you are not paid to get a lot of support issues. Feel free to create a binary "onlyforiliadreader-html2mobi" if you want but do not call it "html2mobi".

[nrapallo]

Originally Posted by tompe

NO! It is idiocy to make a tool that produces files you know crashes on a reader if you are not paid to get a lot of support issues. Feel free to create a binary "onlyforiliadreader-html2mobi" if you want but do not call it "html2mobi".

That is why a flag (--noresize) would be useful here. Instead of setting $rescale_large_images = 0, recompiling the code and creating a 'different' version say "Nicks_html2mobi", the flag is read at execution time and performs the rescaling (or not). Also, this would have to be re-done for each release and for each person's version!

Please reconsider. I know you only produce for your Cybook, but others, like me, have found your software useful and would like to create .prc for other devices as well.

[JSWolf]

Originally Posted by nrapallo

That is why a flag (--noresize) would be useful here. Instead of setting $rescale_large_images = 0, recompiling the code and creating a 'different' version say "Nicks_html2mobi", the flag is read at execution time and performs the rescaling (or not). Also, this would have to be re-done for each release and for each person's version!

Please reconsider. I know you only produce for your Cybook, but others, like me, have found your software useful and would like to create .prc for other devices as well.

Very well said. Thank you.

[HarryT]

Is the problem with large images still present in firmware v538, Tommy?

[tompe]

Originally Posted by nrapallo

That is why a flag (--noresize) would be useful here. Instead of setting $rescale_large_images = 0, recompiling the code and creating a 'different' version say "Nicks_html2mobi", the flag is read at execution time and performs the rescaling (or not). Also, this would have to be re-done for each release and for each person's version!

Please reconsider. I know you only produce for your Cybook, but others, like me, have found your software useful and would like to create .prc for other devices as well.

I can think about it but the problem is that html2mobi then can be used to create files that are known to fail on some devices. Then somebody creates such files and put them on archieves and not telling that they can be problematic. Especially since I had the problem with nearly all files I generated with too large images.

I do not feel like prioritizing the Cybook. I just feel that the files should work on as many devices as possible.

[tompe]

Originally Posted by HarryT

Is the problem with large images still present in firmware v538, Tommy?

Maybe not but I only tested one file know to have the problem and it worked so it is hard to know. But when there is an official firmware updated I will change the default and maybe have a flag for the old behaviour.

[nrapallo]

Originally Posted by tompe

Maybe not but I only tested one file know to have the problem and it worked so it is hard to know. But when there is an official firmware updated I will change the default and maybe have a flag for the old behaviour.

Thank-you!

p.s. I tried this for html2mobi and opf2mobi:

I tried my $rescale_large_images = 0; in Util.pm, but still got max. 480 widths. Then I noticed in Util.pm

sub get_image_data {
    my $filename = shift;
    my $rescale = shift;

    $rescale_large_images = $rescale if defined $rescale;

and wanted to pass $rescale of 0. For the flag to work, I tried changing in MobiFile.pm

my $data = MobiPerl::Util::get_image_data ($filename);

to

my $data = MobiPerl::Util::get_image_data ($filename, $resize_flag);

where $resize_flag is set 0 for non-Cybook .prc but still got max. 480 widths.

I'm stumped! Where else is it being resized?

[tompe]

Strange, what command did you run? Did you check the input so the images are really larger?

[nrapallo]

Originally Posted by tompe

Strange, what command did you run? Did you check the input so the images are really larger?

Nevermind, the original images where not larger (as you said); just tested it again and it does preserve the larger images!

Funning, I resized the original images in IrfanView and they didn't resize. Now I've got my own gremlins to figure out!

Here's to a fix soon...

[Jellby]

Pardon me if this has been already discussed, I've searched the web but I haven't read the whole of this thread.

I'm generating an HTML file manually, and I would like to convert it to mobi/prc format with html2mobi. I generated a table of contents in the HTML file by using "<a name=...>" and "<a ref=...>" tags. I haven't yet tried this on my Cybook, but when I convert back the mobi file to HTML with mobi2html, the links don't work (as they are "href=000000000"). According to the README, my mobiperl is 0.0.37.

The other thing is, is there a way to generate the links to "table of contents", "start reading" and similar things some mobipocket files have? I've seen they are inside a "<guide>" element when exploded to HTML, but they seem to include file offsets, which would be hard to write manually...

[tompe]

Originally Posted by Jellby

I'm generating an HTML file manually, and I would like to convert it to mobi/prc format with html2mobi. I generated a table of contents in the HTML file by using "<a name=...>" and "<a ref=...>" tags. I haven't yet tried this on my Cybook, but when I convert back the mobi file to HTML with mobi2html, the links don't work (as they are "href=000000000"). According to the README, my mobiperl is 0.0.37.

Strange. You should test your prc file with FBReader or Mobireader or the Cybook to see that the links really work to confirm that your html is correct. It should work converting back.

The other thing is, is there a way to generate the links to "table of contents", "start reading" and similar things some mobipocket files have? I've seen they are inside a "<guide>" element when exploded to HTML, but they seem to include file offsets, which would be hard to write manually...

I think you have to use opf2mobi and have the items you want in the guide element in the opf file. The offset will be computed automatically I think. I was a long time since I implemented this and I kind of do not remember exactly what I implemented...

[Jellby]

Originally Posted by tompe

Strange. You should test your prc file with FBReader or Mobireader or the Cybook to see that the links really work to confirm that your html is correct. It should work converting back.

Well, now I've tried with Mobireader and with the Cybook, and indeed the links don't work. I think my HTML doesn't have anything strange, I have things like:

<A HREF="#780619">19</A>
...
<A NAME="780619">19/06/1978</A><BR>

I think you have to use opf2mobi and have the items you want in the guide element in the opf file. The offset will be computed automatically I think. I was a long time since I implemented this and I kind of do not remember exactly what I implemented...

Hmm... but how do I create the opf file? Or better, what are opf files? (what is their format? are they text files? can they be easily created from HTML?) I'm using Linux, by the way, so Windows-only tools are of no use to me.