Closed Bug 743950 Opened 13 years ago Closed 13 years ago

html mail with embedded png, is not displayed correctly (emacs, reference to Content-Type: multipart/mixed part)

Categories

(Thunderbird :: General, defect)

11 Branch
x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: oub.oub.oub, Unassigned)

References

(Blocks 1 open bug, )

Details

(Keywords: testcase)

Attachments

(3 files)

Attached file test-mime-xemacs-org.eml (deleted) —
User Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.16) Gecko/20101206 SeaMonkey/2.0.11 Build ID: 20101206150522 Steps to reproduce: Hello I am using Kubuntu 10.04 and tried tested the following problem in TB 11, 12 and 13. Thunderbird has a extension called latexit, which allows to convert LaTeX math formula into png and then to embed them into a html mail. The resulting mail is correctly displayed in GMail. So far so good. Now a different email reader (gnus & (X)emacs) has the same feature and the resulting email is correctly displayed in Gmail, in the Ipod, Apple Mail on the Mac, a web based email programm provided by Sun. Actual results: the png are displayed as attachments Expected results: the png should have been displayed inline. I am not sure whether it has to do with the mime attachment Content-type: multipart/alternative; Or the html presentation. I only can attach one file for the moment, so I don't attach the eml generated by latexit.
This is a eml in which the math formula are displayed correctly, while in the other eml the png are only displayed as attachments.
Attachment #613539 - Attachment mime type: application/octet-stream → text/plain
Attachment #613540 - Attachment mime type: application/octet-stream → text/plain
That's the opposite case of bug 674473. Here, the message has a multipart/mixed structure at the top with "cid:" references to the image/png part which is inside that structure (the text/html part is correctly in a multipart/alternative but there is no multipart/related; both images are in the multipart/mixed context). Also, the images have a "Content-Disposition: attachment", both reasons to show them as attachment as Thunderbird does it. Now it seems that Gmail completely ignores multipart/related vs. mixed and simply takes the reference regardless of that context, which would explain what you see. Strictly speaking, the message is incorrectly formed. Please file a bug with Emacs, the latexit structure appears to be correct.
Well, I changed the line Content-Disposition: attachment; to Content-Disposition: inline; and reopened the eml file and still thunderbird does not display it correctly. in order to send a report to emacs, what should the correct syntax be, the one of latexit? I already mentioned that topic on the Gnus (Emacs) list, with both eml as an example, but the maintainers did not agree that there way of contruction mulitpart mime was incorrect. Also Apple Mail displays the message in the way Gmail does. What would be the problem if thunderbird would do the same "liberal" interpretation of mime messages?
Hello I just changed the emacs settings, now Content Type is inline but again the resulting message is not displayed correctly. I attach the file.
Attached file Content Type: inline (deleted) —
Attachment #613576 - Attachment mime type: application/octet-stream → text/plain
The "inline" disposition covers one part only, most importantly the top-level MIME header Content-Type: multipart/mixed; boundary="=-=-=" would have to be changed to Content-Type: multipart/related; boundary="=-=-=" for the message to be correct.
Summary: html mail with embedded png, is not displayed correctly Content-Type: multipart/mixed; latexit math formula. → html mail with embedded png, is not displayed correctly (emacs, reference to Content-Type: multipart/mixed part)
> multipart/related; boundary="=-=-=" for the message to be correct. You are right! Thanks! Ok I will again write to the emacs mailing group.
You can refer them to the RFC 2387 specification which describes the correct embedding of media types.
Uwe, has this been resolved with the emacs developers? Or, is there any indication that something yet has to happen in this specific report?
Hello sorry for my delay: yes this issue has been discussed on the emacs list, and thanks to your suggestions/explanations a solution was finally at hand.So I can confirm that with the modified emacs code, embedded (math formula) png are displayed correctly in TB and seamonkey 2.X
Thanks, I'm hence resolving this as a 3rd-party problem (->"invalid") given that emacs produced some incorrect code. If someone thinks that we should catch this case anyway, feel free to reopen this bug with respective supporting statements.
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: