Hi,

I bought couple of books from fictionwise yesterday and I cant read them on my cybook. I filled PID on website and downloaded them. When I try to open them on cybook it freezes and must be restarted. I get same result when I copy them using mobipocket reader.

Dictionary bought from mobipocket is working correctly.

I have older firmware in cybook not 538. Have anyone any suggestions other that to wait for new firmware and hope that this will be fixed in it?

Thanks in advance

Mota

Ask for new firmware or try to run "mobi2mobi --gen3imagefix --outfile new.mobi notworkingfile.mobi" on the files that are not working. The books probably have large images and you probably have triggered the bug related to this.

Thanks. mobi2mobi helped.

You can get build 538 by writing to bookeen and asking for it.

Ask for new firmware or try to run "mobi2mobi --gen3imagefix --outfile new.mobi notworkingfile.mobi" on the files that are not working. The books probably have large images and you probably have triggered the bug related to this.
When is mobi2mobi going to have a switch to not resize images since it seems that firmware 538 fixes the image size bug?

When is mobi2mobi going to have a switch to not resize images since it seems that firmware 538 fixes the image size bug?

I started using a modified 'html2mobi.exe' in PDFRead 1.8.2 that does not limit image sizes within the .prc. I caution Cybook Gen 3 users that images larger than 480x640 may crash their ereader. It seems that I should also tell them to get 'mobi2mobi' and apply the '--gen3imagefix' if that is the case until the firmware fix is applied by all.

By the way, do any Cybook Gen 3 users have issue with any of the HarryT Jane Austen Classics (http://wiki.mobileread.com/wiki/Jane_Austen_Classics_Available_at_MobileRead) in .prc format? Those use large images!

Make that Gen3 users with firmware 538. We know the original 1.0 firware has the image size bug for sure.

I
By the way, do any Cybook Gen 3 users have issue with any of the HarryT Jane Austen Classics (http://wiki.mobileread.com/wiki/Jane_Austen_Classics_Available_at_MobileRead) in .prc format? Those use large images!

The bug is not so simple that all large images are a problem.

When is mobi2mobi going to have a switch to not resize images since it seems that firmware 538 fixes the image size bug?

I have told you before. When there is an official fix from Bookeen.

But, nobody with 538 has said that large images are an issue and if they are, then they can always run mobi2mobi with it resizing to fix it.

But what I want is to be able to use mobi2mobi to fix the metadata where needed and if there are images, I don't want them possibly reduced in size. I don't want to have to check every mobi format eBook for possible images that might be resized.

What is the problem with putting in a switch to prevent image resizing? The default would be to resize and if anyone wants them not resized then that's ok too. The Gen3 is not the only implementation of a mobipocket reader. So please don't go by the bugs it has only. Give people the choice how they want things where possible.

But, nobody with 538 has said that large images are an issue and if they are, then they can always run mobi2mobi with it resizing to fix it.

But what I want is to be able to use mobi2mobi to fix the metadata where needed and if there are images, I don't want them possibly reduced in size. I don't want to have to check every mobi format eBook for possible images that might be resized.

What is the problem with putting in a switch to prevent image resizing? The default would be to resize and if anyone wants them not resized then that's ok too. The Gen3 is not the only implementation of a mobipocket reader. So please don't go by the bugs it has only. Give people the choice how they want things where possible.

I have explained my position before. MobiPerl is distributed as perl code so it is trivial to change if you need it. This is something I do in my spare time and the primary goal is to minimize support questions.

Trivial if you know pearl or have the time to learn what's needed to modify the code. I don't know pearl nor do I have the time to learn to modify it.

But I don't see what's the problem with my suggestion of a switch to not resize images and making the resizing the default. That would not impede anyones usage or any other programs that rely on it.

I started using a modified 'html2mobi.exe' in PDFRead 1.8.2 that does not limit image sizes within the .prc.

By the way, in line with tompe's previous request, my modified 'html2mobi.exe' is called and distributed as 'NRhtml2mobi.exe' until an offical fix is available. :2thumbsup

However, I have not added a switch for the '--gen3imagefix' so Cybook Gen 3 users will have to use 'mobi2mobi.exe' if the image crashing issue is present. This is my preferred solution.

Trivial if you know pearl or have the time to learn what's needed to modify the code. I don't know pearl nor do I have the time to learn to modify it.

But I don't see what's the problem with my suggestion of a switch to not resize images and making the resizing the default. That would not impede anyones usage or any other programs that rely on it.

Hey, Jon, did you create a new ticket for this on the Mobiperl Dev Hub? :D

Trivial if you know pearl or have the time to learn what's needed to modify the code. I don't know pearl nor do I have the time to learn to modify it.

But I don't see what's the problem with my suggestion of a switch to not resize images and making the resizing the default. That would not impede anyones usage or any other programs that rely on it.

What is pearl? I have exactly specified what you need to change in another place. If you do not want to modify it for you local need then do not modify it. But we have discused this before so why bring it up again.

I do not want people to put MobiPocket files with this problem on this site for example. The thing is that nearly all files with large images generated by MobiPerl has these problems but files generated with MobiPocket Creator with the same images generally do not have the problem.

The thing is that nearly all files with large images generated by MobiPerl has these problems but files generated with MobiPocket Creator with the same images generally do not have the problem.

tompe:

I had a similar problem when writing mobi2imp.pl where the resulting images would fail to show up in the ereader. What I did was, using GD, just copyResized the images but not actually resize them. What this did was rewrite the images using the GD library and those images would then load and show up properly. Maybe Mobipocket Creator does something similar, internally.

Sample code (you originally wrote this!) fixing this issue in mobi2perl.pl:sub fix_image_tags {
my $tree = shift;
my @imgel = $tree->find ("img");
foreach my $img (@imgel) {
my $recindex = $img->attr ("recindex");
my $ind = int ($recindex);
my $filename = $image_index_to_filename{$ind};
################################################## #################
#For .IMP start - just rewrite .jpg/.png/.gif image files (fixes non-stnd pics)
#
if (defined $opt_verbose || defined $opt_debug){ print "FIXED IMAGE/TAGS: $recindex - $ind - $filename\n"; }

my $imagefile = "$explodedir/$filename";
my $supportedimage = 0;
#my ($body,$path,$ext) = fileparse("$imagefile",'\.\w+');

my $im = $imagefile;
$im =~ /\.jpe?g$/i and $im = GD::Image->newFromJpeg($imagefile,1) and $supportedimage = 1;
$im =~ /\.gif$/i and $im = GD::Image->newFromGif($imagefile) and $supportedimage = 1 and $im->transparent(-1); #use only non-transparent .gifs;
$im =~ /\.png$/i and $im = GD::Image->newFromPng($imagefile) and $supportedimage = 1;
#$im =~ /\.bmp$/i and next; # not yet implemented in GD, but hopefully not needed here!

if ($supportedimage) {
my ($width, $height) = $im->getBounds();

my $target_im = new GD::Image($width,$height,1);
$target_im->copyResized($im,0,0,0,0,$width,$height,$width,$hei ght);

open(IMAGE, "> $imagefile");
binmode(IMAGE);
if ($imagefile =~ /\.jpe?g$/i){
print IMAGE $target_im->jpeg(85);
} elsif ($imagefile =~ /\.gif$/i) {
print IMAGE $target_im->gif();
} elsif ($imagefile =~ /\.png$/i) {
print IMAGE $target_im->png();
} #elsif ($imagefile =~ /\.bmp$/i) {
# print IMAGE $target_im->bmp();
#}
close(IMAGE);
}
#
#For .IMP end
################################################## #################
$img->attr ("recindex", undef);
$img->attr ("src", $filename);
}
}


Just a thought!

I have kind of tested this since I resized to different sizes to try to find if there was a limit. So just saving them again was not enough.

By the way, do any Cybook Gen 3 users have issue with any of the HarryT Jane Austen Classics (http://wiki.mobileread.com/wiki/Jane_Austen_Classics_Available_at_MobileRead) in .prc format? Those use large images!

They all work. Do you think I'd post a book for the Gen3 which didn't? :)

They all work. Do you think I'd post a book for the Gen3 which didn't? :)

Touche, I forgot that you have a Gen 3! :smack:

I have kind of tested this since I resized to different sizes to try to find if there was a limit. So just saving them again was not enough.

Ok we are getting somewhere!

Can you try creating a simple ebook (.html with a few large images known to crash the the Gen3) and produce a .prc with Mobipocket Creator and 'html2mobi.exe' with no resizing and compare the internals of the .prc? Obviously, there is something different.

It could be a database entry is missing, misinterpreted or the images are different. This would be a start.

Also, if you explode the two .prc's prepared above using 'mobi2html --rawhtml', and post the results here, I and others can help locating the source of this "bug"; be it firmware or mobiperl related.

Can you try creating a simple ebook (.html with a few large images known to crash the the Gen3) and produce a .prc with Mobipocket Creator and 'html2mobi.exe' with no resizing and compare the internals of the .prc? Obviously, there is something different.

It could be a database entry is missing, misinterpreted or the images are different. This would be a start.


Actually, I think I misstated or misremembered. For some reason the images I had as test cases caused problems. Bur when I took one of the problematic files and used mobigen the result was still a file that crashed the Cybook. So it might just be that the images I used was more problematic than images other people use in Mobipocket Creator. I can no longer test for this problem since I have updated the firmware.

I can't praise Fictionwise's customer service highly enough. Click thru to their support email and ask them for advice. I'm sure you will get a quick answer.

Actually, I think I misstated or misremembered. For some reason the images I had as test cases caused problems. Bur when I took one of the problematic files and used mobigen the result was still a file that crashed the Cybook. So it might just be that the images I used was more problematic than images other people use in Mobipocket Creator. I can no longer test for this problem since I have updated the firmware.

So to resolve this, why don't you offer your 'mobi2mobi' solution for Gen3 users with the old firmware and allow the switch to not resize for those users, like yourself, that have updated the firmware.

Obviously, i don't have a Gen3, but I do use mobiperl to create .prc and I too would not need the resizing.

Seems like a win-win to me. ;)

So to resolve this, why don't you offer your 'mobi2mobi' solution for Gen3 users with the old firmware and allow the switch to not resize for those users, like yourself, that have updated the firmware.

Obviously, i don't have a Gen3, but I do use mobiperl to create .prc and I too would not need the resizing.

Seems like a win-win to me. ;)

Why would people have to install MobiPerl programs just to read a file they have downloaded from some site?

Why would people have to install MobiPerl programs just to read a file they have downloaded from some site?

I thought that if a downloaded .prc file crashed the Gen3, then there was a solution that 'mobi2mobi --gen3imagefix' offers in that the images are resized and thereby allowing those Gen3 users to now properly use that file (that they downloaded elsewhere and maybe was created by others using say mobigen). I believe the original poster above found this solution useful.

I personally don't use .prc files, but I would like to generate them for others to use. I have installled my own work-around so for me it's a moot point.

However, your MobiPerl suite of programs, by default, resize images, even if the .prc file has no issues displaying on the Gen3 or any other ereader supporting this Mobipocket format. Imagine the (poor) iLiad user that has a 768x935 screen and it only shows 480x640 images!

I guess, the only ones that would have to install mobiperl, now, would be those Gen3 users that have not updated their firmware.

Time will tell what is truly needed here (or not)!