I won’t lie to you, we’re Microsoft fans here… OK, that should’ve got rid of the annoying fanbois! The Redmond guys do a lot of great work, most of which goes under the radar, unnoticed and unappreciated. It’s easy to pick on the pack leader, but it doesn’t mean it’s all true. That said, too often they make decisions that, to put nicely, are hard to defend. One that caused quite a storm was the decision to use the Word 2007 HTML renderer in Outlook 2007 to render HTML emails.
Up until Office 2007, Outlook used the rendering engine from Internet Explorer to render HTML emails, but used Word to compose them. This meant that users would write an email in Outlook, cc’ing themselves, and what they got back looked different. Microsoft noticed this, and decided to do something about it. Fixing Word to output HTML in a standards compliant way would have been the logical choice, but not for Microsoft; it was much easier to render HTML emails in Word when received in Outlook.
For Outlook users, the result was a consistent experience, for email marketeers, it was a disaster – but who likes them anyway, bunch of spammers.
The result was a general avoidance of HTML in emails (beyond the simplest mark-up), and a descent into the dark ages, as can be seen from the examples from Campaign Monitor.
But, to be fair that’s Microsoft’s prerogative. They can write systems to be non-standards compliant, they can degrade functionality, and people have the right to vote with their feet. There’s no God-given right here to force them to be sensible, they’re a business, and just as our friends over at Apple prove consistently, you don’t need to play nice to win.
What gets on my nerves is when a Software company rights code that doesn’t work with their own products. That’s a bug! And the big problem for big M was the effect of the Outlook decision on SQL Server Reporting Services (SSRS). SSRS 2005 was a great success in the enterprise, and unsurprisingly it was increasingly being used to email rich reports throughout the enterprise and to customers.
These emails could contain graphs, pictures, all kinds of useful information, and companies lapped it up. But the output from SSRS 2005 did not display correctly in Microsoft Outlook 2007 – the client of choice in MS-enabled enterprise, and the largest revenue spinner for Microsoft itself. At this point, with large enterprises complaining about the pretty reports being broke, you’d think Microsoft would have a change of heart, but that would’ve been a big climb down. It might have been difficult to patch all those copies of Outlook out there, but I doubt it, changing the renderer from Word back to IE wouldn’t have been that difficult, ideally they would have fixed Word to be standards compliant – but that would have been prohibitively expensive, so I don’t blame them ducking that solution. The cheapest way was to patch the HTML Renderer in SSRS 2005, and that’s the route they chose and deployed in cumulative update package 10 for SQL Server 2005 Service Pack 2 (and later SP3). This update didn’t restore full HTML compatibility, it just stopped the tables shrinking, and so it didn’t look so bad.
No one was happy but at least it was better than the terrible shrinking column problem that was plaguing the SSRS community.
Now with the soon to be released Brease version 2, we’re leveraging some of the great enhancements added to SSRS 2008, where they’ve upgraded the Report Builder to be much more useable and feature rich – which is great for clients, for whom Visual Studio is a bit too feature rich. Imagine our horror when we discovered the shrinking columns problem had reoccurred? Clearly, when re-writing the HTML renderer in SSRS 2008, Microsoft had not included their previously released fix. Obviously we got on the phone and after several days came back a typically amusing, and standard, “we can’t reproduce it but here’s the fix…” response.
So for anyone else noticing that their SSRS 2008 reports are not rendering correctly in Outlook. Firstly you should upgrade to R2, as Microsoft have added a setting to the MHTML Device Information Setting and the HTML Device Information Setting called OutlookCompat (what??? you missed it???). The description of this field is “Indicates whether to render with extra metadata that makes the report look better in Outlook.”. The default value for MHTML is true, but for HTML it’s false so you have to explicitly set it.
So to fix the shrinking tables problem in SSRS 2008 R2, you need to edit the rsreportserver.config file in your installation (if you don’t know how, slowly back away from your computer and call your IT guy).
Look for the following XML –
<Extension Name="HTML" Type="Microsoft.ReportingServices.Rendering.HtmlRenderer.MHtmlRenderingExtension,Microsoft.ReportingServices.HtmlRendering"/>
And replace with the following –
<Extension Name="HTML" Type="Microsoft.ReportingServices.Rendering.HtmlRenderer.MHtmlRenderingExtension, Microsoft.ReportingServices.HtmlRendering"> <Configuration> <DeviceInfo> <OutlookCompat>TrueOutlookCompat> DeviceInfo> Configuration>Extension>
Alternatively, you can set the DeviceInfo OutlookCompat flag explicitly when rendering HTML that will ultimately be rendered in an email client. This will prevent the junk being output on all HTML that may only be destined for a browser.
I hope that helps some poor harassed developer out there who has a big Enterprise screaming down his neck after investing a fortune in upgrading to SSRS 2008! In the meantime, lets keep hoping that the trend being shown with IE9 represents a general softening of Microsoft towards standards compliance, and maybe, just maybe, Office 2014 will include a Word that loves HTML… you know, it might just happen!