So after my write up over on the Campaign Monitor forums about the problems with DPI scaling with HTML email on HiDPI devices i.e. my XPS 15 9530, a lot of development has been made in understanding why HTML emails are rendering poorly in Outlook with large scaling factors used. Once again, community forum member Michael Muscat provided a very detailed write up on the situation originally over on the Litmus Community forums covering some of the information I discovered, along with some new workarounds and one of the most critical fixes being for images, which we’ll get into shortly. Big thanks to him for this new information that’s come to light.
DPI scaling in general terms is a known problem in Outlook, but on HiDPI devices its even worse and most of the HTML email campaigns I have received have been broken in some way that affects the layout massively.
For testing and experiments I used the following Outlook clients versions under the following conditions:
- Outlook 2007 (Windows 7 200% scaling)
- Outlook 2010 (Windows 7 200% scaling)
- Outlook 2013 (Windows 8.1 200% scaling)
The common dominator here is all these versions of Outlook use Microsoft Word for rendering email, so while they severely lack any HTML/CSS standards, they virtually render email in the same way, meaning the problems with DPI affect all three versions. Even older versions of Outlook may also be affected, but their usage statistics are rather low, so focusing on these clients makes more sense.
The problems with Outlook and DPI (summarised)
- Width and height HTML values in pixels on various elements are not rendered correctly
- Images don’t render correctly when factors greater than 96 DPI are used
Because of this font sizes often appear out of proportion compared to rest of the email.
Problem #1: Emails that use pixel values for width/height
Welcome to the first problem of HTML email with HiDPI in Outlook. You will notice emails that end up in the inbox on such a device will appear squished up.
Take the Email on Acid example email below (by the way, I’m not hating on you guys and gals or anything, you just landed in my inbox and provided me with a perfect demonstration!)
You’d agree that the width is far too small right? Well would you be surprised to learn that the width value defined in this email is 580px? Its true, but any pixel guru’s out there knows that’s not 580px visually. Actually, its half the size it should be. You’ll also notice that the black header block isn’t squished up, why? Simple, because the width value is 100% which is a relative value. We have our first discovery.
Outlook handles HTML px values differently with higher DPI settings
Taking this nice summary from Michael, this is how Outlook looks interprets widths in various forms.
- All widths and heights defined using HTML attributes are perceived as pixel values.
- All “px” widths and heights defined in VML shapes are perceived as pixel values.
- All other “px” values are converted into “pt” values.
- Desktop scaling is applied to relative units like “pt”. For example, 10pt @ 150% desktop scaling would be equivalent in size to 15pt @ 100% desktop scaling.
Now you know your enemy a little better, but how can we fix this? The fix is actually rather simple. For HTML width and height attributes applied to block level tags like <table> and <td> you simple need to declare a matching CSS width and height property.
<!-- Wrapper table, as this is a relative width, nothing new is required here --> <table border="0" cellpadding="0" cellspacing="0" width="100%"> <tr> <td align="center" valign="top"> <!-- Container table, specify a CSS width in conjunction with the HTML width attribute --> <table border="0" cellpadding="0" cellspacing="0" width="600" style="width:600px;"> <tr> <td align="left" valign="top"> <!-- The rest of your template here --> </td> </tr> </table> </td> <!-- End Container table --> </tr> </table> <!-- End Wrapper table -->
Doing this will allow your px widths to be interpreted correctly as you’d expect. Score.
Problem #2: What’s going on with my images?
So after figuring out why emails appeared squished, the next problem you’ve probably noticed is the rendering of images isn’t quite right. Problem number two. Image scaling in Outlook is poor when the DPI is greater than the default of 96 DPI. See the comparison below:
Email on Acid email footer in Outlook 2013:
Email on Acid email footer in Internet Explorer 11 (View in browser option via Outlook):
To illustrate how width and height values differ with images in Outlook with DPI, here’s an example image at 248px x 68px with the code to go along with it:
<td align="left" width="244" height="68" style="width:244px;height:68px;" valign="top" bgcolor="#000000"> <img src="/path/to/image" alt="Something Descriptive" style="display:block;" width="244" height="68" border="0" /> </td>
After applying the CSS width and height properties to correct the HTML width on the table cell, you can now see how smaller the image is rendered. Notice that both the image and table cell are both the same width and height, but the image isn’t.
Its worth noting here that Outlook isn’t actually modifying the size of the image itself at all. If you were to save the picture from within Outlook it will be the exact size of the original image. It is all to do with scaling.
Outlook can scale images (sort of..)
You may be surprised to learn that Outlook can scale images, but not immediately when it lands on the inbox. From tests the images appear half size in the preview pane, even with images on or off they are drawn incorrectly, however once the images are downloaded and the email has been opened up separately, images do get scaled up. It is however a process that is triggered sometimes so its not reliable. There is also however a very big catch 22 to this.
In order for Outlook to scale images you must not declare any width and height attribute on the image tag itself, otherwise this prevents it from ever happening. This goes against best practice in regards to image in HTML so what do you do? The preview pane problem remains however, images always appear smaller than they should so the answer is relying on Outlook to do it on its own isn’t an option.
Documentation dating back from Microsoft Office 2000 provides the answer (no really!)
This is where Michael Muscat and his experiments picked up where I left off, all of the image based handling discoveries are solely down to him! Outlook can be forced to render the images correctly with some clever XML directives that only Outlook understands. It requires you to make some adjustments to your template first.
Additional XML namespaces:
You’ll first need to amend the root HTML tag in your template to incorporate some XML namespaces that Outlook will need to understand the special directives that are going to be used.
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office">
The first part is to enable VML support, what is VML? Its a subset of XML specifically for images and shapes that is supported in Microsoft Office and hence Outlook 2007, 2010 and 2013. While VML isn’t required directly to fix this, Michael did some experiments with VML which helped lead to the discovery below. The second part is to enable the Microsoft Office namespace for use in Outlook.
Normalise the DPI of images (which is referred as PPI by Microsoft Office):
This is where the magic is, you’ll now need to place this Microsoft Office specific code in the head section of your template, it should be included right before the closing tag of the head.
<!--[if gte mso 9]> <xml> <o:OfficeDocumentSettings> <o:AllowPNG/> <o:PixelsPerInch>96</o:PixelsPerInch> </o:OfficeDocumentSettings> </xml> <![endif]-->
This snippet will now scale up your images upon landing in the inbox, meaning the preview pane will display the images properly, along with when the email is opened separately making whole email looking more like its 96 DPI counterpart that you probably dreamed of seeing on HiDPI. You’ll notice some quality loss on the images i.e. jpeg, but overall it works well.
Why does this work?!
Well, first of all remember when I said documentation dating back to Microsoft Office 2000 helped solved the problem? I wasn’t lying. In fact Michael said he had help from a complete reference of XML in Microsoft Office over on MSDN to help find a solution. The link is a download for a HTML (ironic) help guide that details various properties dating back to Office 2000. You might not know this, but in order for Microsoft Office content to be potentially usable in webpages (back in the day this is) it supported (and still does) HTML, CSS, XML and VML. Of course there are limitations to the support level for these languages, but this is the underlying factor as to how its possible to use such properties in Outlook.
OfficeDocumentSettings is the containing tag, but in this case it acts as the container for various document properties, don’t forget this is the Word rendering engine so the term document is actually what email is to Outlook 2007 onwards, a Word document. Within the OfficeDocumentSettings tag the following properties can be used, most of them not really relevant:
AllowPNG, Colors, DoNotOrganizeInFolder, DoNotRelyOnCSS, DoNotUpdateLinks, DoNotUseLongFilenames, DownloadComponents, LocationOfComponents, PixelsPerInch, ReadOnlyRecommended, RelyOnVML, TargetScreenSize
The golden nugget in this case is PixelsPerInch, being able to force a specific DPI setting fixes the image problem beautifully. AllowPNG is not strictly required, but potentially by using it you can gain some image quality and decreased file size (and overall image download time).
A caveat for Outlook 2007
Unfortunately sometime after writing this article, I found Outlook 2007 has some behaviour differences when modifying the PPI value. A community member on the Litmus Community member mentioned that this fix didn’t work for her and images were still were still not being rendered correctly in Outlook 2007. Intrigued I did some further testing. What I found is a different behaviour and hence rendering of images when modifying the PPI value.
125% scaling (120 DPI):
- 72 PPI – Enlarges images a lot
- 96 PPI – Enlarges images slightly
- 120 PPI – Images are displayed at the correct size
100% scaling (96 DPI):
- 72 PPI – Enlarges images by a lot
- 96 PPI – Images displayed at the correct size
- 120 PPI – Shrinks images (erm what?)
Compared to the later versions, Outlook 2007 has a different way of handling the PPI with DPI scaling factors, it looks like Microsoft since changed this behaviour, maybe as a bug fix or simply by design, either way however you’ll notice the difference of what each value of PPI does under Outlook 2007.
The inconsistent image scaling factor difference between 100% scaling and 125% scaling (as well as others) means you can’t fix the image scaling problem for Outlook 2007. Because whichever way you go, you will break the appearance for either the normal DPI audience or the higher DPI audience. There is no way to conditionally target any Outlook client by DPI (only by Microsoft Office version). This means by forcing the 96 PPI value, you’ll still find images will be slightly larger than they should be for clients using DPI factors greater than 96, but in my opinion forcing 96 as the PPI will still make things a bit better.
A workaround in this case is to develop your layout in such a way that will allow the image to push your layout wider, rather than break out and overflow, it certainly won’t look as pretty, but its damage limitation
Let me know your results
Improving HTML email on HiDPI may not be a priority for you when it comes to development time right now, but with HiDPI devices on the rise with Windows 8.1 and future versions, its a good time to understand how Outlook handles DPI and how you can make your emails looks better for these type of Marketing list members! There is also the consideration of users who use large DPI factors for accessibility purposes as well.
All of the information here is fairly new, and hence hasn’t been tested thoroughly, I’ve tried to get a broad range of clients and environments to test everything out and haven’t found any bad side affects. I’d love to know if anyone else has been testing this and what your results and thoughts are. You can post your thoughts in the comments below or join in the discussion over the Litmus Community forums. You can also find the original article I started on the Campaign Monitor forums
Once again, big thanks to Michael Muscat and his input on this, couldn’t of done it without him!