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)
MailNews Core
MIME
Tracking
(Not tracked)
RESOLVED
FIXED
mozilla1.8beta1
People
(Reporter: ppandit, Assigned: mscott)
References
Details
(Keywords: fixed-aviary1.0)
Attachments
(4 files, 3 obsolete files)
(deleted),
image/jpeg
|
Details | |
(deleted),
image/jpeg
|
Details | |
(deleted),
image/jpeg
|
Details | |
(deleted),
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
Updated•26 years ago
|
Status: NEW → ASSIGNED
Updated•26 years ago
|
Target Milestone: M7
Updated•25 years ago
|
Target Milestone: M7 → M12
Will the Import tools be cross platform? If so, I'll need to change the
platform and OS to All.
Comment 4•25 years ago
|
||
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
Tony is not building his tools for Linux.
I don't think this bug needs to be fixed for PR1.
Tony we should fix the imported MIME type, not guess the MIME type from the
message body.
Updated•25 years ago
|
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.
Comment 9•25 years ago
|
||
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.
Comment 10•25 years ago
|
||
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... :)
Comment 11•25 years ago
|
||
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?
Comment 12•24 years ago
|
||
Can't you set the nsIMsgCompFields argument to override the default pref?
- rhp
Comment 13•24 years ago
|
||
Aha. You mean I should call SetTheForcePlainText( false) and that should cause
any HTML passed in to remain HTML?
Comment 14•24 years ago
|
||
I would like to think so...but without trying it myself, I'm not sure. :-)
- rhp
Comment 15•24 years ago
|
||
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
Comment 16•24 years ago
|
||
Putting on nsbeta2+ radar. Will become minus on 6/15.
Whiteboard: [nsbeta2+] 6/15
Comment 17•24 years ago
|
||
Woops, forgot to mark this fixed. Fix was checked in last week.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 18•24 years ago
|
||
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
Comment 19•24 years ago
|
||
Umm... This is a fix for Eudora messages imported into Mozilla, not the other way
around.
Reporter | ||
Comment 20•24 years ago
|
||
I was redoing my original bug procedure. I'll try just the Eudora to Mozilla
import.
Comment 21•24 years ago
|
||
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
Comment 22•24 years ago
|
||
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 ?
Comment 23•24 years ago
|
||
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!~
Comment 24•24 years ago
|
||
reopening bug. i still see html tags when importing html messages from Eudora.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 26•24 years ago
|
||
[SPAM] Adding myself to cc
Updated•24 years ago
|
QA Contact: esther → nbaca
Comment 27•24 years ago
|
||
Milestone 0.8 has been released. We should either resolve this bug or update its
milestone.
Comment 28•24 years ago
|
||
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?
Updated•24 years ago
|
Target Milestone: M17 → ---
Comment 29•24 years ago
|
||
adding myself to the cc list.
Comment 30•24 years ago
|
||
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.
Comment 31•24 years ago
|
||
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.
Comment 32•23 years ago
|
||
*** Bug 111662 has been marked as a duplicate of this bug. ***
Comment 33•23 years ago
|
||
Marking nsbeta1 because it makes reading imported html messages from Eudora
difficult.
Keywords: nsbeta1
Whiteboard: [nsbeta2-] → [nsbeta2-],imp-mail
Comment 34•23 years ago
|
||
*** Bug 64117 has been marked as a duplicate of this bug. ***
Comment 36•23 years ago
|
||
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...
Comment 37•23 years ago
|
||
Comment 38•23 years ago
|
||
Comment 39•23 years ago
|
||
Comment 40•23 years ago
|
||
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.)
Comment 41•23 years ago
|
||
Discussed in Mail News bug meeting with Engineering, QA, Mktng and PjM.
Decision was to minus this bug.
Comment 42•23 years ago
|
||
Checked with Eudora 5.0-J on my japanese Mac OS 9. Same problem there.
Changed the platform to all.
Hardware: PC → All
Comment 43•22 years ago
|
||
*** Bug 183454 has been marked as a duplicate of this bug. ***
Comment 44•22 years ago
|
||
*** Bug 150695 has been marked as a duplicate of this bug. ***
Comment 45•22 years ago
|
||
I have seen this bug in Eudora Lite 5.1 also.
Comment 46•22 years ago
|
||
I'm experiencing this bug on Mozilla 1.3a.
Imported from Eudora 5.1.
Windows 2000
Comment 47•22 years ago
|
||
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.
Comment 48•22 years ago
|
||
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.
Comment 49•22 years ago
|
||
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]
Comment 50•21 years ago
|
||
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 → ---
Comment 51•21 years ago
|
||
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?
Comment 52•21 years ago
|
||
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).
Comment 53•21 years ago
|
||
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.
Comment 54•21 years ago
|
||
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
Comment 55•21 years ago
|
||
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.
Comment 56•21 years ago
|
||
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.
Comment 57•21 years ago
|
||
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.
Comment 58•21 years ago
|
||
*** Bug 201984 has been marked as a duplicate of this bug. ***
Comment 59•21 years ago
|
||
*** Bug 237307 has been marked as a duplicate of this bug. ***
Comment 60•21 years ago
|
||
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.
Comment 61•21 years ago
|
||
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.
Comment 62•21 years ago
|
||
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.
Comment 63•20 years ago
|
||
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.
Comment 64•20 years ago
|
||
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.
Comment 65•20 years ago
|
||
Remove an unused line from the previous patch.
Comment 66•20 years ago
|
||
I forgot to mention that this patch corrects only the eudora import process.
HTML Mails already imported will not be fixed with this patch.
Comment 67•20 years ago
|
||
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...
Comment 68•20 years ago
|
||
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.
Comment 69•20 years ago
|
||
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.
Comment 70•20 years ago
|
||
*** Bug 243382 has been marked as a duplicate of this bug. ***
Comment 71•20 years ago
|
||
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
Assignee | ||
Comment 72•20 years ago
|
||
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
Updated•20 years ago
|
Flags: blocking-aviary1.0?
Comment 73•20 years ago
|
||
<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>
Assignee | ||
Comment 74•20 years ago
|
||
Attachment #134823 -
Attachment is obsolete: true
Attachment #148062 -
Attachment is obsolete: true
Attachment #148063 -
Attachment is obsolete: true
Assignee | ||
Comment 75•20 years ago
|
||
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 76•20 years ago
|
||
Comment on attachment 153462 [details] [diff] [review]
the fix
ah, ok - looks good.
Attachment #153462 -
Flags: superreview?(bienvenu) → superreview+
Assignee | ||
Comment 77•20 years ago
|
||
fixed on the 1.0 branch and the trunk
Comment 78•20 years ago
|
||
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.
Comment 79•20 years ago
|
||
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.
Comment 80•20 years ago
|
||
*** Bug 254887 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Keywords: fixed-aviary1.0
Whiteboard: fixed-aviary1.0
Comment 81•20 years ago
|
||
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.
Comment 82•20 years ago
|
||
*** Bug 224839 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Product: MailNews → Core
Updated•16 years ago
|
Product: Core → MailNews Core
You need to log in
before you can comment on or make changes to this bug.
Description
•