Matt Esch

Printing VML and other printing bugs with IE8

By Matt|browsers, javascript|Be the first to comment!

My aim was to make an OpenLayers map control printable. In IE8, OpenLayers uses uses a VML-based renderer to render the vector features.

The first issue I came across was that VML does not print in IE8 the VML in OpenLayers does not always print.

How do I get VML to print?

This hasn’t worked for me with OpenLayers, perhaps relating to the way the layers work with relatively positioned div elements. But if you want to get a basic VML diagram printing you have to do the following

1. The VML namespace should be added to the document before attempting to print VML. This should be used in conjunction with the behavior CSS rule below.

   document.namespaces.add('v', 'urn:schemas-microsoft-com:vml');

   
   

2. To make VML printable you have to add a behavior CSS rule to the VML elements. Raphael achieves this by adding a class to all VML elements and then adding the behavior rule for that class

   doc.createStyleSheet().addRule(".rvml", "behavior:url(#default#VML)");

What if it doesn’t work?

If this doesn’t resolve your issues, as it doesn’t with OpenLayers, and you cannot avoid VML by using a better tool (such as the pure DOM/CSS renderer I am working on), you have three alternatives;

• Force the page into IE7 compatibility mode
• Rasterise the objects to an image on the server side
• Or produce a document such as a PDF that can be printed later.

After seeing that IE7 standards would not provide a sufficient solution (due to changing the JavaScript engine), and noting that providing a PDF does not create a seamless print solution, I opted to produce an image of the OpenLayers control which can be injected into the page at print time. The image is produced using wkhtmltoimage on the server side and is injected at print time by attaching handlers to window.onbeforeprint (to inject the image into the page), and window.onafterprint (to return the DOM to its previous state). These are proprietary events of IE8 that are actually quite useful. These events execute very quickly as they trigger between the data processing. So, onbeforeprint fires before any print processing begins, and as soon as the page is ready for printing, i.e. the print preview or the print dialog becomes available, the onafterprint event fires and the document is ready print. This is nice because the page is not rendered between the events, and so no sign of this hack appears in the solution. It’s completely transparent.

A PDF can just as easily be produced using wkhtmltopdf, but this could be difficult if you haven’t completely encapsulated your entire page state and can reproduce it in another browser. In my case I had encapsulated the state of an OpenLayers control, so producing an image of it was fairly straight forward. However do note that if you want to read the data from stdout on Windows, you may notice that the binary data is a bit messed up if this bug hasn’t been addressed yet. It turns out that \n is translated to \r\n when wkhtmltoimage outputs to stdout. It’s not too hard to undo this, but hopefully this will be fixed soon.

Other anomalies in printing

Ok so that’s was one problem fixed. Now there are reports of other random printing bugs relating to pages containing a lot of data. IE8 just crashes. IE9 in IE8 standards mode works fine, but *real* IE8 crashes when trying to print pages containing large amounts of data. This may be resolved by removing any hidden DOM elements that are on the page. (We have 5 tabs containing memory-hungry images). I thought I would implement a generic solution that traverses the DOM and removes any hidden elements, and a function for returning them back to their original location. Equipped with the before/after print events, we should be able to seamlessly remove elements from the DOM and add them back again when the user wishes to print the page.

(function () {
 
    var invisible;
 
    function removeInvisible() {
        var e = document.body.firstChild,
            next,
            p,
            remove;
 
        invisible = [];
 
        while (e) {
            if (e.style && (e.style.display === 'none' || e.style.visibility === 'hidden')) {
                invisible.push({ parent: e.parentNode, child: e, next: e.nextSibling });
                next = e.nextSibling || null;
                remove = true;
            } else {
                next = e.firstChild || e.nextSibling || null;
                remove = false;
            }
 
            if (!next) {
                p = e;
                do {
                    p = p.parentNode;
                    next = p.nextSibling;
                } while (!next && p.parentNode !== document.documentElement);
            }
 
            if (remove) {
                e.parentNode.removeChild(e);
            }
 
            e = next;
        }
    }
 
    function appendInvisible() {
        var a, i;
        for (i = invisible.length - 1; i >= 0; i -= 1) {
            a = invisible[i];
            a.parent.insertBefore(a.child, a.next);
        }
        invisible = [];
    }
 
    window.onbeforeprint = removeInvisible;
    window.onafterprint = appendInvisible;
 
}());

Unfortunately, removing the hidden elements did not solve the printing bugs in our case, but it may be useful in general. (Forcing IE7 mode was actually the successful choice in this case).

On further investigation I also found other print bugs with IE8, such as DXImageTransform used with the filter property does not work. I’ve not yet seen a solution to this problem either, and I am inclined to believe it cannot be solved. The simpleCanvas library I have been working on was relying on the ability to print rotated div elements and images without the use of VML, but will have to fall back to server-side rasterisation if I want to provide this functionality in IE8.

I guess the best I can say is that IE8 is not designed for modern web applications, and this rather lengthy account of the problems I have experienced just trying to get the browser to print are a testament to this point. By modern standards the browser is incredibly slow, filled with odd proprietary features and very unique bugs that will of course never be resolved.

Libraries like jQuery convince us that trying to write web applications for IE8 is achievable with no additional time cost, but this is merely an illusion. Trying to support non-trivial sites in IE8 will cost you a fair amount of development time, and the results may not even justify the cost considering the significant performance issues with IE8. In the mean time you will have a lot of code specifically for supporting old browsers slowing down your site across all browsers, and you will be reluctant to use any modern features in case there is no easy option for backward compatibility.

Refusing to provide your IE8 users with anything at all isn’t really acceptable, but it requires a tiered approach. In general I favour the 2 versions approach; a limited fallback site for IE8 and any other older browser, which encourages users to upgrade to a sensible modern browser, and a full blown version that only works on the latest browsers. You should save the best experience for the users with the sense to upgrade their browsers, (or the IT departments with the sense to upgrade), and don’t waste your time trying to support advanced features in such a tricky browser.