Win7: Images neither shown in preview mode nor pdf export

Bug #663944 reported by Stefan Meir
20
This bug affects 3 people
Affects Status Importance Assigned to Milestone
RedNotebook
Fix Released
Undecided
Jendrik Seipp

Bug Description

Running the German version of RedNotebook 1.1.1 under Windows7 images neither show up in preview mode nor in exported pdf files.
Exported html is fine and shows all images.

Revision history for this message
Stefan Meir (spamtostefan) wrote :
Revision history for this message
Jendrik Seipp (jendrikseipp) wrote :

Hmm that's odd, because exported PDF and HTML files should be identical. Can you post some example text, where the image does not show up and the resulting exported html?

Changed in rednotebook:
status: New → Incomplete
Revision history for this message
Jendrik Seipp (jendrikseipp) wrote :

Strange thing is: Image preview is working on my setups (winxp and win7). I am not sure how to fix this issue. Does anyone have an idea?

Maybe someone can try to open the exported html file containing a picture that doesn't show up in the preview with Midori (http://www.twotoasts.de/index.php?/pages/midori_summary.html). This browser uses webkit, just like RedNotebook does.

Revision history for this message
Bob Paulson (bpaulson) wrote :

I just opened an html file exported from RedNotebook 1.1.2 in Midori 0.2.6 and the images display fine. (Using RN English and WinXP SP3 German.)

I looked at the html code for an image and it looks like this:

<img align="middle" src="file://E:\My Dropbox\My Pictures\Canon PS A710 IS\E-mail\201010 USA\Dinner at Bookstore small.jpg" border="0" alt=""/>

This displays fine in Midori as mentioned above. I then inserted this code into RedNotebook 1.1.2 with double single quotes, like this:

''<img align="middle" src="file://E:\My Dropbox\My Pictures\Canon PS A710 IS\E-mail\201010 USA\Dinner at Bookstore small.jpg" border="0" alt=""/>''

And when i hit Preview, the same problem arises as with the normal RedNotebook markup of

[""file://E:\My Dropbox\My Pictures\Canon PS A710 IS\E-mail\201010 USA\Dinner at Bookstore small"".jpg]

No image is displayed, just that little box signifying something like file not found, I think.

Are both Midori 0.2.6 and RedNotebook using the same version of webkit? So why does it work on your winxp and win7 setups and not on ours? Something is obviously different, but what? Any way to start some debug mode and see exactly what is happening?

[Just curious, why does RedNotebook have the double quotes before the .jpg file extension? If I move them to be after the .jpg as in the html code, then the code is not interpreted (as per your 1.1.2 documentation for unparsed text). Otherwise you won't see what's inside the brackets?]

Same problem on my netbook, running WinXP English. I'll try it later on my wife's Vista system.

Revision history for this message
Bob Paulson (bpaulson) wrote :

I installed RN 1.1.2 on our Vista system and got the same problem when trying to display images with Preview.

Revision history for this message
Jendrik Seipp (jendrikseipp) wrote :

Thanks for trying it out. Could you maybe try inserting a picture that does not have whitespace in its path? And maybe you could also try removing the "file://" from the beginning of the pathname for an image without whitespace.

The "" around the filenames is a txt2tags (http://txt2tags.sf.net) quirk. This is needed for referencing images with absolute pathnames.

There is no direct way to debug the html rendering. The only option would be to download the webkit package from http://opensourcepack.blogspot.com/2009/12/pywebkitgtk-windows-binary.html (bottom of the page, needs linked gtk package) and see if the included demo browser loads the exported html fine or what the error messages are.

Probably a better and easier option would be to run depends.exe (http://www.dependencywalker.com/) and see if there are any dlls missing etc. To do that, start depends.exe, run rednotebook.exe inside of it and see if anything is missing. Then preview a picture and see what the dll import log shows.

You're right, there has to be a difference between our setups, but I don't know what it could be. Maybe depends.exe can tell us.

Revision history for this message
Stefan Meir (spamtostefan) wrote :

I just created a totally fresh journal on my Win7 machine and in this new journal images are correctly displayed in preview mode!

This made me more than curious, I did some testing and finally found out what's going wrong (on my machine): RedNotebook only displays images that are on hard disc C. As in my old journal all images were located in a folder on a different hard disc those images were not displayed in preview mode. After copying everything on hard disc C everythings works fine (for me).

Bob, does this help on your machines? (you also don't seem to have your images on hard disc C)

Revision history for this message
Bob Paulson (bpaulson) wrote :

(Reply from e-mail didn't show up (yet?) so here it is again:

I tried one without whitespace, [""file://E:\TempBobby\AnnaS"".JPG], same problem. Removed the "file://", [""E:\TempBobby\AnnaS"".JPG], same problem.

Will try depends.exe.

Revision history for this message
Bob Paulson (bpaulson) wrote :

With depends.exe, it complains about three missing modules when I open RedNotebook.exe:

EFSADU.DLL
IESHIMS.DLL
WER.DLL

After I start the program (I used Start Profiling with no arguments), it found one more:

ZLIB.PYD

Screen shot attached.

Revision history for this message
Bob Paulson (bpaulson) wrote :

Stefan, yes, if I copy an image to the C: drive then the preview works, thanks!

Jendrik, hope this helps. Don't really want to have user data on my C: drive. :-)

Revision history for this message
Bob Paulson (bpaulson) wrote :

...and export to PDF also displays the image if it is on the C: drive.

All three machines I tested on have the same setup: System on C:, User stuff on E:, so got same results everywhere.

Revision history for this message
Jendrik Seipp (jendrikseipp) wrote :

Bob: The errors in depends.exe are expected.

Stefan: Thanks for your discovery! This seems to be a problem of the webkit policy. It probably doesn't trust files on other drives. I guess we'll have to look if there's a setting to change that behaviour.

Changed in rednotebook:
status: Incomplete → Confirmed
assignee: nobody → Jendrik Seipp (jendrikseipp)
Revision history for this message
Bob Paulson (bpaulson) wrote :

I inserted a picture from the C: drive and then changed in the resulting RedNotebook code the drive letter to E:, or Q:, or XYZ: or whatever, including no drive letter. Hitting Preview causes the image to be displayed every time; it apparently doesn't look at the drive letter. As long as the image exists in the designated path on the C: drive, it doesn't care what drive letter is given.

Since I could display images from the E: drive with html in Midori, which uses webkit, it must be possible to do that.

Revision history for this message
Jendrik Seipp (jendrikseipp) wrote :

I have contacted the author of the compiled webkit versions, let's see what he thinks...

Revision history for this message
Jendrik Seipp (jendrikseipp) wrote :

Apparently this is a webkit issue. I have reported it here: https://bugs.webkit.org/show_bug.cgi?id=50416

Revision history for this message
Jendrik Seipp (jendrikseipp) wrote :

I just fiddled around with some dlls and suddenly it works when I write file:/// with three slashes insteas of just two. Does that work for you guys, too? It seems however that only jpgs work, pngs don't.

Revision history for this message
Bob Paulson (bpaulson) wrote :

Yes, it works for me with three /// slashes. I tried this with jpgs only.

Revision history for this message
Jendrik Seipp (jendrikseipp) wrote :

Nice. I changed the inserting behaviour and will release an updated beta soon.

Changed in rednotebook:
status: Confirmed → Fix Committed
Changed in rednotebook:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.