GNOME Bugzilla – Bug 341258
Inline images act as external IMG tags
Last modified: 2011-05-11 13:07:09 UTC
Distribution: Fedora Core release 5 (Bordeaux) Package: Evolution Severity: normal Version: GNOME2.14.1 2.6.x Gnome-Distributor: Red Hat, Inc Synopsis: Inline images act as external IMG tags Bugzilla-Product: Evolution Bugzilla-Component: Mailer Bugzilla-Version: 2.6.x Description: Description of Problem: When inserting an inline image, the code creates an HTML <IMG> tag with src equal to the relative file path. It seems as if the option to insert an image is mixed up with what should be an option to add an image tag. Steps to reproduce the problem: 1. Create a new HTML message 2. Insert -> image -> select your image 3. Send message Actual Results: Open up the message on the recipient, and you'll get a red X. If you view source, you can see the <img> tag with a local filesystem source URL relative to the sender's machine, instead of a link to the missing mime encoded image Expected Results: an image, embedded in the email via mime How often does this happen? Every time. Additional Information: Possibly create 2 image options under the [insert] file menu selection. One for inline images, the other for external images (via http://etc...), or make it an option in the insert image dialog box ------- Bug created by bug-buddy at 2006-05-10 13:51 -------
Ubuntu bug about that: https://launchpad.net/distros/ubuntu/+source/evolution/+bug/51116 "Inline Image Attachment/Display - Evolution 2.6.1 The in-line image display used to be automatic now it's not working, when you used to add an image, it would reference the image in the html. Now in evolution 2.6.1, it display the image in the composer when you add it but the reference is for the local file so when the mail is received by the other party they can't see the image. I posted this on evolution mailing list and it appears to be a distribution specific issue. ... > Thanks for your bug. What do you mean by "The in-line image display used to be automatic now it's not working", that you have to click on the attachement to display it when you receive a mail? Do you have a pointer to that upstream discussion? We don't use a lot of patches for that package so it's likely to be an upstream issue ... When you try to insert an image on the composer window, it will display it, but it won't send it attached to the msg. Then I notice that the problem seems to be in the composer preferences, I have the forward style as inline and it doesn't attach the in-line image, if I change the forward style to attachment then it works well. In previous version it worked well in both forward styles so the behaviour has change. I posted this on evolution mailing list but it seems nobody is having issues with it, although the fact that I'm sending an image in a new message has anything to do with "forward inline style""
I also saw this behavior with a client. With forward style set to Attach or Quoted, it did not work (didn't try inline). I then looked at the generated HTML of the sent message, and found: <IMG SRC="file:///home/jim/T%20P%20P/E-Mail%20Heading/mailer_logo.png" ALIGN="bottom" BORDER="0"> I then suggested he try to move the image to his home directory (eg /home/jim/mailer_logo.png), and then it worked (Quoted attachment style-- didn't try the others). It seems that the spaces confused evolution, and it defaulted to 'file:///' rather than base64 encoded. Evolution 2.6.1 on Ubuntu Dapper
(In reply to comment #2) Thanks James - I can confirm, this is what's happening. I thought it was an issue with PNG versus JPG, but I didn't realize the PNG files I was inserting had spaces in their names.
I just tried to reproduce this with 3.0.1 and all works fine, using Insert->Image in a composer with HTML message format set attaches the image into the message and the generated IMG tag points into that attachment, as it should. I tried all variations, file name wand path without spaces, file name with spaces, path with spaces and nothing makes a difference.