
Mystery Solved: DPI Scaling in Outlook 2007-2013
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 -->
<!-- Still need height attribute for 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, add these mso styles.
<table cellspacing="5" cellpadding="10" border="0" style="mso-cellspacing: 5px; 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!
Edit: Vastly simplified thanks to some special xml that hopefully fixes VML and image scaling. Again, not field tested, but promising from what I've been able to see.
Edit: Solution confirmed to be working by jmwhite
Edit: Still need height attribute for Gmail, added some extra styles to make cellspacing and cellpadding scale properly.
A comment on font sizes: As stated in this excellent post
font-size
"px" values are converted into "pt" values, but it seems they are rounded to half pt:s. The same goes forline-height
. So if your CSS saysfont-size: 15px; line-height: 22px;
Outlook converts it tofont-size: 11.5pt; line-height: 16.5pt;
. This is effectively displayed as 15.3333px / 22px. The font is therefore larger than intended.This is great! Thanks for the help! Unfortunately, I've run into an issue. All of this gets thrown out the window as soon as the user forwards or replies to the email. Images and tables no longer agree on what the width should be and everything looks crazy. Has any one else experience this issue?
I should mentioned that I believe the primary cause is when an Outlook user sends or receives a forwarded email from an email client that did NOT have a matching DPI. I'm speculating though, I'm still investigating.
Forwarding HTML emails can cause all sorts of rendering problems. If my memory serves, the already rendered email has it's styles re-rendered. Likely those cellpadding and spacing styles could be getting stacked on forward. Not sure there is much that can be done for this.
Outside of completely redesigning the email layout in a way to be less prone to the affects of forwarding, you're probably right. I'm currently attempting a complete redesign because I don't think my managers are happy with the current results.
Most ESP's provide a "Forward to a Friend" feature/widget. I'd include that in your email so a fresh version will be sent to the forwardee.
Thanks for the suggestion Susan. Unfortunately, we do all of our email campaigns in-house. But more importantly, the issue appears on replies as well as forwards. And the email I'm dealing with is an invoice payment reminder for a B-to-B business. So there's a lot of back and forth.
I have to agree James. All of the testing I have done is to implement the changes outlined here into a template used on new messages within Outlook 2013, with display scaling set to 200%. These changes all allow included text/images to look fine while the message is being composed, but any recipient on a lower DPI screen still sees blown up content.
I get the feeling that this technique works up until the point where the content is rendered on a high DPI screen, prior to a send. So in my case - an Outlook Template for a 1-off email - the content doesn't stand a chance when it gets rendered at a higher DPI from the get-go.
This breaks because email clients will re-interrupt the email and rewrite it the way it wants before sending and if it doesn't like something it just throws it away.
Sorry to bug you about this again, Michael but it is not working for me. I followed the steps above and (1) added to the xmlns (2) added to the head (3) have all my widths inline, however I can not add the height to every cell as this is a template and I don't know what the heights will be - will it be ok if I don't and just have the widths? And do I need to put 'px' for each of the widths/heights or use the style for them as it is shown both ways above? (4) I don't use cellpadding or cellspacing.
This is what the top of my email looks like; http://screencast.com/t/BqJtzpCw
Is there anything else I can do? And also I am trying to put a "public-facing" version of the code so I can post it here.
Thanks so very much!
VW
Right Veronica you might of just discovered how this method doesn't work properly in Outlook 2007.
I was testing on Outlook 2010/2013 as I figured it wouldn't matter seems Outlook and DPI are the same in 2007-2013 right? WRONG! Actually it does matter because there seems to be a rather interesting difference with Outlook 2007.
Setting a PixelsPerInch value of the following in Outlook 2007 will yield the following results:
125% scaling:
100% scaling (Normalised DPI):
Can you spot what's wrong here? I smell a bug in Outlook 2007...
The completely backwards image scaling factor difference between 100% scaling and 125% scaling means you can't fix this problem. Because whichever way you go, you will break the appearance for either the normal DPI audience or the higher DPI audience.
I ran a test with two conditional statements for Outlook, setting a PixelPerInch value of 120 PPI for Outlook 2007 and 96 PPI for 2010/2013 and while that works, this will now break the layout for any normal DPI client who views it Outlook 2007 as images will appear smaller than there original size, as you reported originally in your post on the Campaign Monitor forums.
Now knowing that Outlook 2007 will now be enlarging images when forcing images at 96 PPI and there being nothing you can do about it, one workaround is to basically code your email so the table layout expands with the image. I took some of your code quickly and formed an example of how this could be done, it would require quite a bit of adaptation based on your current code.
http://pastebin.com/Xrx8wzwQ
Its not going to look as great, but it means the image won't break out of the table layout looking out of place.
Hey James,
Wow! Your testing is amazing! So it sounds like the only Outlooks affected are 2007 / 2010 / 2013 - correct? I also read that it only happens on Windows 7 / Vista - have you found that to be true? If so, that makes the audience much smaller than every single version of Windows.
Also, what about those emails that don't use this technique and still look great at 125%? I have an example here; http://jsfiddle.net/BBLQs/. It is just interesting that they don't have any problems and I am having a lot of problems.
By looking at my code, I wonder if I am doing something incorrectly that makes the emails more vulnerable to the scaling problem? Or is it more random?
Sorry for all the questions, I'm just trying to wrap my head around this :D
Also THANK YOU for the email test, however it broke my responsive design and it still looked bad on my 2007 - maybe I have some strange setting?
Not sure, but if you are attending the Email Design Conference in a few weeks I definitely owe you a pint or two!
Thanks again!
VW
Hi,
No, only Outlook 2007 I believe, as the DPI handling appears different. Outlook 2010/2013 should be OK, as 96 PPI seems to work fine across various scaling factors. Older versions of Outlook pre 2007, I have not looked into that much as they don't use the Word rendering engine.
I don't believe this issue is specific to Vista/7 as I ran the tests on Outlook 2007 at 125% scaling on Windows XP Professional (Virtual Machine)
Emails that don't manipulate the PPI of images may work because the layout expands as the image is enlarged, like I was referring to. However I can assure you, it will be broken on Higher scaling factors in Outlook 2010/2013.
My code snippet was literally just a basic example, I didn't use any of your responsive code, you would need to re-apply that. It was basically to demonstrate a table layout that would expand with enlarged images rather than how your original template made the image break out.
James - that is wonderful news! I am glad to know the scaling problem is not specific to a certain version. And what you say makes total sense to me about the emails that don't manipulate the PPI.
For the code snippet, I wanted to confirm that what you did was for the table the image is in you did not enter a width - is that correct? As I am going to run some tests and wanted to make sure I was understanding your concept correcty.
And again - thank you SO much for your assistance!!!
VW
It definitely looks like Outlook 2007 behaves differently when you manipulate the PPI on images, and likely a bug judging by how the PPI value and the scaling factor don't match up. Basically the original fix by Michael works, but not for Outlook 2007, because 96 PPI doesn't do the same thing it does in Outlook 2010/2013, which again leads me to think its a bug which Microsoft never fixed, but made changes to in future versions.
Outlook 2010/2013 can be normalised by forcing 96 PPI, it appears to work consistently across all scaling factors (compared to Outlook 2007). It explains why I initially couldn't replicate your issue as I was testing at 125% scaling on Outlook 2010, which rendered your image fine without any problems. I also tested it at 200% scaling on Outlook 2013, no problems.
What I did was create a very basic table structure, one wrapping table at 100% and one container table at 600px (as a width attribute + CSS width property) within that I added that header image. The container table provides the width required, so its not required to set further widths on nested tables/cells if it needs to be 600px.
Not sure you will see this given how old this post is, but I'll give it a go.
I'm currently building an eDM. The laptops everyone uses in the office run Win7 Outlook 2013, with a default of 125%.
However, when I set the images to 96 the images get scaled up, and 120 shows at the correct size. But you're saying this only happens when running Outlook 2007?
I'm torn between doing this at 120dpi just to keep the people in the office happy, but will be not as appropriate for anyone else using Outlook.
Man I hate Outlook.
Hello, got your message on the Campaign Monitor forums, being part of the original discussion and in possession of a HiDPI device I feel compelled to assist!
If you could, would you upload the code in your template somewhere so I can investigate further.
James - of course! Here it is, http://jsfiddle.net/W8vx5/
I am extremely grateful for your review.
Thanks!
VW
Veronica,
Looking at your email code at first glance, you are not required to add a width CSS property to each table cell, when the cell itself doesn't have a width attribute. In the case of the large 600px width image in question, image scaling is handled by the MS Office XML code. You should also force the value of 96 for PixelsPerInch and not 120.
When a width attribute is used on a table or cell, only then you should use a width CSS property, but otherwise its not required. The exception to this rule is percentage width values as these don't need special handling.
As the containing table has a CSS width property already set, that is enough.
So in short remove the CSS width property on the table cell containing the image, and all will be well. I just tested it on Outlook 2010 at 120 DPI. Fortunately I have many virtual machines to do my dirty work. You also got a free test in Outlook 2013 at 192 DPI, and the image scales fine :)
Hey James - I thought I did what you said, but it did not work which really pains me to say :(
I definitely could have misunderstood and applied the incorrect updates.
This is what the email looks like at 125% -> http://screencast.com/t/KwRn4PGfOH and the code is here -> http://jsfiddle.net/W8vx5/1/
I feel really bad, but do you mind taking a look again? I am also trying out using png's instead of jpg's made from a MAC instead of a PC - maybe that is something? No idea.
But thanks so much for your time on this - I greatly appreciate it!
VW
I can confirm that the issue is showing up in Windows 8 outlook 2013
Can someone tell me why outlook 120 DPI adds extra pixels here
http://d.pr/i/13Ro3
Code here: https://litmus.com/builder/10a4a2d
See red border around the yellow image. The blue image is in correct size.
Hi Stian,
I think its got to do with the cellspacing and cellpadding you have on the table that has the image.
Cheers
I've tried all of the "fixes" outlined in this thread, but according to my test results in Litmus, the fonts are still getting bigger than they should. Is there anything that can target that issue alone?
I fixed the text scaling simply by converting px to pt.
Try adding !important; to the inline font-size and line-height ... That worked for me
Patrick, thanks for the suggestion. I gave it a shot just like you suggested, but the Litmus test results were unchanged. The font-size gets larger, and the font-family also changes. I'll keep looking for a solution. (The fix for image scaling does seem to work, though)
Hi Patrick, remember to be careful of !important in emails - see here https://www.campaignmonitor.com/blog/email-marketing/2010/05/outlook-2007-and-the-inline-important-declaration/
I’ve been through these fixes again and again but despite implementing all the above I can’t get my images to resize in Litmus testing no matter what I do.
Can someone provide a complete template that effectively addresses this issue? Just a bare bones complete HTML that works when tested. It’s driving me nuts that this post (and several others around the web) seems to claim that it’s a simple fix and I can’t replicate that success.
Do you have acces to a laptop with a high DPI screen, because I see sometimes in Litmus that my images won't resize but in real-life they do.
I don't, but a team member does and reports the image being larger as displayed in the Litmus Outlook 120 simulation.
Can't seem to fix it. I've used many of the examples here but it seems that different techniques will work or not work depending on the specific elements across the entire code structure, so that's why I'd like to see something complete if possible.
Agreed that Litmus can sometimes be in error with renderings especially with Outlook across different hardware.
as soon as i paste
in the head, it stops rendering in Litmus builder previews entirely...
Hey Michael - This is a screenshot of what I have in the head of my emails and they work in Builder; http://screencast.com/t/skzcOYj2Rwlw
I made a mistake with the closing </head> tag - it's slightly improved, if i can control the font size....
Thanks Veronica
Would LOVE it if Litmus added a HiDPI browser test.
They just added an Outlook 2013 120 DPI test, which is pretty close!
Yes this solution still helps at least to change the look of the mail sent to customers, especially with Outlook and other products.
Hi Everyone,
Thanks for the above fix which is working great for me except that the images in Preview pane (Outlook 07-13) still look smaller. But when I open the email (double click and open it) all the images are scaled and look great.
I double checked and triple checked all the code and it is as per the above suggestions, and going crazy as the images are smaller (not scaled) on initial load in the preview pane
Any help is much appreciated
Thanks
Rohith
I'm having the same issue it seems like the mystery has still yet to be solved with image portion of this fix for 07-13 outlook.
Reading through this forum it seems like there has not been any working solutions for Ralph or Vincent (if there is a fix please let us know with an update). I've pretty much used all the recommended fixes such as calling out all widths and heights and changing DPIs on the images and still images are smaller and not expanding to its called dimensions. Also using bulletproof backgrounds and having the same issue there with the VML images not enlarging all the way but I'm thinking its the same issue.
If the original poster Michael or James can really weigh in that would be great, if there is no fix for 07-13 outlook that's fine, just don't want to spin my wheels trying to figure it out.
Thanks!
J
Sure, please post the code somewhere, preferably the output that is generated from your ESP.
Thanks Michael,
You are a star, that actually helped
My ESP (Eloqua) is creating a new <html> tag and moving the <html xmlns *****> with namespaces into the body, I did send a test using the same code from MailChimp and it works great.
May be my ESP is treating the namespaces in a different way, I have to check this with the tech support on this
Thanks again
Rohith
Thanks Michael and Rohith,
I also use Eloqua and the html tag could be altered while outputting the email. Thanks for helping in discovering this potential issue.
I really appreciate your prompt replies and will post a fix for this particular issue if there is a solution. In the meantime I can work with something here. Thanks again!
Josh
Hey Josh
My problem was with an Outlook signature and not with sending an html email from a tool like Campaing Monitor. Outlook seems to behave diferently when using the trick in an HTML signature.
I have found no solution for this...
Regards
Our ESP is Marketo and this problem is not yet solvable with Marketo. They strip out mso tags in the header. They say it will be solved in the October release, but they've been saying that since May.
This feature is now available for activation upon request in Marketo. Soon it will be released to everyone! Yay!
Thanks so much for sharing this discovery and fix.
I need help with this issue please. I'm a newb to html coding and having difficulty understanding where to insert this fix.
Below is the html code I'm working with. The issue I'm having is it is image based and it showing up reformatted images out of place and alignment for a few people when viewing it in Outlook 2013. Feel free to e-mail me at taylorzdpac@gmail.com
Hi there,
I seem to be having the same scaling/density problem with an email template posted by my ESP. I tried to apply the fix to the HTML but I'm not having any luck. Probably because I don't completely understand what I'm doing. The email looks pretty much fine on a phone, but terrible in Outlook 13. Can someone check out the HTML below and tell me what I did wrong to try to fix it at 96px?
Looking briefly at your email code it has several validation errors, so I would fix those first. The main errors are:
<td style="background-color:#5d7b9a; mso-cellspacing: 5px; mso-padding-alt: 0px 0px 0px 0px; bgcolor="#5d7b9a">
I'd fix these first and then proceed to retest.
As a strong recommendation you should also consider making your images block elements and add width/height attributes.
To clarify, the issues with images in Outlook 2007 - 2013 on Windows is when DPI factors greater than 96 DPI (100% scaling) are in use. This is configured in Display properties via Control Panel from within Windows. If this doesn't match the conditions you are testing under, this isn't the problem you are having.
I've tried implementing those fixes to make our email images and tables render properly in outlook 120 DPI. Can anyone tell from the code what needs to be changed here?
https://litmus.com/builder/documents/3197633
Hello
I was so happy to find this post until I tried to make it works. I don't knox why but my image doesn't scale on 125% or 150% DPI Windows 7, 8 computer.
Table is scaling but not the image.
Here's the very simple code I did :
The image is a 180x150px jpg @ 96dpi
Maybe I missed something?
Thank you for your help
I know for me it works when I don't put the inline height or width on images in the td. And it might be overkill, but on all my tables I put the width. Good luck!
Hello Veronica and thank you for your answer. I tried your suggestion, but it stil doesn"t work:
Here are results:
outlook 2013 - windows text 100%


outlook 2013 - windows text 150%
I took a look at your code and the width and height look like they are still in the td with the image: http://screencast.com/t/ldekJuaP
And for the table with the 180 width I normally put the non percentage widths in the style designating it as px. Thanks!
I put your code into the Litmus Builder here; https://litmus.com/builder/59de4e5
And the Litmus Preview is here; https://litmus.com/pub/9e33caf
Not sure if that is what you are looking for?
(Oh and I "borrowed" the styles from a Litmus email - they are SO helpful!)
Thank you so much Veronica.
I copied &pasted your code but the image is still not scaling in Outlook!
this is geting me crasy ;-)
Here's a pic of what I get:

I have juste done a test on Litmus and the image scaling is ok : https://litmus.com/pub/c8a675f
My guess is that as I set my html template as an Outlook signature, Outlook is modifying on some way the code before sending. Table, td ans text are scaling but not images...
Don't know how to deal with that...
This is great and worked for me!!! Thank you!!!
This thread is golden, thanks.
Thank you for sharing !
Unfortunately, I am still experiencing issues with the code when tested in Outlook 2007. The images are not being displayed when I apply the code to my email.
The images in my email are all uploaded on Amazon S3. The image URL's are all absolute links as far as their source.
I'm not sure why this is happening.
Hey Ralph,
I was having that problem until I made the changes to the td's and tables as listed above by some wonderful email peeps!
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.
Use inline styles for pixel widths and heights.
Still need height attribute for Gmail.
Do not need the height or width on the td of an image.
By doing that I have not had any problems reported.
Good luck!
VW
Hi Veronica,
I am still experiencing issues when the email is viewed in Outlook 2007 for a 150% DPI even after applying the changes noted above. Below is the code for my email.
Outlook 2007 behaves differently with images when using the conditional code originally discovered by Michael. If you look at a conversation Veronica and myself had regarding an email template she had, I discovered the key difference of what happens when you set certain PPI values with
o:PixelsPerInch
in Outlook 2007 with images at 100% and 125% scaling (150% is likely to be the same also), in short you can't fix it, because its how the Outlook 2007 engine works with this.You can't develop a specific conditional for Outlook 2007 either, because you'd end up breaking the appearance of images for one side of the user base, clients using 96 DPI or clients with larger scaling factors due to the inconsistent behaviour demonstrated in my discussion with Veronica.
In Outlook 2010 and Outlook 2013, Microsoft changed the behaviour where this fix will work as described across all scaling factors. The title of this thread is a little deceptive, because it wasn't discovered Outlook 2007 works differently till later on.
You can only mitigate the issue by designing your layout to gracefully stretch, to avoid any issues with images "breaking" out of the constrained layout, other than that, images can't be fixed completely in Outlook 2007. You can still perform the other fixes mentioned to make widths/height correct render, these work consistently with the various Word Engine versions.
Are you saying that using the following code won't work? I'm slightly confused by your recent comment.
I realized that I am not referencing any .PNG image files and updated to .GIF files. Below is the modified code for my email.
Could you take a look and see what is happening? The images that are a part of the main body of the email seems to be breaking the layout. Is there some sort of way to target only Outlook 2007 when the DPI is larger than 96 using conditional comments or CSS styles?
Thanks!
Apologies if my recent comment confused you. Yes the code "works", but Outlook 2007 handles it differently.
See my comment here, where I test what each of the common values for
o:PixelsPerInch
does on higher scaling factors with Outlook 2007, I compared 100% to 125%, but I'm pretty sure 150% scaling will be the same as well.https://litmus.com/community/discussions/151-mystery-solved-dpi-scaling-in-outlook-2007-2013#comment-1986
I am referring to the fact that setting the value of
o:PixelsPerInch
to 96 with Outlook 2007 will not behave in the same way as newer versions of Outlook. Notice how the value 96 DPI causes images to actually be increased, on 120% scaling, when this normalises everything on Outlook 2010 and 2013. This is purely down to how the Outlook 2007 was designed, and cannot be changed, but Microsoft did change it in Outlook 2010.You cannot sadly, conditionally set the
o:PixelsPerInch
value based on if the user is using normal DPI or scaling factors greater than 100%, that is way beyond the scope of conditional comments, and is not possible to detect via any other means.This issue is specifically with Outlook 2007 and images, the rest of the original article is still valid i.e. declare width/height attributes as pixel width/height properties inline etc.
Bottom line: Images in Outlook 2007 on higher scaling factors are broke and not fixable without breaking either the normal DPI users view or the higher scaling factor users view. Again, depending on your design you can make the layout more friendly to expand if images are larger than expected, so you don't get the break out effect, but other than, you are out of luck.
James,
I have set up my html email with inline width and height attributes and it still does not work. Do you suggest the images than the 100% body of my email?
This is so fantastic I can't put it into words! The only thing is that I am having the same problem with Gmail on a Mac - any ideas there? As the Outlook ones worked like a charm!!!
Thanks!
VW
I have no idea what could be causing that, you might want to post your code and some screenshots. Best I can suggest is to wrap your content in a min-width div:
This should prevent gmail from crunching your tables.
Hey Nice information Michael Muscat you guys are awesome "Litmus". ;)
But in my opinion you can't used height every where. Height to be flexible always.
Thank you for this! The code worked perfectly, however I did adjust the mso styles to reflect 0px.
I have DPI issue. I have tried the option what you people suggested above. I hope anyone can review my code and guide what are the ways I can fix this?
Screenshot: https://imgur.com/a/1oVQf
Hey Kevin - Some things I've found helpful in the past:
At least in the past, something about AllowPNG was seen to enable the Windows Display Scaling setting to kick in.
Hey Kevin, here is what currently works for me. Since my ESP strips out the xmlns strings, I had to heavily test and troubleshoot to solve it.
My ESP adds this doctype, but I do not test with it in Litmus:
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
I do not use any VML code.
Make sure to use both html and inline css dimensions on ALL fixed size structural elements – td and table – so that Outlook can convert them to points and scale them for the 125% display; the html dimension is still best practice for some gmail iterations – <table width="100" style="width:100px;">. Do this for every element that has a fixed width.
Your code above has a table with width="600" but not the additional css width added.
Structural elements with variable widths (%) do not need css widths
For images, I only use html dimensions and do not add css widths, they scale fine in Outlook 2010+; media queries override these dimensions for small screens.
I have lots of examples with this technique that preview great in Litmus and in Outlook 2007-2016.
Running into an issue with the first step of the fix (defining height/width in the td). Declaring the width and height on the TD/TH seems to compromise the mobile responsive version on iOS/Android by artificially forcing the height. I can't think of a nice way to undo that in mobile. :(
Still my issue not fixed
Tried using classes on the TD/TH to make it 100% width in mobile devices? If not then it will the place to start.
FInally added these techniques to my default email templates, appreciate the help from the community! All is working as intended on high DPI set up now.
How does one control the font size? Turns out after a recent test, a few recipients had DPI scaling turned on causing the font size in the navigation bar to increase and butt up against each another.
Can anybody tell me what the values in these attributes do? Are they supposed to translate to "neutral" values in non MSO clients? Or are they just placeholders for whatever I might happen to need?
Thanks
Thanks Its works for me :)
Very helpful post and comment thread. I've tested the image scaling solution with Outlook 2016 on a high DPI machine, and I can confirm it works.
But what if I want to develop templates to send from Outlook? Outlook seems determined to strip out the XML conditional magic listed above.
Hey Matt,
See my comments here (https://litmus.com/community/discussions/151-mystery-solved-dpi-scaling-in-outlook-2007-2013#comment-5713) and here (http://answers.microsoft.com/en-us/office/forum/office_2013_release-outlook/images-in-an-html-email-signature-getting-enlarged/8876b819-4637-4064-88e9-9dcc981b82af?page=2&tab=question&status=AllReplies#tabs)
The standards normally outlined for solving these design issues seem to be only useful for the case of an HTML email that is not be rendered prior to sending - this would be the case for a mass email marketing service. I've been dealing with this issue from the perspective of just the email signature, but the same restrictions that you've called out apply - these standard practices aren't as helpful when the content you've designed is displayed by an email client for composing, before the send happens. In this case, the content of the email design is at the mercy of the hardware and operating system of the user. Things like Windows' Display Scaling can distort assets, and some email clients (cough Outlook cough) love to parse/rewrite/mangle HTML in a body or signature template.
Unfortunately, I think the true answers to these types of issues lie in the ability of email client developers (MS, Google, Apple, Mozilla, etc) to provide support for rich HTML & CSS in templates, to correct for the effects of hardware/software conflicts (ie: pixel-density compensation), and to not alter the markup of any customized templates that are used in personal email composition.
Thanks for the reply, Sam. Sounds like we’ll need to find another workaround if we want our templates to look decent when sending via Outlook. Our goal now is just to make sure the received email doesn't look broken (even if it does look a bit different).
Consistency is definitely the goal here, but I agree that even looking "mostly okay" after sending would be a great start. If you come across any potential solutions or workarounds, I'd love to hear about it!
Leaving this here just in case it might help someone else... I've found that the image scaling bug only seems to affect images whose wrapping is set to 'in line with text.' Set the wrapping to 'square' or 'top and bottom', and Outlook seems to respect the image size on both the sender and recipient end.
Hi Matt, we also send lots of email from Outlook within our company as well as outside, and this image scaling is killing us! I just cannot wrap my head around the idea that MS chose to physically resample images larger in order for someone to see them larger.
Our process is to lay out a message in html, open the page in IE and send page by email—this gives is the page as an email (with beautiful MS coding helpfulness). Save the message, then save as an OFT (Outlook file template) so that someone else can send it. So you're saying that touching this image wrap setting in Outlook before saving will solve it? I'm going to test it, then hopefully do some running cartwheels.
Hey Matt,
I did some testing with the image wrap settings and didn't have much success. However, I'm working with Outlook signature files that have image tags with external URLs as the source. I'm wondering if this makes the difference (compared to embedded images) in whether or not image-wrap settings affect the sizing.
I did find (totally on accident) some documentation on a registry setting in Windows that basically tells MS Word (the rendering engine that Outlook uses) to ignore the system Display Scaling settings: https://support.microsoft.com/en-us/kb/3042197
I've found that creating this registry value has some positive effects. When composing an email, images do appear on the sender's machine as enlarged, if they have Display Scaling enabled. However, regardless of the Display Scaling percentage, images viewed by the recipient are shown at their native size. I don't have any knowledge yet on how this setting affects the MS Word experience.
While there are some trust issues with not being able to see the images correctly during composition, I think that's an easier problem to deal with, compared to the risk of recipients seeing images that are heavily blown up.
Hi Matt, this plagued us for a while too. Our solution was to build our email templates without any widths or heights on anything except images. It's a bit old-school, you have to go back to laying out tables with 1px white gifs, but Outlook changes all these emails to be inline when you send and then scales them nicely with the fonts, so all scales correctly. Only thing is when someone on a high DPI sends to someone on a low DPI the whole email will be 33% bigger and the images will be stretched (stretched proportionally so layout is fine, but quality is low). Sending from Low to High is fine.