I'm programmatically sending HTML-formatted email, and setting the font as Arial throughout (font-family: Arial;). When the messages arrive in Outlook 2010, text in table elements is in Times New Roman. Text in div elements is fine in Arial. If I View Source, copy into an HTML file, and view in a browser, all fonts function as expected (it's all Arial).
Some Google results show that Outlook will fall back to its default font (Times New Roman) when none is specified, but that's not what's happening here.
Why is Outlook forcing my email to display in Times New Roman when specified otherwise?
Even if you set font-family: arial to table, it still wont work. You need to specifically set the font for each td inside your table to get it right.
<!--[if mso]>
<style> body,table tr,table td,a, span,table.MsoNormalTable { font-family:Arial, Helvetica, sans-serif !important; }</style>
<!--<![endif]-->
The table in question was nested in a div that had font-family:Arial; in its style, but the table did not have a font set. So tables don't inherit fonts (and perhaps other things) from their containers in HTML emails in some clients.
This issue was happening from outlook 2007 and the previous solutions didn't work for me, the only solution that seems to work is wrapping the text with <font face="arial, sans-serif">My text with arial</font>
If you're working with Outlook 2007, you must define font-family on table . Otherwise it will set to default serif font.
The <font> tag is deprecated but since Outlook 2010 is removing (almost all) styles, this is the only way it works.
table.MsoNormalTable
{font-size:12.0pt;
font-family:"Times New Roman";}
Open your HTML with Text Pad, and change it to Arial.
None of above methods worked for me, using a custom font linked with #font-face. had to work with conditional tags for Outlook. Took me quite some time to figure out how exactly. So I've set up a code example: I was still having some troubles implementing this in my situation so I've shared a code example for this: https://stackoverflow.com/a/21626196/135654
You can put your style to "span" tag, It will works good.
<td>
<span style="font-family: "Times New Roman"></span>
</td>
I had the same problem....all text in the body of the email was Arial, but the table defaulted to word. I had to wrap the font in each each cell......time consuming..
Related
I'm working on an email that has several dividers. The character in the table cell gets deleted when edited through the wysiwyg editor. I tried using the &zwj character to solve that issue and it works on most email clients but outlook 2016 is showing a line above the divider.
Screenshot
Is there a better solution than this?
<tr>
<td bgcolor="#222222" style="font-size: 1px; line-height:16px; color:#222222"></td>
</tr>
Outlook 2016 has a problem with adding those lines in. Other developers have reported that the issue is down to Outlook 2016 converting white space.
You could try targeting Outlook and collapsing the borders. Just add this:
<!--[if (gte mso 9)|(IE)]>
<style type="text/css">
table {
border-collapse: collapse;
border-spacing: 0; }
</style>
<![endif]-->
It’s worth noting that depending on how you structured your email this may not be the right fix for you. It works on some emails, but can have an adverse effect on the overall rendering of the design.
You can also try matching the background. It's more of a cover up than a fix. Lines inherit the color from the <body> tag. So, by setting the background color of the <body> to the same color as our problem section, we essentially cover up the lines. They’re still there, yes, but no one will see them. We also want to only target the problem clients. There’s no need to change the background color of clients that render the email correctly.
Simply add this to the <head> of your email with the background color changed to match the problem section.
<!--[if (gte mso 9)|(IE)]>
<style type="text/css">
body { background-color:#123456 !important;}
</style>
<![endif]-->
More info about lines in Outlook here: https://www.emailonacid.com/blog/article/email-development/how-do-i-get-rid-of-the-lines-in-outlook-emails/
Have you tried using border instead of background to set the color?
<tr>
<td style="font-size: 1px; line-height:0; border-bottom: 1px solid #222222;"></td>
</tr>
If found that even when ESP's don't mess with and characters, Outlook can sometimes interpret height and line-height oddly. If if we're using mso-line-height-rule: exactly;.
I use border in my own work and haven't found an issue yet.
Cannot replicate this at all. Any chance of a view of your complete template code?
There could be a wider underlying issue with your HTML.
Alternatively, change your declaration to
That is the correct HTML version of a zero space character.
zwj also doesn't display correctly in Litmus when I test your snippet in one of my templates.
I've seen this problem touched on in many questions but none have been specific enough to help me. So I hope it offends no one if I simplify it and ask again. Hope springs eternal!
Is it really IMPOSSIBLE to control the width of an image embeded in an email when Outlook renders it? I.e. control the width of an image for which the html code is
<img src="cid:seal">
I.e. when the html code expects an embedded image instead of one stored elsewhere.
[Note: "seal" is the content ID I assigned when creating the MimeBodyPart with the embedded image].
Details:
I use a Javamail application to send a multi-part email message. The body part is an html document. Another MimeBodyPart carries the image used in the html doc. I've simplified the html test to nothing more than a two column table with the left column for the image and the right column for text.
And absolutely NOTHING I have tried has been able to control the size of the image when opened in OUTLOOK.
The image is always what I assume must be some native size for the image ... which is too big ... so it forces the first cell to be more than 15% wide. Or if I give the cell a fixed width the image overflows the box, i.e. get's clipped.
I put the basic code stripped of all font styling colors etc. below.
I have tried every combination of using width attributes and css style properties on the img tag. I've wrapped the image in another table ... or wrapped it in a div block inside the main table cell ... and even wrapped it in a div block inside a table cell inside the parent table cell. And I've tried specifying widths in fixed pixels and %'s.
It would really be nice if we all knew for sure if this is simply IMPOSSIBLE with Outlook.
Or if it is possible possible, to publish sample code that works. [It's hugely attractive to have the email open its images immediately, and not rely on the reader downloading them.]
NOTE: I seem able to control width when I load the image from an outside source afterwards, i.e.
Thanks for any help.
<html>
<head>
<meta name="viewport" content="width=980, initial-scale=1">
<title>Test Email</title>
</head>
<body style="width:100%; border:0;margin:0;padding:0;">
<table align="center"
style="width:980px; border-collapse:collapse;
margin-left:auto; margin-right:auto;">
<tr style="border:0; margin:0; padding:0;">
<td style="width:15%; border:0; margin:0; padding:0;">
<img src="cid:seal"
style="width:6em; height:auto;">
</td>
<td style="width:85%; margin:0; padding:.5em 0em 0em 0em; border:0;">
Some Titles and stuff
</td>
</tr>
<tr>
<td colspan="2" style="border:0; margin:0; padding:1em 1em 0em .5em;">
<p> 1st paragraph
....
<p> last paragraph
</td>
</tr>
</table>
With help from Eugene above, I discovered at least one good solution.
<img src="cid:seal" width="300" or "300px" of "15%"> DOES NOT WORK.
But when I ditched the quotes this worked
<img src="cid:seal" width=300 height=300>
It does of course mean setting width in % is still a problem since it requires quotes.
But I'll take what I can get. Email now pops open with logo without the user needing to download pictures. AND ... this css body selector also works rendering the background with an embedded image. [I stored the background image with a Content ID of"bkg".]
AGAIN ... unlike the img attribute src="cid:id" that uses quotes, url() requires the id w/o quotes.
<body style="background-image:url(cid:bkg);
background-repeat:repeat;
width:100%;
generic-family:Sans-serif;
font-family:Verdana;
border:0;margin:1em 0 1em 0;padding:0;">
Outlook uses Word as an email editor. The following series of articles provides reference documentation related to supported and unsupported HTML elements, attributes, and cascading style sheets properties:
Word 2007 HTML and CSS Rendering Capabilities in Outlook 2007 (Part 1 of 2)
Word 2007 HTML and CSS Rendering Capabilities in Outlook 2007 (Part 2 of 2)
You can design the page in Word and then save the resulted document as a web page. Thus, you will find the required HTML markup to use.
If you're like me, your eye will be twitching by the end of reading this. I don't blame you.
Our client has requested us to develop a responsive HTML email template, with two specifications:
Using as few images as possible
Using as many "fancy css-enabled features" as possible. Mostly, this just means rounded corners on boxes.
This question is specifically about executing the rounded corners. Gmail and Apple support CSS rounded corners, and Outlook requires vector graphics. For the remaining platforms, they're ok with using square edges.
Here's how we're detecting and executing outlook:
<!--[if mso]><v:shape>...</v:shape><![endif]-->
Works like a charm, even back to Outlook 2000. The problem is, I can't figure out how to create a fallback. Intuition says this:
<!--[if !mso]>...<![endif]-->
but it just gets ignored outright as a comment by most other email clients, and then corners are missing from the boxes altogether. I ask you, fine members of the SO community: is it possible to deploy markup for all platforms except MSO? Perhaps there's a more clever way to accomplish this that I haven't considered? Or is email HTML still too stone-age to attempt something like this?
Found a solution after much brain-wracking. Instead of this:
<!--[if mso]><v:shape>...</v:shape><![endif]-->
<!--[if !mso]>[fallback goes here]<![endif]-->
This works very well:
<!--[if mso]>
<v:shape>...</v:shape>
<div style="width:0px; height:0px; overflow:hidden; display:none; visibility:hidden; mso-hide:all;">
<![endif]-->
[fallback goes here]
<!--[if mso]></div><![endif]-->
All it does is wrap the fallback in an invisible div in MSO, and deploys the vector solution instead.
Hope this helps someone in the future!
This also works, without the need for the hidden div.
<!--[if mso]>
Outlook content
<![endif]-->
<!--[if !mso]> <!---->
Non-outlook content
<!-- <![endif]-->
The trick is to re-open the comment before closing it on the 4th line - the
<!---->
bit. If you don't do that, IE renders "-->" before the non outlook content. Other browsers don't have that problem.
Although CodeMoose's solution does hide the fallback; in my tests, it left space for where the fallback would be (I read that Outlook doesn't render overflow:hidden). That didn't work for my layout since it bumped other elements out.
After a lot of searching, I found that if you make a small modification to CodeMoose's suggestion, it'll hide your fallback and won't add any unnecessary spacing:
<!--[if mso]>
<v:shape>...</v:shape>
<![endif]-->
<[fallback goes here] style="mso-hide:all;">
By adding "mso-hide:all;" to the actual style of your fallback, Outlook will collapse and ignore your fallback code, thereby preserving your layout. And your fallback still displays fine in clients that can handle the complex CSS you used VML to try to replicate, like in Outlook for Mac.
I had some troubles with Outlook falling back to Times New Roman when using a custom font with #font-face declaration. Not only did I have to hide the #font-face declaration from Outlook using the conditional around it's own style block. (all other styles go in another block). I also had to double wrap my textual content in spans with the conditional tag. Just to give an example of how this technique as posted by #CodeMoose (above) works while using a custom font.
<!--[if !mso]><!-->
<style type="text/css">
#font-face {
font-family: 'Museo100';
src: url('http://www.somesite.nl/site/fonts/museo100-regular-webfont.eot');
src: url('http://www.somesite.nl/site/fonts/museo100-regular-webfont.eot?#iefix') format('embedded-opentype'),
url('http://www.somesite.nl/site/fonts/museo100-regular-webfont.woff') format('woff'),
url('http://www.somesite.nl/site/fonts/museo100-regular-webfont.ttf') format('truetype'),
url('http://www.somesite.nl/site/fonts/museo100-regular-webfont.svg#museo100') format('svg');
font-weight: normal;
font-style: normal;
}
<!--<![endif]-->
First I tried to put the conditional around my "Museo300" font declaration inside the inline style but that obviously didn't work, so I had to double wrap my content into two span's with style declarations. The inner one being conditional for non MSO.
<span style="color: #00B2EB; font-family: arial, sans-serif; font-size: 14px; line-height: 19px; font-weight: normal;">
<!--[if !mso]><!--><span style="font-family: Museo100;"><!--<![endif]-->
Text goes here, shown in Museo in Apple mail while this method shows in Arial in Outlook (and others that do not support custom fonts
<!--[if !mso]><!--></span><!--<![endif]-->
</span>
This works great in getting Outlook to show the text in Arial while Apple mail will show the text in font Museo. Other clients (like mail on Android) have a normal fallback behaviour and just show Arial.
This is my first post. So:
I'm working on an HTML e-newsletter using the same template I've used for a while now. The template has worked well until recently (the bit of code I have been using is below). Suddenly Outlook 07/10 are not behaving the same way I perceived that they had behaved in the past. They don't appear to be honoring white-space attribute when it comes to hyphens. All other email clients are behaving as I expect (they're honoring white-space attribute).
One of the elements in the newsletter is an ISBN, which is a set of digits separated by hyphens like, "978-1-555-97610-1". The ISBN is in a span tag that is part of a line of text inside a p tag that along with many other p elements, and possibly an img, reside inside a table. I need to prevent ISBNs from breaking on hyphens and wrapping onto new lines.
I can't use non-breaking hyphens, and I have researched this problem a lot in the past (I get a lot of ISBNs in my line of work), so I hope I'm not posting something that's already been answered a billion times.
Any help is deeply appreciated!
Thanks,
Andrew.
CODE:
<p style="font-family: Arial, Helvetica, sans-serif; font-size: 13px; color: #000000; margin-bottom: 0px; text-align: right;">
Metropolitan Books · 384 pages · $18.00 · paperback ·
<span style="white-space: nowrap;">978-0-8050-9466-4</span>
</p>
How about non-breaking hyphen ‑
Use the <nobr> tag.
E.g. <nobr>978-0-8050-9466-4</nobr>
I needed to have an element not break in an email viewed through Outlook 2013, but not break on spaces. As much as I hate hacking, the way I tackled this issue was to use non-breaking hyphens, but set their color to the background-color of their parents:
<div style="background-color: #fff; color: #000;">
New<span style="color: #fff;">‑</span>Listing
</div>
I have been working on a similar problem except in Outlook 2016 and white space (spaces), and the solution I found that worked for me is using html character.
You might want to try adding width to this, if possible. Then it is not breaking.
I'm using Bamboo invoice as an invoice generator, and I'm trying to customize the invoice template, but no matter what I do, the font just won't seem to adjust.
currently I have
body {
margin: 0.5in;
font-family: 'helvetica';
font-size: 10pt;}
I've read up on it, and helvetica is an installed font, so it should work
to make sure I changed it to 'courier'; which is also in the lib/fonts directory, but the font remains the same.
Any help?
Kinda late, but still applicable for google visitors
I had a similar problem with DomPDF, but since BambooInvoice uses it... Anyway DomPDF has trouble with the font-family definition in the CSS. I applied inline style to the top div box to solve the problem.
<div id="container" style="font-family:sans-serif;">
....
</div>
I solved my problem by removing a font: inherit that was applied as a 'css-reset' to almost all elements as a first declariation. Apparently this is not overridden by later declarations, and/or inherit doesn't work properly.
I had similar problem with DomPDF 6b3 when trying to use font-family or font-size. Finally discovered that using font instead of those seems to be working.
Remove the quotes around helvetica.