Practical ASP.NET

Supporting a Printer-Friendly Page Button (Part 2)

Peter wraps up his solutions for getting junk off the page when the user wants to print out a copy. This time by working with Themes and JavaScript.

• By Peter Vogel
• 10/08/2009

In last week's column (Supporting a "Printer Friendly Page" Button: Part I), I posed the problem of how to create a printer-friendly version of a Web page. I assumed that this meant getting rid of most -- but not all -- of the stuff on your Master Page (copyright notices and legal disclaimers would have to remain, for instance). I also assumed that you'd want to offer this button on every page on your site, rather than have to deal with it on a case by case basis. The solution I proposed last week involved swapping in a new Master Page with the minimum number of controls on it at run time, when the user clicked on a "Printer Friendly Version" button. This week I'll look at two other solutions.

Use the Theme
My second solution is to swap in a different Theme rather than a different Master Page. The structure of this solution is the same as the Master Page solution I proposed last week, but with this code in the PreInit event.

Protected Sub Page_PreInit(ByVal sender As Object, _
    ByVal e As System.EventArgs) Handles Me.PreInit
        If Me.Request.QueryString("PrinterFriendly") = "True" Then
            Me.Theme = "PrintingDisplay"
        End If
End Sub

Here you'll want to create a new theme that uses CCS rules to remove items from your page or adjust their location. Your existing stylesheet is probably already controlling the appearance and placement of your controls so you just need to tweak those settings as part of creating your new theme. For instance, these two rules control the tags with the ID LogoImage (an Image control on my MasterPage) and Main (a ContentPlaceHolder control):

#LogoImageDiv {position: absolute; 
     left: 10; top: 30; 
     width: 175; height: 44 }
#MainPlaceHolderDiv {position: absolute; 
   left: 300; top: 175; 
   width: 400; height: 300 }

Here are the same two rules but the LogoImage rule now makes the Logo disappear and the ContentPlaceHolder rule moves it closer to the Page's upper left-hand corner:

#LogoImageDiv {visibility:hidden}
#MainPlaceHolderDiv{position: absolute; 
  left: 50; top: 50; 
  width: 400; height: 300 }

As with the Master Page solution, you'll need to keep your default and printer-friendly themes synchronized. At the very least, if you add anything to your Master Page that you don't want on your printer-friendly page, you'll need to update both stylesheets. Depending on the differences between your printer-friendly theme and your standard theme, this solution might be easier or harder to maintain than having a second Master Page. Unlike the Master Page solution, you can't add new controls to the printer-friendly version of the page.

Use JavaScript
My third solution is to add some JavaScript to your Master Page that does what the stylesheet in the previous solution does: make some items disappear and others move around. The JavaScript equivalent to the CSS in my previous example would look like this:

‹script type="text/javascript"›
        function PrinterFriendly() 
        {
            var logo = document.getElementById("LogoImageDiv");
            var main = document.getElementById("MainPlaceHolderDiv");
            logo.style.visibility = "hidden";
            main.style.left = 50;
            main.style.top = 50;
        }
‹/script›

To give the user the ability to trigger the JavaScript, you'd drag an HTML Input Button onto the page and set its onclick attribute to the name of your JavaScript function:

‹input id="PrinterFriendly" type="button" value="button" 
            onclick="return PrinterFriendly()" /›

In many ways this solution is the best of the three that I've presented, as it doesn't require a trip to the server to redisplay the page. Furthermore, the whole solution is encapsulated within the master file and doesn't require another file to be added to the site. You will still have some synchronization work: As items are added or removed from the Master Page, the JavaScript will need to be updated. And the JavaScript is sufficiently simple that even a JavaScript-phobic developer like me can probably work with it.

However, because you are using client-side code, you do need to recognize that executing JavaScript is browser dependent (though this code ran successfully in IE 7 and FireFox 3.0). Unlike the Theme-based solution, there is a penalty for removing controls from the Master page. Your stylesheets won't mind having a rule with no corresponding control, but JavaScript code will fail if you remove a control it's trying to modify.