Malek's Moorish Tales

Meanderings about life and technology

Web printing, an interesting way out ...

I have many times encountered the issue of allowing people to print some content from a web form, and usually the answer is one of the following painful and not very convincing solutions :

  • ActiveX : having an activeX component handle the printing of the info on the page . This is just one more thing from the COM deployment hell era ...
  • PDF : giving a link to a dynamically generated PDF has been, for quite some time, the best way out of the issue. most users do have a PdfReader, and it works ... the problem here is simply that you need server side processing of the info into a Pdf document, while the Pdf document is not part of the process at all (unless there is a requirement to let people save the doc whithout being able to modify it) ... this is a return to the Pluming era ...

Well, the main problem here is to be able to act on the client side, and do some rich functionnality ... wait a minute, there is something called Zero Touch Deployment, is there ?

The problem is, you are not supporting client that don't have a .Net Framework installed ... but, isn't that like Pdf ? the only difference is that .Net is newer, and is not on most people's machines, and does not even exist for many operating systems (yet). Well, I am lucky, because when I look at statistics of browser usage in Morocco (At least if I can trust the most visited portals), more than 95% of all internet users have machines with Windows 9x and up. Unix/Linux users are marginal, and pre-Windows 95 almost non existant ... I guess it is one time one has to be vicious, and pull out some scheme to make those users install CLR, and printing has made a great job of driving adoption of Pdf ...

So, here is the scheme : Have a smart client app that gets the info in HTML or XML (with XSLT) through a web service, and print it on the client. put that up on some highly visited site, where printing is an important functionality. Then, on the Web Pages, just test if the client has CLR , and if not(and is runing windows), redirect (with all due respect and info that he needs to install an app to be able to use printing) to .Net Framework redistribuatble installation (With code access security settings that will permit execution and printing, once again after having notified the user). Once the client has CLR, just redirect to smart client app, and pass the necessary request params that will allow the web service to retrieve the document.

Wait a minute, I tried to do this, but there is no way to pass params to the smart client app. Url formating will not let you pass command line args. If you pass request params, you have two issues : retrieving those params, and you can do that in different ways :

Environment.GetCommandLineArgs()  or  Environment.CommandLine

AppDomain.CurrentDomain.domain.GetData("APP_LAUNCH_URL")

That will give you the full Url, and you can parse it to get back your params. The problem now is that you have made the WebService proxy go crazy. It will try to see if there is a config file (for some obscur reason), and will be using your Url and appeding .config to it, and there is no way out. Not quite so,  thanks to Chris Sells and his article on msdn. You can add an HttpHandler to the application serving your smart client, so that it handles the .exe, and the .config...

There, you have completed the trick, and good luck hunting unCLRed clients ...

Add comment

biuquote
  • Comment
  • Preview
Loading