Microsoft Word 12 HTML mails render MsoNormal paragraphs with margin

RESOLVED INVALID

Status

Thunderbird
Message Reader UI
--
minor
RESOLVED INVALID
8 years ago
8 years ago

People

(Reporter: Brian Hauer, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

8 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1

When rendering HTML emails generated by "Microsoft Word 12", Thunderbird either misinterprets or otherwise ignores prompting to remove margins on paragraphs and therefore renders extra space between paragraphs.

Presumably the author of these messages is using Outlook 12 and Word 12 as an embedded control, although I have never used Outlook and cannot say that with any certainty.

Apparently in their composition window, paragraphs have no margin and therefore the author uses a double carriage-return between paragraphs as is common with plain-text messages.

Microsoft inserts a non-trivial amount of style and markup in the generated message, and then further complicates matters by using the odd "quoted-printable" transfer encoding for the message.  This results in:

1. The following MIME separator:

--_000_FD7A3...
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

2. The following meta tag for "Generator:"

<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">

Note the quoted-printable encoding of equals signs as =3D.

3. The following CSS definition in a <style> tag:

p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}

I am not making that .0001pt bottom margin up.

4. The following HTML markup (I have removed extraneous <span> tags that I think are not relevant to this issue).

<p class=3DMsoNormal>Hey David,<o:p></o:p></p>
<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>
<p class=3DMsoNormal>We will use...</p>

Again note the =3D encoding of the equals sign.

Thunderbird renders the paragraphs with normal margins and therefore the empty second paragraph in the message causes a rendering with extra spacing as seen in the attached screen snip.

I am not sure if the "margin" settings provided by Microsoft are sufficient to cause Thunderbird to remove margins from paragraphs.  But assuming they are sufficient, is it possible that the CSS class is not being identified correctly because Thunderbird is looking for a class named "p.3DMsoNormal" rather than "p.MsoNormal"?

Reproducible: Always

Steps to Reproduce:
1. Receive a message from someone using Word 12 as their mail editor.

Actual Results:  
Excess space between paragraphs either caused by Microsoft inadequately specifying an intent for no margins -or- Thunderbird not finding the CSS class correctly.

Expected Results:  
Paragraph margins would be reduced to 0 and therefore the spacing between content paragraphs in the cited example markup would appear with a gap equal in height to 1 line of text.

This may be "trivial" priority but it is actually quite annoying as it makes messages unnecessarily tall.  I'm selecting "Minor."
(Reporter)

Comment 1

8 years ago
Created attachment 439990 [details]
Rendering of example markup
(Reporter)

Comment 2

8 years ago
My apologies!  Not moments after submitting this, a friend pointed out that this is ultimately caused by the "Message Body as Simple HTML" option.  I'm going to mark this as resolved since the problem disappears when using "Original HTML."

I suppose the only remaining question is whether there is any way to address this so that I can continue to use "Simple HTML" without suffering the additional space between paragraphs.

Ultimately I very much want to avoid the "Original HTML" setting if only out of unjustified paranoia about HTML emails.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.