Closed Bug 3157 Opened 26 years ago Closed 20 years ago

Import (formerly imported) HTML messages from Eudora - seen as plain text, <x-flowed>, <x-rich>

Categories

(MailNews Core :: MIME, defect, P2)

Product:
MailNews Core
Component:
MIME
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
mozilla1.8beta1

People

(Reporter: ppandit, Assigned: mscott)

References

Details

(Keywords: fixed-aviary1.0)

Attachments

(4 files, 3 obsolete files)

1. Eudora dialog asking in what format to send (plain,styled, plain & styled)
35.05 KB, image/jpeg
Details
Actual Results: Eudora HTML message sent in plain, imports w/html tags (N6 & 4.7)
16.29 KB, image/jpeg
Details
Actual Results: Eudora HTML message sent in styled & plain, imports w/html tags (N6 & 4.7)
21.79 KB, image/jpeg
Details
the fix
8.06 KB, patch
Bienvenu
: superreview+
Details | Diff | Splinter Review
THE FOLLOWING IS A QUESTION I SENT TO TONY ROBINSON AFTER TESTING WITH 4.51: Hi Tony, Gotta a question concerning Eudora import/export and Messenger. I imported my Inbox from Messenger into Eudora. Then I imported from Eudora to Messanger. The original messages were composed in HTML. But when I imported them back from Eudora, they were basically text files containing HTML code/tags. Can we make Netscape's IMPORT feature convert it back into real HTML messages? Also, when I do a reply, the mail compose window comes up in HTML mode so I don't understand why these messages are not in HTML. Is this a limitation of Eudora? Thanks, Par
HERE IS TONY'S RESPONSE: It's a problem with the way Eudora stores HTML messages. It strips out the mime information that identifies the text as html and inserts some additional html style tags surrounding the message that eudora uses to indicate the text is html. The IMPORT tool is not currently smart enough to scan the body of the message and determine if it is HTML by looking for the eudora specific tags. It would also seem reasonable fot the Netscape mail viewer to recognize that a message identified as text/plain contains HTML and display as such. After all, it's pretty easy since the entire message is bracketed by <HTML> </HTML> I think? TR
HERE IS TONY'S RESPONSE: It's a problem with the way Eudora stores HTML messages. It strips out the mime information that identifies the text as html and inserts some additional html style tags surrounding the message that eudora uses to indicate the text is html. The IMPORT tool is not currently smart enough to scan the body of the message and determine if it is HTML by looking for the eudora specific tags. It would also seem reasonable fot the Netscape mail viewer to recognize that a message identified as text/plain contains HTML and display as such. After all, it's pretty easy since the entire message is bracketed by <HTML> </HTML> I think? TR
Status: NEW → ASSIGNED
Target Milestone: M7
Target Milestone: M7 → M12
Will the Import tools be cross platform? If so, I'll need to change the platform and OS to All.
I wouldn't make the change yet...I don't think we will be supporting all platforms initially. - rhp
Summary: Import (formerly imported) HTML messages from Eudora - seen as plain text → [PP] Import (formerly imported) HTML messages from Eudora - seen as plain text
Putting [PP] for now in summary.
Tony is not building his tools for Linux. I don't think this bug needs to be fixed for PR1.
Assignee: rhp → tonyr
Status: ASSIGNED → NEW
Target Milestone: M12 → M14
Tony we should fix the imported MIME type, not guess the MIME type from the message body.
Status: NEW → ASSIGNED
Keywords: pp
Summary: [PP] Import (formerly imported) HTML messages from Eudora - seen as plain text → Import (formerly imported) HTML messages from Eudora - seen as plain text
With the new import tools, this mostly works now. There are a few odd cases that I need to test though before I mark this fixed. This is only an issue for Eudora import on Win32 & Mac.
In all messages stored in Eudora 4.x's mailboxes (I'm not sure if this applies to 3.x) if it was a text/html file begins with <x-html> A message composed by Eudora will have an or <x-html> at the beginning of the message body. Pre-formatted or traditional text messages will either not have an <x-{}> tag or will be marked as <x-flowed> at the beginning of the body of the message. If the tags above can be detected on the message the "Content-type:" header in the new converted mailbox can be set to "text/html" and the mail program will properly display the message. This also fixes the appearance of all original and recieved messages to/from Eudora. I've done this manually using a text editor and it appears to work without any problems. I know this doesn't do well as a linear pass, but it does what it needs to do. I hope this helps.
Target Milestone: M14 → M17
Possibly if you could do a four or five line buffer to detect the <x-html> tag you could go back and set the Content-Type: text/html header if a Content-Type: header hadn't been detected for the current message. Once detected insert it in at the appropriate spot in the line buffer. ??? if it sounds (uhh.. ) Just a possible solution. From what I've been able to tell, it follows the format Status:{something}{newline}{newline}<x-html>{newline} format before the message. If a "Content-Type:" wasn't detected then you could insert it before at the front of the buffer before the "Status:" header and I think it would work. Just food for thought... :)
Import uses MsgComposeAndSend to create the imported message. This currently checks the preferences and will re-format any HTML mail to plain text if the preferences are set that way. Rich, is there any way we can get ComposeAndSend to ignore the preference and always compose using what was passed in?
Can't you set the nsIMsgCompFields argument to override the default pref? - rhp
Aha. You mean I should call SetTheForcePlainText( false) and that should cause any HTML passed in to remain HTML?
I would like to think so...but without trying it myself, I'm not sure. :-) - rhp
This is a simple 1 line fix, the same problem/fix exists for Outlook imported mail as well. This is all tested and ready to check in, should have no impact on anything else.
Keywords: nsbeta2
Putting on nsbeta2+ radar. Will become minus on 6/15.
Whiteboard: [nsbeta2+] 6/15
Woops, forgot to mark this fixed. Fix was checked in last week.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Download Eudora 4.3.2 (the latest according to www.eudora.com) and tried to import the messages from Messenger. The import tool within Eudora does not see any Netscape profiles (either 4.x or mozilla). Is there some trick to get it work to see our data? Par
Umm... This is a fix for Eudora messages imported into Mozilla, not the other way around.
I was redoing my original bug procedure. I'll try just the Eudora to Mozilla import.
pratik - when you get a chance, can you verify? You can get Eudora from their web site or we have the software in the lab 311 bookshelf.
QA Contact: ppandit → pratikd
I imported messages from Eudora 4.3.2 into NS 6 build 2000--07-13-08. For HTML messages, I still see html code/tags in the body of the message. Am I missing something ?
BTW I was using a commercial build 2000-07-13-08. I also tested on Mozilla build 2000-07-17-08, I still see the tags ! Tonyr: can you confirm your fix was checked in ? Thanks!~
reopening bug. i still see html tags when importing html messages from Eudora.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
removing from beta 2 radar
Whiteboard: [nsbeta2+] 6/15 → [nsbeta2-]
[SPAM] Adding myself to cc
QA Contact: pratikd → esther
QA Contact: esther → nbaca
Milestone 0.8 has been released. We should either resolve this bug or update its milestone.
Build 2001-02-26-09: NT4 Eudora 5.0.2 This appears to be working for me. I imported Eudora messages which included HTML messages. The messages look correct and I'm not seeing the html tags. Should I be testing any other versions of Eudora?
Target Milestone: M17 → ---
adding myself to the cc list.
Does not work for me. Messages composed with Eudora (imported) and other HTML documents are not viewed as HTML. <x-flowed> and <x-html> tags are visible as well as all other tags.
When Eudora pops a message and stores it, it strips the Content-Type: text/html header. Also, this is a result of the block copy of the Headers during the import process. See bug 73694 for some more discussion. The import may need (I recommend) parsing the headers and correcting them if need be. A quick scan of the body can find <x-flowed> and <x-html> tags that Eudora uses to denote HTML and then append a header of (Content-Type: text/html) if necessary.
*** Bug 111662 has been marked as a duplicate of this bug. ***
Marking nsbeta1 because it makes reading imported html messages from Eudora difficult.
Keywords: nsbeta1
Whiteboard: [nsbeta2-] → [nsbeta2-],imp-mail
Blocks: 126322
*** Bug 64117 has been marked as a duplicate of this bug. ***
reassigning to cavin.
Assignee: tonyr → cavin
Status: REOPENED → NEW
The problem appears in Netscape 4.7 and Netscape 6, so it's been around for awhile. 1. This step is taken just to populate the Eudora Inbox. Create an HTML message in Eudora, send the message and a dialog asks what format should it send the message (Plain, Styled, Plain & Styled). There is no default for this dialog, the user has to choose. a. Send one message in plain b. Send a second message using styled c. Send a third message using plain & styled 2. Retrieve the messages in Eudora 3. Import Eudora Mail into N6 (or 4.7) Actual Results: This is how it appears in N6 (or 4.7) a. The message sent in "plain only" appears with html tags b. The message sent in "styled" looks good c. Message sent in "plain & styled" appears with html tags Screen shots to follow...
This is not restricted to Windows NT. It occurs on all flavors of Win32. I'm not sure that it would be fair to set the OS to ALL. Does this problem happen when Mozilla converts Eudora mailboxes under an Apple OS? If so, this should be classified as all OS's (at least for which Eudora is available.)
Discussed in Mail News bug meeting with Engineering, QA, Mktng and PjM. Decision was to minus this bug.
Keywords: nsbeta1 → nsbeta1-
Target Milestone: --- → mozilla1.2
Checked with Eudora 5.0-J on my japanese Mac OS 9. Same problem there. Changed the platform to all.
Hardware: PC → All
*** Bug 183454 has been marked as a duplicate of this bug. ***
*** Bug 150695 has been marked as a duplicate of this bug. ***
I have seen this bug in Eudora Lite 5.1 also.
I'm experiencing this bug on Mozilla 1.3a. Imported from Eudora 5.1. Windows 2000
I have still about 2 years of mail in Eudora format and until now I did not succeed to convert them to Mozilla. I tried to import them to Outlook Express 6 and then from OE6 to Mozilla. The HTML issue was then more or less solved, but many mails had the wrong date. I abandoned my testing but if somebody is working on this bug and interested, I can do more investigation.
The date issue after going from Eudora -> OE6 -> Mozilla Mail 1.3a has been verified. Moreover, while some HTML messages were fixed, many of the messages still had <x-flowed> tags, and some still had unrendered HTML for whatever reason.
Re: comment 10 (and 9, 31) >Possibly if you could do a four or five line buffer to detect the <x-html> tag >you could go back and set the Content-Type: text/html header if a Content-Type >header hadn't been detected for the current message. (...) That seems to be a good solution, at least by hand, if we apply this to the Mozilla mailboxes after importing from Eudora, to avoid dealing with some "Content-Type: multipart/..." headers in Eudora that disappear in Mozilla in the frequent case that they had only one part in reality in Eudora. (Anyway this would be easy to detect given that the MIME multipart boundary is declared in header but not used in the message body in those cases). If, after the headers and a blank line, the first line of the message body is "<x-html>" (or "<html>" in sent messages), and there is not a "Content-Type" header, then it seems enough to add "Content-Type: text/html" to the headers to fix this bug, at least in the cases that I've seen. The situation is: ["From " line of start of message] [header lines here, ending with a blank line] <x-html> (or <html> as the first line of body) [body of message] If there is not a "Content-Type" header, then the line "Content-Type: text/html" can be added for example at the end of the headers, before the blank line and <x-html> or <html>. Very simple, and it works: ["From " line of start of message] [header lines here, ending with a blank line] Content-Type: text/html <x-html> (or <html> as the first line of body) [body of message]
I see this on mac os x, so noting all. clearing TM, 1.2 is long gone.
OS: Windows NT → All
Summary: Import (formerly imported) HTML messages from Eudora - seen as plain text → Import (formerly imported) HTML messages from Eudora - seen as plain text, <x-flowed>
Target Milestone: mozilla1.2alpha → ---
The bug can still be seen in Mozilla 1.4 and Thunderbird 0.3 - unlike bugs in nature, this certainly doesn't seem to disappear with old age... Mail sent by Outlook Express 6 HTML-formatting or Outlook with Microsoft Word 10 rich-text-formatting causes <x-html> wrapping around the <html> stuff, making Mozilla show the html code instead of a rendered page. There is one freeware utility, Eudora Mailbox Cleaner, that solves this problem on Mac OS X - see: http://homepage.mac.com/aamann/Eudora_Mailbox_Cleaner.html Perhaps the author would be willing to share some of his code?
See also the following utilities: eud2mbox (http://www.jjminer.org/eud2mbox/ - perl script, loses attachments, solves x-flowed etc), CEIConvert (http://www.timcoston.com/linux/index.php - perl scripts, loses attachments, doesn't handle non-us-ascii on the subject line, doesn't handle x-flowed etc.) and eudora2unix (http://eudora2unix.sourceforge.net/ - python scripts, doesn't handle non-us-ascii, keeps attachments).
The script can be used for post-processing a mailbox imported from Eudora, and demonstrates a quite simple solution that could form the basis of a proper fix in Mozilla itself.
For those interested, I've also developed a script that seems to resolve this issue (for me at least). It was tested using ActivePerl version 5.6.1.633, importing to Mozilla Thunderbird 0.3, and exporting from Eudora 5.2.0.9, all in a Windows XP "DOS" environment. Just place it in your directory and watch it go. It was for the most part flawless. There are no parameters to set. Be sure to back up your directory (the one you will run this script in) just in case. It worked for me and may be useful for anyone else with similar problems to mine. This Perl script was meant to be used after you have already used Thunderbird to import your Eudora email. Any questions or comments (bugs?), please let me know. Syntax: perl replace.pl Download it here: http://www.mbdatadesign.com/replace/replace.pl
i dont know how to run all these 'scripts' does this bug have any kind of priority? I'd really like to use Thunderbird rather than Eudora but this bug is frustrating enough to make me not want to switch.
You will need to download ActivePerl and place this script in your new Thunderbird directory (after using the import process from Eudora). This script will fix up what Thunderbird doesn't. But use at your own risk...create a backup of your new Thunderbird directory first. 1) Download ActivePerl here: http://www.activestate.com/Products/Download/Register.plex?id=ActivePerl 2) Install ActivePerl. 3) Save the Perl script to your new Thunderbird directory where your email is stored. 4) Type the following at the DOS prompt: perl replace.pl As a side note, remember that Thunderbird is still in the beta stages and WILL have bugs. But aside from a few of those issues, it is a great program.
Both of <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=3157#c53" title="Jan Frederik Solem's simple script">these</a> <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=3157#c54" title="Matt B's slightly flashier script">scripts</a> work for Mozilla 1.4, converting mailboxes imported from Eudora 6.0.1, in Windows ME. Importantly, with Matt B's script, I had to comment out the line: flock(OUTF, 2); because it led to a fatal error in WinME. According to the ActivePerl 5.6.1 documentation, it's a call that's only supported in WinNT (and apparently, XP as well). I have no idea if this line is important or not; I Am Not A Programmer, and this is the first time I've ever modified a perl script. All I know is, it works for me without that line, and it doesn't work with that line. Also, I had some trouble with both scripts as far as converting all of my largest mailbox, until I noticed that both scripts were breaking at a point where there were some nonstandard, undisplayable characters (rendered as boxes in MetaPad) in some emails from a travel agency in India. Once I deleted them, they worked fine. I think that it's something to keep in mind, though, once someone implements this in Mozilla.
*** Bug 201984 has been marked as a duplicate of this bug. ***
*** Bug 237307 has been marked as a duplicate of this bug. ***
FYI, I've changed servers and the replace script is now different. The new location is as follows: http://www.mbdatadesign.com/replace/replace.txt Please rename from replace.txt to replace.pl after downloading. - Matt.
This HTML import problem is causing a serious issue for me, especially since I'm wanting to migrate over 100 users to Thunderbird. Also, I'm not sure if anyone else has experienced this, but the converter isn't importing attachments when I experience this problem. I'm importing from Eudora 6.0.3 into Thunderbird 0.5 (20040207) on Windows 2000 SP4.
Eudora doesn't store the original MIME/BinHex attachment in the message, it strips them out of the .mbx file. I believe it does the same for embedded images in HTML messages. This would require a whole new level of functionality, although not too difficult. Maybe file an RFE bug to grab Eudora's attachments folder when doing an import.
This bug has been keeping me from fully converting to Thunderbird, and since I had some time this weekend I wrote a quick Java app to clean up my imported Eudora mailboxes (apologies to the Perl guy in this thread, I just didn't want to install ActivePerl). The utility only adds the proper headers and strips the Eudora x-flowed and x-html tags, it doesn't address the embedded image issues that others have pointed out. I've tested with several years of Eudora mail from two different users but would appreciate any feedback from others. Source code is available, feel free to modify. 1. Download the mountaininterval-mozilla-mail.jar file from http://www.mountaininterval.org/software.html#mozilla-mail. 2. Use the Mozilla File -> Compact Folders command to compact your existing mail folders. 3. Shutdown all Mozilla apps. 4. Backup your existing Mail directory. 5. From the directory that the jar file was downloaded into, type the command "java org.mountaininterval.apps.mail.MailGUI". 6. Select the folder to convert. 7. When the app is finished start Mozilla and verify mail was properly imported.
This patch adds a new function which looks for eudora special tags (x-folded and x-html). It removes them and return the content type accordingly (text/plain or text/html). This content type indication is used if no content type could be determined from the header (which happens for multipart mails from which eudora removes the content-type lines). This patchs enables HTML imported mail to be correctly displayed in Mozilla/Thunderbird. It also solves Bug 228149.
Remove an unused line from the previous patch.
I forgot to mention that this patch corrects only the eudora import process. HTML Mails already imported will not be fixed with this patch.
Regarding this: +static const char *TagContentType[] = { +"text/html;", +"text/html", +"text/plain;", +"text/plain;", +}; Are those last two entries supposed to be identical, or is [3] supposed to also have no semicolon, like [1] does? Or, oppositely, should [1] have a semicolon? You'll need to ask for a review on that patch; I'm CC'ing bienvenu who I hope knows a good candidate for reviewing it...
thx for doing this. Seems basically OK. A few comments: if (!bodyType.IsEmpty()) pMimeType = ToNewCString(bodyType); - + else + pMimeType = ToNewCString(m_bodyType); + this can be just something like: pMimetype = ToNewCString(bodyType.IsEmpty() ? m_bodyType : bodyType); re + "text/plain;", + "text/plain;", was the ';' intentional? Why is it required? Can you just remove the ';' here as well?: + bodyType = "text/plain;"; the should be an nsCAutoString, since it's going to be a short string. @@ -259,5 +259,6 @@ nsEudoraCompose compose; nsCString defaultDate; - + nsCString bodyType; + It looks like you have tabs in your patch - we don't checkin tabs, so either you could set your editor to put in spaces (we use 2 or 4 char indent - mostly 2), or I can fix it before I check in the final patch.
You're right for the ';', it's a cut'n paste mistake, it is not necessary. Concerning the string stuff, you sure must be right, I have quickly read the mozilla string guide but I didn't catch all. Can you also review the patch I proposed for Bug 242953, there are also some strings and I was not sure I took the good type (nor if my solution is the good one). For the tabs problem I would be glad if you could fix it for the final patch if you don't mind.
*** Bug 243382 has been marked as a duplicate of this bug. ***
Here is a python script that does PRE-conversion of Eudora mailboxes. It fixes most of the problems I've encountered when migrating mailboxes to Thunderbird. Read more here: http://www.gnist.org/~lars/code/eudora2mbox/eudora2mbox.html or download from here: http://www.gnist.org/~lars/code/eudora2mbox/eudora2mbox.py
Yann, I saw some review comments for your patch by David Bienvenu but I don't see a new patch that contains those changes. Can you please create a new up to date patch and then obsolete these other bug patches if they no longer apply? Thanks.
Assignee: cavin → mscott
Flags: blocking-aviary1.0?
<x-rich> also appears sometimes in Eudora mailboxes. Am updating the summary to reflect this.
Summary: Import (formerly imported) HTML messages from Eudora - seen as plain text, <x-flowed> → Import (formerly imported) HTML messages from Eudora - seen as plain text, <x-flowed>, <x-rich>
Attached patch the fix — — Splinter Review
Attachment #134823 - Attachment is obsolete: true
Attachment #148062 - Attachment is obsolete: true
Attachment #148063 - Attachment is obsolete: true
Comment on attachment 153462 [details] [diff] [review] the fix I took the existing patch, made it work with x-rich and took into account David's sr comments. David your ?: trick doesn't work here because bodyType and m_bodyType are different types. The compiler doestn' like that syntax...
Attachment #153462 - Flags: superreview?(bienvenu)
Comment on attachment 153462 [details] [diff] [review] the fix ah, ok - looks good.
Attachment #153462 - Flags: superreview?(bienvenu) → superreview+
fixed on the 1.0 branch and the trunk
Status: NEW → RESOLVED
Closed: 24 years ago → 20 years ago
Flags: blocking-aviary1.0? → blocking-aviary1.0+
Keywords: nsbeta1-, pp
Resolution: --- → FIXED
Whiteboard: [nsbeta2-],imp-mail → fixed-aviary1.0
Target Milestone: --- → mozilla1.8beta
On Mozilla 2004-07-17 Win32 trunk nightly build for the most part this patch works very well. In more than 95% of the cases, the conversion is works as intended. However in some (rare) cases (maybe x-rich only?), Eudora appears to store stuff as text/html without full html tags. For example (see below for source as converted by Mozilla): --- From - Mon Jan 1 00:00:00 1965 Date: Mon, 20 Jan 2003 23:40:09 -0600 Mime-Version: 1.0 Content-Type: text/html; charset=windows-1252 Message-Id: <CDE53309-2D02-11D7-9672-0030658A1192@uchicago.edu> X-Mailer: Apple Mail (2.551) X-UIDL: =Y+!!8pO"!$gD!!`?g"! Content-transfer-encoding: 8bit -- <fontfamily><param>Times</param>Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Phasellus sollicitudin, purus vitae tempus interdum, diam nunc dictum urna, sit amet pretium dui augue a sapien. Integer aliquet, mi non vulputate fringilla, tellus eros tempor tortor, vel tempus diam nisl ut felis. Phasellus tellus ligula, posuere eu, feugiat in, fermentum et, risus. Praesent interdum imperdiet wisi. Mauris pharetra, ante at convallis vestibulum, eros orci rhoncus orci, non consequat odio arcu a pede. Donec faucibus congue eros. Morbi vestibulum mi nec metus. Sed dapibus, wisi mattis fringilla tempus, orci nunc vehicula dui, id rutrum nisl tellus vitae elit. Suspendisse ultrices. Pellentesque et libero. Nullam neque. In sagittis risus vitae nunc. Vivamus posuere wisi sit amet ante. Nullam elementum magna eget tellus. Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Phasellus sollicitudin, purus vitae tempus interdum, diam nunc dictum urna, sit amet pretium dui augue a sapien. Integer aliquet, mi non vulputate fringilla, tellus eros tempor tortor, vel tempus diam nisl ut felis. Phasellus tellus ligula, posuere eu, feugiat in, fermentum et, risus. Praesent interdum imperdiet wisi. Mauris pharetra, ante at convallis vestibulum, eros orci rhoncus orci, non consequat odio arcu a pede. Donec faucibus congue eros. Morbi vestibulum mi nec metus. Sed dapibus, wisi mattis fringilla tempus, orci nunc vehicula dui, id rutrum nisl tellus vitae elit. Suspendisse ultrices. Pellentesque et libero. Nullam neque. In sagittis risus vitae nunc. Vivamus posuere wisi sit amet ante. Nullam elementum magna eget tellus. Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Phasellus sollicitudin, purus vitae tempus interdum, diam nunc dictum urna, sit amet pretium dui augue a sapien. Integer aliquet, mi non vulputate fringilla, tellus eros tempor tortor, vel tempus diam nisl ut felis. Phasellus tellus ligula, posuere eu, feugiat in, fermentum et, risus. Praesent interdum imperdiet wisi. Mauris pharetra, ante at convallis vestibulum, eros orci rhoncus orci, non consequat odio arcu a pede. Donec faucibus congue eros. Morbi vestibulum mi nec metus. Sed dapibus, wisi mattis fringilla tempus, orci nunc vehicula dui, id rutrum nisl tellus vitae elit. Suspendisse ultrices. Pellentesque et libero. Nullam neque. In sagittis risus vitae nunc. Vivamus posuere wisi sit amet ante. Nullam elementum magna eget tellus. Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Phasellus sollicitudin, purus vitae tempus interdum, diam nunc dictum urna, sit amet pretium dui augue a sapien. Integer aliquet, mi non vulputate fringilla, tellus eros tempor tortor, vel tempus diam nisl ut felis. Phasellus tellus ligula, posuere eu, feugiat in, fermentum et, risus. Praesent interdum imperdiet wisi. Mauris pharetra, ante at convallis vestibulum, eros orci rhoncus orci, non consequat odio arcu a pede. Donec faucibus congue eros. Morbi vestibulum mi nec metus. Sed dapibus, wisi mattis fringilla tempus, orci nunc vehicula dui, id rutrum nisl tellus vitae elit. Suspendisse ultrices. Pellentesque et libero. Nullam neque. In sagittis risus vitae nunc. Vivamus posuere wisi sit amet ante. Nullam elementum magna eget tellus. Sincerely, Housing & Dining Systems </fontfamily> --- The above email shows up in one really long, wrapped, line, because it thinks its HTML, but doesn't see any <p> or <br> tags. Other than this, the conversion process seems to work fine.
Thanks for having improved the patch ! Concerning the x-rich marker, I am not sure we should interpret it as a marker for html content. I thought it is some kind of rich text format, for example I saw the <smaller> marker in this kind of mail, which isn't a html marker, is it ? I didn't understand when Eudora generates theses RTF mails so I didn't handle this case (and it would be more complex to try to handle theses mails) Maybe it would be better to handle them as plain text since it would be more readable than a all-in-one-line mail.
*** Bug 254887 has been marked as a duplicate of this bug. ***
Keywords: fixed-aviary1.0
Whiteboard: fixed-aviary1.0
Re: comment #79: x-rich indicates that the content is of the type text/enriched. This is not the same as text/html. From what I can see, Thunderbird does display text/enriched correctly, so just changing the tag-to-type map should do the trick. Since this bug's already closed, I've submitted it as bug 257058.
*** Bug 224839 has been marked as a duplicate of this bug. ***
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: