Image Lost During ODT > ePub Conversion

[Foothills]

I'm trying to debug a really annoying problem that happens consistently during my current ePub generation effort. I'm using OpenOffice 3.4.0 under OS X 10.7.4 and the latest calibre (0.8.64).

I create the document in Open Office and save it in .odt format
I open calibre, add the .odt to my library, and convert to ePub
I sync the result over to my iPad 2 running 5.1.1

The cover page works fine, the TOC works fine, the text all works fine, and the 'regular' photos inserted into the .odt as .jpg images are all OK - the problem is one diagram, also in .jpg format, that simply refuses to make the translation into the ePub file. These results are consistent whether I'm checking the file with the calibre viewer on the Mac or in iBooks on the iPad.

This diagram is inserted from the same directory as the photos, so it doesn't seem like some kind of path problem but who knows. It appears to healthy and happy when you view the .odt in OpenOffice.

The photos are quite large and the problematic graphic relatively quite small both in terms of pixel dimensions and file size. I can add a test photo (or photos) in the exact same place in the document with no problems.

Any ideas what might be different about this particular .jpg that might make it fail to convert?

Thanks in advance for any ideas ... or solutions!

[theducks]

Originally Posted by Foothills

Any ideas what might be different about this particular .jpg that might make it fail to convert?

Thanks in advance for any ideas ... or solutions!

What does the writer2EPUB plugin (for OO) do with this?

[DoctorOhh]

Originally Posted by Foothills

Any ideas what might be different about this particular .jpg that might make it fail to convert?

Was this the 1st image in your ODT? If so you may have the Remove first image box checked under Preferences - Common Options - Structure Detection.

Another option open the jpg in a image program such as Paint Shop Pro or Paint.net and save it as a png and use that file instead and see what happens. I believe there was a, for lack of a less ignorant word, rogue spec jpg at one point that just does not play well with some programs.

[Foothills]

Originally Posted by theducks

What does the writer2EPUB plugin (for OO) do with this?

It blows up. Literally. It churns for a while and then comes back with an error about a bad URL, even though there aren't any links anywhere in the document!

[Foothills]

Originally Posted by dwanthny

Was this the 1st image in your ODT? If so you may have the Remove first image box checked under Preferences - Common Options - Structure Detection.

I've tried it as the first, second, third, etc. but this jpg is always the image that fails.

Originally Posted by dwanthny

Another option open the jpg in a image program such as Paint Shop Pro or Paint.net and save it as a png and use that file instead and see what happens. I believe there was a, for lack of a less ignorant word, rogue spec jpg at one point that just does not play well with some programs.

This is what I'm going to do next once I get home. I'm on the road with a new MacBook Pro and don't have all of my usual tools with me. I too now suspect that there's something just off about the format of this JPG file even though I've done my best to launder it through iPhoto, etc. on this machine.

One other strange factoid - if I make this the only image in the doc and do NOT include a separate cover page the image is grabbed and used as the cover but doesn't appear in the text body. If I do include a separate cover the image doesn't appear at all.

For what it's worth I sent the complete .odt to Kovid via an official bug report and he was able to successfully process it into an ePub. Very odd - obviously something's different somewhere!!!

I'll report back once I've had a chance to re-work the JPG with PSP ...

Thanks to both of you that responded and to Kovid for checking out the bug!

[DoctorOhh]

If there is a place in OpenOffice 3.4.0 that allows you to designate the cover, could this image have been set with that attribute?

For lack of a more elegant solution you could try duplicating the jpg and putting the two images one page apart and see what survives.

[Foothills]

Well, the problem persists no matter what .jpg I insert in my .odt source and no matter what I do re: cover page selections. I've basically just surrendered and now insert a sacrificial image on the first page of my document that I know will simply get lost in translation ...

[DoctorOhh]

Originally Posted by Foothills

Well, the problem persists no matter what .jpg I insert in my .odt source and no matter what I do re: cover page selections. I've basically just surrendered and now insert a sacrificial image on the first page of my document that I know will simply get lost in translation ...

Submit a bug report.

[Foothills]

Already done as stated above - Kovid was not able to replicate the problem even with my original .odt file. Obviously there's some difference in the environments.

[jackie_w]

Another idea...can you save the odt file as html. If so you could examine the raw html in a text editor to see how the rogue image coding <img> looks compared to the rest.

Also, if you can save odt as html you could try importing the html to calibre, which will convert it to a zip with all the images. Then do a zip-to-epub conversion. Do you get a better epub?

[kovidgoyal]

Just checking the obvious, you dont have the remove first image option checked, do you?

[Foothills]

Originally Posted by kovidgoyal

Just checking the obvious, you dont have the remove first image option checked, do you?

No, it's not checked, but it's acting as if it were.

As part of this project I've had to do many many conversions of the same doc because of image-related problems (see my other post) and the behavior has been very consistent. I've verified that option is *not* checked each and every time. My "sacrificial" image is addressing the issue, though - what's really causing me a lot of work (and re-work) is the image size problem described in my other post.

[theducks]

Originally Posted by Foothills

No, it's not checked, but it's acting as if it were.

This setting can exist in many places:
Preferences is the place that is used For the First Ever Conversion (default) of that Book. Once the Book has been converted, the settings that were used, are stored with the books metadata(.db)
Any reconversion, will use the saved settings unless you click/tick the clear/restore (use the now current Preferences) defaults

So if you were just fixing Preferences, you would see no changes.

If you changed the setting on the Conversion Screen.. Those override the saved (or current preferences) values for that book only AND those will be the New saved (book) values