Thanks for the bug report Sven.

Scott, I can't believe you guys haven't fix this in 1.1.1! I need to set the font to something else than "Variable Width" consistently as otherwise it always displays as Times New Roman in Outlook clients, which is ugly and makes your emails look like from 10 years ago. Mail.app has a similar problem, which was one of the reason for me to switch to Postbox. Please, fix this one fast! It isn't that difficult, hopefully.

Thanks, Sven.

I have to agree with Sven. This is very disappointing.

I thought I could work around it by declaring "Variable Width" to be the font I use normally, and it looks fine in Postbox, but when I view the sent mail in GMail, for example, the fonts are inconsistent still.

One of the other HTML mail headaches I've found is that editing quoted text tends to result in bizarre behaviour.  Namely, sometimes I'll backspace one "character" and it will delete an entire paragraph.   The quoting engine of Mail.app is pretty impressive in this regard.  If I hit return in the middle of a block of quoted text, it knows to continue the quoting after, and not modify the bit before.  Great for in-line contextual emails.    

Using plain-text is generally my preferred answer, but, that too has issues with quoting and wrapping.  Especially if I remove part of a bit of quoted text, the re-wrap engine gets really confused and will move text into weird locations.  The HTML quote-backspace-nuking-paragraphs one though is pretty annoying.  

Same problem here as noted in the original post: 

Although I choose a specific font (Tahoma, medium, in my case) using Postbox > Preferences > Composition > General > HTML > Font, New Messages default back to Variable Width, such that they still show up in Tahoma when viewed in Postbox, but instead incorrectly show up as very ugly Times New Roman 12pt in Outlook and Gmail when received by another person.  This makes my e-mails look unprofessional, and so far is the only impediment to our entire company adopting Postbox as our preferred e-mail client. 

Is there a way you can fix this bug?

(I'm using Postbox 1.1.1 on a Mac OS X 10.5.8, by the way, in case that's relevant.) 

Thanks!

Any update on this?  

It's frustrating to see all the focus on peripheral features (social networking) when there are very basic issues like this one that urgently need to be resolved.

I have had this same exact issue since using Postbox. Are there any plans to fix it?

Firstly, +1 on this. The message composer does not do a good job of maintaining font preferences throughout when composing HTML content (the bullet point test case reveals this painfully). To be fair to the Postbox developers, this seems to be a problem inherent in Mozilla's engine itself; Thunderbird has exactly the same deficiencies and the reason the issue becomes obvious in Postbox is because some of the defaults relating to fonts are subtly different. More on that later, but I'd just like to reply to a comment by SimplictyIsBliss first ...

@SimplictyIsBliss: Messages will display with Times New Roman in Outlook, if they only contain plain-text content. In Thunderbird, plain text is always dispatched unless it detects any degree of 'rich' formatting. In that event, Thunderbird will (by default) ask you if you want to send it as plain text, HTML only, or as a multipart messages which combines both. It is very important to understand that, even if Compose messages in HTML format is enabled on your account, this behaviour still applies.

Generally, it is the right thing(tm) to do as it prevents HTML from being pointlessly sent out where no formatting has been employed. However, that does mean that it is down to the recipient's mail user agent as to which font should be used. After all, it's plain text without any formatting - the decision as to which font to use is down to the user agent and ultimately, the user him or herself. In Outlook, the default happens to be Times New Roman. The user could quite easily change the default font used for rendering plain-text emails in Outlook.

That said, the defaults of Postbox deviate from Thunderbird in one respect. By default, Thunderbird (version 2.x) asks the user what they want to do if it detects rich formatting prior to sending. By contrast, Postbox will always construct a multipart email containing both plain-text and HTML content. That can be confirmed by going to Tools > Options > General > Send Options. There, it should say that it will Send the message in both plain text and HTML (the preference name is mail.default_html_action).

Therefore, I'm suprised that you're finding that Outlook is rendering your messages with the font normally used for plain-text. If presented with a multipart message, it should default to rendering the HTML content unless the user or admin has enabled the Read all standard mail in plain text option, as documented here:

http://support.microsoft.com/kb/831607

Therefore, you should probably check the state of the three preferences mentioned above to see if they have been inadvertently changed. Another thing that may help is to define a value for the msgcompose.font_face preference which, by default in both Thunderbird and Postbox, is undefined. For example:

1. Tools > Options > Advanced
2. Click the Config Editor button
3. Search for font_face
4. Double click the line that starts with msgcompose.font_face
5. Enter the following text: sans-serif
   
6. Click OK

What that will do is force the message composer engine to wrap portions of text with a <font> tag that specifically states that the text withint should be rendered using a sans-serif font (which rules out Times New Roman). You may find that this helps with your Outlook case.

Going back to the issue at large, the inconsistency with font sizes stems largely from two things:

1. Stagnation upstream (in Mozilla's composer engine)
2. The choice of the Postbox developers to deviate from the baseline font size of 16pt in conjunction with the above

With regard to the second point, I touch upon some of the issues caused in gory detail in this thread:

http://support.postbox-inc.com/entries/157830-normalise-baseline-fo...

As I touch upon there, Mozilla's composition engine could do with being generally reworked in terms of how it approaches the issue of applying font properties. The question is, will that ever happen upstream or will the Postbox developers have to chew the fat?

Just to clarify why the composer engine is doing a bad job, consider the HTML that it produces. Let's assume that I've just wiped my Postbox profile and configured Postbox from scratch. I've now proceeded to select "Helvetica, Arial" and "small" as the font size, just as SimplicityIsBliss did. Now, I've composed a new message and run through the test case involving bullet points. Here's the HTML that it produces internally:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<font size="-1"><font face="Helvetica, Arial, sans-serif">The quick brown fox jumped over the lazy hen.<br>
</font></font>
<ul>
  <li>The quick brown fox jumped ...</li>
  <li>... over the lazy hen<br>
  </li>
</ul>
</body>
</html>

So what's the issue here? Well, the composer engine is limited to using the (deprecated) font size and face attributes. We can see that it has applied them in the case of my opening text. However, when it comes to the bullet points (that's the <ul> tag), the engine has neither (a) made use of <font> tags within the list items (b) made use of CSS to enforce any font characteristics. That's why the list ends up falling back upon the defaults.

To put it another way, the composer engine (like many) makes sloppy, excessively localised use of the deprecated <font> tag, but does not do so consistently across all elements. Really, this problem could be solved easily if it were to be given an overhaul and make use of CSS. For example, if the body tag began like this:

<body style="font-family:Helvetica,Arial,sans-serif;font-size:10pt">

... then there would be no issue whatsoever as these characteristics would be applied consistently across all content.

Basically, the composer engine is showing its age. Now, I wonder if there are any bugs in Mozilla's bug tracker which raise this issue?

Well, there's a glimmer of hope. The libeditor codebase [1] is used to implement the HTML composition engine and it does actually have some CSS support [2]. In fact, a preference is exposed to control its behaviour in that regard: editor.use_css. The catch? It has absolutely no effect in Thunderbird or Postbox but does in, say, KompoZer (there's even a checkbox for it in the application preferences). Even then - as far as I can tell - it adopts the same approach as it does with the <font> tag, only wrapping the content in similarly defined <span> tags. Maybe coaxing it to apply a default inline style on the body tag as well is possible?

[1] http://www.mozilla.org/editor/
[2] http://www.mozilla.org/editor/adding-css-to-editor.html

Kerin,

Thanks for the great write up and detail about what's going on. It's very helpful to read that and gave us some good indicators as to what is going on and we've got some good leads we  are investigating for a future update of Postbox. For the case of fonts not being respected for bullets and paragraphs, etc.

-Scott

Sure thing, Scott. Really, the font tag just needs to die :) It's not as though the modest usage of CSS required would be an issue with the other email clients out there. Here's a good site that covers standards support in email clients:

http://www.email-standards.org/

Even those that are rated as poor actually have a level of support perfectly sufficient for the basic stuff that's needed here. The main thing is to always use inline style definitions because those contained in a <style></style> section are liable to be stripped out entirely. Just another thing I noticed along the way ... it's can be a good idea to enforce defaults for certain things such as paragaph margins. For instance, I've once found that AOL's webmail service - while otherwise rendering perfectly my work - was squashing the paragraphs to together. That was solved by using paragraphs defined like so:

<p style="margin:1.12em 0">

Note that 1.12 comes from the "Default style sheet for HTML 4" document provided by W3C:

http://www.w3.org/TR/CSS2/sample.html

Such things could of course lend themselves to useful new preferences. In any case, applying the basic choice of font family and size to the <body> tag would likely deal with the vast majority of the concerns that other folks have already raised.

Here's one more vote for this bug! It drives me crazy. I find myself constantly using the "Remove All Text Styles" feature and then reformatting the message. Annoying and a waste of my time. This needs to be fixed - I'm really thinking of switching to something else - I simply refuse to fight my e-mail client every time I want to send a message.

I too hope this "font thing" gets resolved soon. As Mladen just wrote, and I have the same sentiment, "fighting my e-mail client" is not worth the fight. I sent an email to my boss today, some of the body was cut and pasted, and I chose to paste the text as unformatted hoping the fonts would not get messed up but no luck. My boss wrote me back...."Hi Mark, what font is your e-mail using? I noticed it's harder to read than it used to be. Spacing seems off slightly. Not a big issue but just so you know..." Well, I know my boss and she was just giving me the benefit of the doubt today. This really is a big deal. I know Thunderbird has the same problem but I'm hoping that the experts at Postbox will take care of this for us dedicated, paid-in-full [+ Lifetime Upgrade paid], Postbox users. I love Postbox and am looking forward to it getting even better.

Mark [Windows XP]

I'm experiencing this same issue.  I vote for bumping it up in importance to be fixed.

Same here... Please fix!

Changing title, and moving over to the Feature Requests forum.

Any progress on this issue? Is causing me problems at my job.  :-(

Anyone can confirm if this issue still present in the latest betas of Postbox 2 ?

Im really loving the new beta (beta 3), but a bit sad that this issue still present at this point. Please fix this for the final release...

same problem! I really hope it wil be fixed soon