Community Forum

Over the years we have built up a community of email marketers, coders and designers that live and breathe email.

Use the Email on Acid Forum like your virtual water cooler: Stop by to discuss email code, quirky clients and fixes and post your issues (with an example of the code) for our community to offer its assistance.

 
   
Outlook 2010 (120dpi) & Outlook 2013 (120dpi) - Grrrr

DavidBoyland

Newbie
Total Posts:  5
Posted: 25 September 2016 09:18 PM

Hi,

I’m having a very difficult time getting these two email clients playing ball.
I’ve attached two EOA screenshots of how my HTML is showing in 2010 and 2013 120 dpi.

I believe I’ve done all the changes I can make to make this pixel perfect as possible.
But hopefully someone can suggest other fixes that I’ve not considered.
Please see tester.html for an example of the markup I’m using.

Many thanks,
Kieran

Image Attachments
outlook-2010-120dpi.jpgoutlook-2013-120dpi.jpg
File Attachments
tester.html  (File Size: 6KB - Downloads: 99)

 

Alex Ilhan

Avatar
Administrator
Total Posts:  203
Posted: 25 September 2016 11:09 PM
[ # 1 ]

Hi David,

Welcome to the Email on Acid forums!

Could you please describe to me what you’re trying to achieve with this code? Judging from the information you’ve provided thus far, I believe I can help you code it in a slightly different way that makes it more “bulletproof”.

Let me know your thoughts!

Cheers
Alex.


 

DavidBoyland

Newbie
Total Posts:  5
Posted: 25 September 2016 11:31 PM
[ # 2 ]

Thanks for coming back to me Alex.

What I need is the 3 column tables to be accurately 99 pixels in height.
At the minute, the 2nd and 3rd column appear to be growing in size somehow.

I’m not interested obscuring the height difference.
I really need it pixel perfect due to the way we build our emails.

It is so close and consistent in all the other Outlooks, except the two 120dpi versions stated.


 

DavidBoyland

Newbie
Total Posts:  5
Posted: 26 September 2016 12:03 AM
[ # 3 ]

For info, I’ve also tried the following with no changes in the previews whatsoever:

<td bgcolor=”#005486” width=“200” height=“11” style=“width:200px; height:11px; font-size:0px; line-height:11px;”> </td>

vs

<td bgcolor=”#005486” width=“200” height=“11” style=“width:200px; height:11px; font-size:0px; line-height:0;”>espacerOUTLOOK.png</td>

Will keep trying other bits, I’m trying to remain hopeful that this is possible.


 

DavidBoyland

Newbie
Total Posts:  5
Posted: 26 September 2016 03:41 AM
[ # 4 ]

My HTML was stripped in that earlier reply, I basically tried using nbsp vs a spacer image within a cell.
Wondered whether it could be related to font rendering, but sadly both showed the same results in Outlook 120dpi.

After more investigating, we found this is most likely an issue rounding up a bad integer.

I’ve attached another HTML example which shows exactly the same problem in the 120dpi Outlooks.

The same rounding up issue also occurs when zooming to 125% in Chrome (Blink engine).
NOTE: You must have a normal resolution monitor to see this problem in the Chrome browser.

Android 4.4.4, Android 5.1.0 and Android Gmail App are other mail clients which shows this exact rounding up issue as well.

Anyone seen this before?
Know of anything we could try adding to the HTML to make this work?

File Attachments
smallestv3.html  (File Size: 9KB - Downloads: 78)

 

Alex Ilhan

Avatar
Administrator
Total Posts:  203
Posted: 26 September 2016 11:51 PM
[ # 5 ]

Hi David,

I suspected it would be the DPI scaling. I’d suggest taking a look at this amazing blog by James White which should cover what you need: https://blog.jmwhite.co.uk/2014/03/28/solving-dpi-scaling-issues-with-html-email-in-outlook/

Let me know if you have any questions or concerns!

Cheers,
Alex


 

DavidBoyland

Newbie
Total Posts:  5
Posted: 27 September 2016 12:54 AM
[ # 6 ]

Thank Alex - I’ve read the article thoroughly but it doesn’t help unfortunately.

Our problem is quite unique.
Most emails are built to allow room for this type of rounding problem.
But since we require absolute pixel accuracy, we will have to figure out methods of hiding it.

It doesn’t seem like this problem is solvable, but thanks for looking anyway.