Outlook 2013 with Windows 8.1 200% Scaling (some findings)

Update: After some further investigation from community member zerocents there is a solution to this problem!

It involves using MS office specific XML in a Outlook conditional and adding a couple of XML namspaces to your root HTML tag, see more below:

Jump to post

Hi all,

My development machine is a XPS 15 9530 (Windows 8.1), which has a screen resolution of 3200 x 1800, this is obviously a very high resolution and hence relies on scaling provided by Windows, which happens to be at 200%, as this is optimal scaling value for this resolution.

Outlook 2013 with scaling of 200% makes HTML emails look awful. There is no sugar coating it. Some of you may be aware that Outlook in general doesn't handle custom DPI settings other than default well in the first place, but at 200% scaling it really does show. Granted scaling of 200% isn't exactly the norm, and is only going to be in use on Retina type resolutions. (That's me, living in a HiDPI world on Windows!).

Here are a few observations with 200% scaling and Outlook 2013. I'm going to potentially suggest the problems will happen with 2007 and 2010, thanks to that lovely Word Engine.

Exhibit #1 (Container table width attribute value doesn't equal the width set):
http://i60.tinypic.com/24p9ppi.jpg

This is a random Email On Acid email (I didn't have a Campaign Monitor one!) I picked out to show an initial problem.

Were all taught to have a wrapper table with a width of 100% followed by a container table with a width of around 600 or lower right? Well viewing the email in Outlook 2013 with my machine, the content area is not actually what the width set in the email is (580 in this case, I peeked at the source code).

You can see that the content area is completely squashed, certainly not what 580px in width should be. What gives?

I found the addition of a CSS width attribute on the container table resolves this problem:

Fix:

<!-- Wrapper table -->
<table border="0" cellpadding="0" cellspacing="0" width="100%">
<tr>
<td align="center" valign="top">
<!-- Container table -->
<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>
<!-- End Container table -->
</td>
</tr>
</table>
<!-- End Wrapper table -->

Now the width will display at whats expected, so the email is no longer squished up. Weird, but fixed.

Exhibit #2 (Lack of image scaling):

I once read that Outlook would resize images with non-default DPI settings, well it ain't happening here. For comparison, here is the footer of the same EOA email in Outlook compared to it being viewed in Internet Explorer 11 which can upscale images no problem on high resolution.

(Note the screenshot from Outlook is of the email without the above width fix applied, so it appears squashed still)

Outlook 2013 HiDPI, scaling of 200%:
http://i60.tinypic.com/5n3q79.jpg

Internet Explorer 11, zoom 200%:
http://i58.tinypic.com/axh7k5.jpg

Outlook is not scaling the images, and that is a problem, as images will appear very small, half the size to be exact.

For example. Take an image that is 248px x 68px, the way Outlook 2013 will display this will actually look like 124px x 34 px (half the size), though the image or its sizing properties haven't been modified. Its just being rendered at the size it would appear at 96 DPI.

The problem here mentioned is that keyword, scaling. Modern web browsers handle this problem on HiDPI by upscaling images, you can notice this by quality loss on smaller images if they were designed at a fixed width x height aimed at 96 DPI, but ultimately it works fine most of the time. Here Outlook 2013 doesn't, and images are tiny.

Extra credit: Image scaling test (Images without width and height set):

With the lack of image scaling in mind. I have noticed that with width and height attributes removed from an image, Outlook 2013 will upscale them, but only after the images have been downloaded and the email had been re-opened.

When received for the first time in the inbox, the standard image block protection will ask to download the images, accepting this, the images download, but are tiny and not scaled. but after the images have been downloaded, the email closed and then re-opened the images appear at the scaled size that matches the appearance of the images at 96 DPI. Oh.

There seems to be some behaviour differences in the preview pane vs opening the actual email in full as well, although this was an interesting find, it also didn't always apply it all images (sometimes only some). Perhaps some caching may also be involved.

Exhibit #3 (Table cell width and height attributes also get iffy)

This is generally related to both points above. If you have table cell that contains an image, this will show you how the width and height don't actually render as you'd think (or as they do on 96 DPI, the most common setting). Here we have a table cell with a black background. The image has been disabled so this can be seen:

<td align="left" width="244" height="68" valign="top" bgcolor="#000000"><img src="/path/to/image" alt="Something Descriptive" style="display:block;" width="244" height="68" align="left" border="0"></a>
</td>

http://i58.tinypic.com/245x3dv.jpg

Now apply the same width and height values as CSS properties, again referring back to the original problem noted with the container table width:

<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" align="left" border="0"></a>
</td>

http://i58.tinypic.com/2iqeu1h.jpg

Q. Is this image (the grey block) 248px x 68px?
A. No its not.

The table cell is now the correct width but its pretty clear how the image is rendered compared to what size it should be had it been upscaled. Notice all the width and height properties match, yet the difference between the table cell and image. All down to DPI settings and lack of scaling from Outlook 2013!

Your thoughts

Got any comments or similar experiences with Outlook 2013 or other email clients? Let's kick off the HiDPI talk, I'd love to know if anyone else out there is experimenting with HTML email on high resolutions, with such DPI settings.

roshodgekiss roshodgekiss, 1 year ago

Wow, this is fascinating! Really curious to see if anyone else has struck similar issues with high-resolution displays. Chime in if so!


Get in touch with us on Twitter: http://twitter.com/campaignmonitor
We're also on Facebook: http://facebook.com/campaignmonitor
jmwhite, 1 year ago
roshodgekiss wrote:

Wow, this is fascinating! Really curious to see if anyone else has struck similar issues with high-resolution displays. Chime in if so!

I'd love to know as well! I was searching around for any information about HTML Email and HiDPI, but didn't find much. I thought I'd share my Outlook 2013 adventures with high resolutions as I've found that most HTML emails that I get, are broken to some degree.

200% scaling for 3200 x 1800 isn't exactly a common environment that your average Marketing List member is going to be running, but the objective for HTML email is always maximum compatibility, and I guess high resolutions are on the rise, so maybe its time to start focusing on them!

I'll continue testing in Outlook and see if I find anything else worthy of documenting.

jmwhite, 1 year ago

I found the same width issue also occurs on table cells, height is also affected. The values of the width and height attributes don't actually appear as what they should either. I used a table cell width with a background colour to demonstrate how this is the case, in conjunction with an image.

roshodgekiss roshodgekiss, 1 year ago

By the way, Litmus recommends using 96DPI (the default) on your machine when designing/testing. Of course, other machines that aren't using this default will scale text / images accordingly, but it's something to keep in mind when creating email campaigns.


Get in touch with us on Twitter: http://twitter.com/campaignmonitor
We're also on Facebook: http://facebook.com/campaignmonitor
jmwhite, 1 year ago
roshodgekiss wrote:

By the way, Litmus recommends using 96DPI (the default) on your machine when designing/testing. Of course, other machines that aren't using this default will scale text / images accordingly, but it's something to keep in mind when creating email campaigns.

Yes they do, as its the most common DPI setting in the wild.

I have always designed my email campaigns with 96 DPI in mind, so I know they at least look good for the average member on a Marketing List. I'm not exactly the norm with my setup, but I spent some time looking into it.

I even got in touch with Microsoft themselves but its something they don't have a fix for. Again, the Word engine. Enough said!

zerocents zerocents, 1 year ago

I've posted my findings and solution on Litmus community :)

https://litmus.com/community/discussions/151-solved-dpi-scaling-in-outlook

Still working on a fix for images though :(


Michael Muscat
jmwhite, 1 year ago

Hey zerocents, I don't have access to the Litmus community unfortunately, only their inbox inspection tools because of our MailChimp subscription. Would you mind posting your findings here? I'm pleased someone else is looking into this as well!

I solved the width and height on block level tags i.e table cells but cant find a solution to images either, the closest I got was removing width/height from the img tag itself which let Outlook upscale them but only after they were downloaded once and the email reopened. I looked through various mso- css properties and couldn't find anything to fix it.

I even got in touch with the Outlook support team and they didn't have any solutions either :(

zerocents zerocents, 1 year ago

Deleted, see solution below.


Michael Muscat
zerocents zerocents, 1 year ago

So basically the final piece of the puzzle is getting relative widths and heights declared on the images. I've tried percentages on the width attribute, width and height on inline styles, classes on the image, styles on the image tag, nothing seems to stick. It seems as if the inline styles are completely stripped and you can't put classes on the image tag, or even target the image element itself, all of it is stripped. I've posted a VML solution and while it's extremely limiting and tedious... it works.

The really frustrating thing? Open up the email in Word and it renders perfectly, open it up in Outlook and it goes kaput. Outlook is clearly doing something extra here.

One thing I'd like to know: If a person has images on by default, do the images scale correctly?


Michael Muscat
jmwhite, 1 year ago

Nice write up, certainly clears up how width and height values are calculated when DPI is involved. Extra credit for looking into VML!

The problem is images as you say. I spent a bit of time trying various combinations to see if I could force Outlook to upscale images. I couldn't, but learnt a few thing along the way, you can find my points below:

Outlook can upscale images but only when a width and height attribute is not declared on the image tag. By removing them, this seems to act as a trigger for Outlook to resize them according to DPI settings. Setting any pre-defined width or height will stop this from ever happening. This however, goes against standard practice with images in HTML, by not declaring exact width and height values.

Images will always appear small initially (preview pane), the image has to be downloaded and then opened in windowed mode in order for Outlook to scale images, what's worse, it sometimes doesn't happen either, it can be sketchy. Even with images auto-downloaded (Add domain to Safe Senders List) it doesn't always work either.

The preview pane vs windowed email seems to have behaviour differences in relation to above. Images appear small constantly in the preview pane, opening the email in its own window appears to trigger the upscaling of images, but there is still brief moment where they appear small. This seems to be a key point though, Outlook is running some sort of routine to upscale images, if we could tap into this via mso- properties or alternative methods, we'd be one step closer.

zerocents zerocents, 1 year ago

Edit: I've consolidated the solution into one post.

Credit to jmwhite from campaignmonitor for getting the ball rolling on this.

DPI Scaling in Outlook 2007-2013

You might have had this problem before. The email you've painstakingly built finally works and even looks great in Outlook, but increasingly you are being sent screenshots from Outlook that don't look anything at all like what you sent. Fonts are blown out, tables appear crunched, eventually you track down the problem and realise that the user had enabled desktop DPI scaling because of poor eyesight, or increasingly, because this is the default setting on new high DPI laptops. What is an email developer to do?


This is what Outlook is doing to your email

Every time someone opens your email in Outlook, it is transformed into something unrecognisable by the word rendering engine. This is the root cause of the problem, and until now no one really knew why emails were being horribly disfigured by desktop scaling. Here's what happens:

• All widths and heights defined using html attributes are preserved as pixel values.
• All "px" widths and heights defined in VML shapes are preserved 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.

This is why your fonts look blown out, or conversely, why your tables look like they are crunched. Your fonts, padding, margins, borders, etc. are all converted to "pt" values and scaled up, while your tables and images are essentially using unscaled "px" values defined by attribute.


The solution is SIMPLE...

Define all table cell pixel widths and heights using inline styles. They will then be converted to points by Outlook. This isn't necessary for percentage widths since it's already a relative unit.

<!-- Wrapper table is percent width, no inline style needed -->
<table width="100%" cellspacing="0" cellpadding="0" border="0">
  <tr>
    <td align="center">

    <table cellspacing="0" cellpadding="0" border="0" align="center">
      <tr>
        <td height="200" align="center" style="width: 600px; height: 200px;">
        <!-- Use inline styles for pixel widths and heights -->
        <!-- Height is still set as an attribute to support Gmail -->
        </td>
      </tr>
    </table>

    </td>
  </tr>
</table>

To make VML and images scale properly, add this markup to your header (don't forget the xml namespaces).

<html xmlns="http://www.w3.org/1999/xhtml"
 xmlns:v="urn:schemas-microsoft-com:vml"
 xmlns:o="urn:schemas-microsoft-com:office:office">

<head>
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:AllowPNG/>
  <o:PixelsPerInch>96</o:PixelsPerInch>
 </o:OfficeDocumentSettings>
</xml><![endif]-->
</head>

For cellspacing and cellpadding

<table cellspacing="10" cellpadding="10" border="0" style="mso-cellspacing: 10px; mso-padding-alt: 10px 10px 10px 10px">
...
</table>

There you have it. Scalable emails in Outlook with minimal effort.

These findings are preliminary and have yet to be field tested, so please post your feedback and I will update accordingly. Happy coding!


Michael Muscat
jmwhite, 1 year ago

My pleasure, it works!

Right off the bat the preview pane rendered images at their correct size. Even with images off they have been drawn at the correct size!

I sent it through MailChimp so you can be assured its gone through a proper ESP. I've also ran an inbox inspection on the most popular clients to confirm if there any ill effects of the addition of the VML namespace and directives, though the conditional should prevent that.

Good news I've observed no bad affects in any clients, I tested:

Apple Mail 6
Android 4.0
iPhone 4s
Gmail
Outlook 2003 - 2013

As these are tests via Litmus, they'll all be at 96 DPI as standard.

All good. Great find, how did you come across this fix?!

First Windows Phone 8 CSS3 support, now fixing DPI in Outlook, your on a roll!

zerocents zerocents, 1 year ago

Trial and error. It helps when you have a comprehensive reference on office xml.


Michael Muscat
jmwhite, 1 year ago

Fantastic find none the less! I went down the mso- property route in my earlier attempts, but I'd never of thought to look at the VML angle, admittedly I've not used much VML in email campaigns.

Thanks again for this brilliant find!

zerocents zerocents, 1 year ago

It seems like cellspacing and cellpadding don't scale correctly unless you define them using inline styles.

<table cellspacing="10" cellpadding="10" border="0" style="mso-cellspacing: 10px; mso-padding-alt: 10px 10px 10px 10px">
...
</table>

Also realised a height attribute is still needed for Gmail.


Michael Muscat
jmwhite, 1 year ago

Interesting. I rarely ever use cellpadding/cellspacing, I've found it to be inconsistent in some cases.

sbecker, 1 year ago

Thank you people! After much online searching, this is the first time I've seen this issue discussed. I was really wondering what was going with images being different sizes in relation to text in Outlook only some of the time. Will try the inline cell width solution and see if that works.

vwilliams, 1 year ago

Hello Everyone,

I posted the below in the Litmus Community and have not heard anything, therefore I thought I would post to the source!  I appreciate, very much, any assistance you can provide.

Litmus Community Post:

I have been working on this and after much testing, frustration, and beer I have found that using the fixes exactly does not work for my specific email. However, if I change the PPI to 120 my email's images look correct at 125%. But unfortunately when viewed at 100% they are smaller than they should be in the email. So I am back to square one.

I was not sure if I should post my code or not here so I made a quick screenshot of it.

Any assistance that can be provided is greatly, greatly appreciated.

Thank you so much!
VW

Sign up for free.
Then send campaigns for as little as $9/month

Create an account