Over the past two years, I have had the pleasure of fixing two issues with printing from Internet Explorer 9. Both of the problems deal with IE-specific “filter” attributes in CSS. We have an application that is used by an audience that deals with a lot of paperwork. They like to print information from our application to add to their paper files, so it is important that printing functionality works well across the browsers used by most of our users.
Problem #1: Opacity and scaling
Part of our application behaves like a single-page app – the primary content switches without changing the URL of the page. When printing, everything but the primary content is hidden, and most styles on the page are reset to be quite plain. Our application was also written, at the time, using jQuery 1.3.2. Every time the primary content changes, the div that houses the content fades out, and fades back in with new information. This was accomplished with a jquery animation on the opacty, much like this:
$('#mydiv').fadeOut();
...
$('#mydiv').fadeIn();
IE 6-9 users reported issues where some of the text would be “blurry”. We were able to finally reproduce the issue on one of our virtual machines, and sure enough, the text on the page would be blurry when printed. It looked like the page had been saved as a low resolution image, and then resampled to a much higher resolution using a very bad scaling algorithm. I copied all of the HTML and CSS into a static HTML file, and it would print fine. I gradually added all of our scripts in, and sure enough, when the fading animation was added, the “blurry” effect would show up in the print preview. It turns out that the issue lies in ClearType. As is explained on the blog dauid.us:
Animating text with JavaScript (especially in jQuery) overrides the ClearType feature by telling the browser to display each step of the pixel throughout animation. When the animation completes, its left displaying the final step without ClearType enabled, leaving the text looking a bit crappy. Functions like fadeIn() and fadeOut() usually trigger the override and cause the pixel problems.
The bug was fixed in jQuery 1.7, according to this ticket. We ultimately were able to upgrade our application to 1.7, and printing worked once again for our IE users.
Problem #2: Gradient backgrounds
A new problem popped up a few weeks ago. Most of our IE users are on version 10 these days, but we do have some still using 8 or 9. A handful of these users reported issues with printing “not being on the page”. IE10 worked, so I fired up an old VM, and indeed, IE9 looked horrible. I was able to dig through version control, and sure enough, there was a global CSS change applied around the time we started to get reports of problems. When printing, the content would produce a single page (pretty common for our use case), where the area within the margins was a grey to lighter gray vertical gradient. The primary content itself was shifted to about 33% left of the printed page, and up about 25%, such that most of the text was actually off-page. The master stylesheet had been recently changed slightly, adding a SASS-generated gradient background to the html element. It rendered several vendor-prefixes (not pictured below), as well as a filter for IE9 and below.
html
{
background:linear-gradient(#d4dae0192px,#f3f5f8545px) 100% 191px no-repeat,#00749d;
filter:progid:DXImageTransform.Microsoft.gradient(startColorstr='#d4dae0',endColorstr='#f3f5f8',GradientType=0);
}
Without dealing with the master CSS file, we were able to add a new !important directive to our print-specific CSS file that fixed this issue:
body,html{
margin:0!important;
padding:0!important;
background:none!important;
filer:none!important;/* Added */
}
The lesson from these two instances? If you need to print from IE, don’t use CSS filters. Or, if you do, be sure to reset them in your print CSS. In retrospect, the simpler solution would likely be:
@media print {
* {
filter:none!important;
}
}