Home » Newsletter » October 2008

By V. Subhash

Many of our software components are designed in such a way that they can be used in both Windows forms and Web forms. However, you may not be able to readily substitute a desktop application with a Web-based one.

Limitations are imposed by Web application model works rather than something to do with our products.

Here is a typical example paraphrased from a query received from a trial user.

I have a Web application (C#, ASP.NET) to generate PDFs but in order to print to the local printer, the user needs to download the file, open it, and then print to local default printer. Is it possible for me to directly print to the local default printer instead of having the user open the pdf and then print?

It seems like a legitimate requirement. It can be easily implemented in a two-tier client-server desktop application but not on a Web application. To explain why, you need to know how the Web application model works.

Who is in charge? Where is all the action?

On the server side, Web applications can do just about anything you may want them to do. They can read and write files, send e-mail, print files, ... just like regular desktop applications.

On the client side, Web pages (that's just what Web applications are inside a browser) run under a lot of restrictions. They cannot read files - leave alone writing to files. They cannot print nor can they send e-mail. Why?

Because nobody wants them to run like that. If web pages could read files on their visitors' computers, then that will be considered as a serious security violation. People would stop using the Internet!

So, web pages run inside a sandbox implemented by the browser. Inside this sandbox, a web page can do some gimmicks with the page contents and maybe read from or write to a cookie (the only file created by a browser at the request of a web page for reading and writing). There is little else that web pages can do. Put simply, Web pages cannot read or write files on the rest of your system.

"Now, wait a minute," you say. "How do I upload files, as e-mail attachments for example?"

When you upload a file through a web page, the action is always initiated by you, not by the web page. Even then, it is the browser that reads the file and directly uploads it to the server. The web page has no JavaScript for reading the files in your computer. And, the e-mail is sent from the server, not the client.

Web pages cannot read the system RAM, or access any other installed hardware or software.

Some web pages, particularly the printer-friendly ones, do bring up a Print dialog box. These web pages have a dumb window.print() Javascript command, which simply instructs the browser to bring up the dialog box. The web page or the server knows nothing about the printers connected to the computer. You get the dialog box even if you have no printer installed.

Even here, the browser sandbox model protects you from any unauthorized printing. You have to click on the Print or OK button to initiate the printing process. The browser puts you in control all the time.

Enter ActiveX, VBScript, and IE

To add more functionality to web pages, Microsoft brought support for ActiveX controls inside Internet Explorer. You could script ActiveX controls with VBScript* inside the browser, similar to what is available in Microsoft Word or Excel.

ActiveX earned a bad press over time. Even with signed ActiveX controls, it was a source of security vulnerabilities. For example, some years ago, some pranksters put Windows Media Player control in web pages and surprised visitors by ejecting their CD trays.

To make things worse, other browsers such as Netscape did not provide any ActiveX or VBScript support, as the technologies were considered proprietary. (However, half-hearted support for Flash and Shockwave from Adobe and Windows Media Player from Microsoft was available, even when they used OBJECT rather than EMBED tags.) Eventually, Microsoft had to scale down ActiveX support. Now, Internet Explorer flashes onerous warnings about scripts and ActiveX!

Bottom Line

What does this all mean? The answer is that it is not possible to do a lot with a Web application when the client is a browser. All desktop-like functionality can only be on the server, not on the client.

So, is there no solution for the trial user referred above? Sure, there is. Instead of writing a simple Web application, the user can choose to write a Web service and a desktop client that works with that Web service. Here is how they could be made to work.

1. The Web service will generate the PDF using a PDF creation tool such as
   • eDocEngine VCL,
   • eDocEngine ActiveX/.NET,
   • PDFOne .NET,
   • PDFOne Java, or
   • Print2eDoc SDK.
2. The web service will then send the dynamically generated PDF to the desktop client application using a standard HTTP-response binary-write method.
3. The client would use a PDF printer component from
   • PDFOne .NET,
   • PDFOne Java,
   • PDFtoolkit VCL, or
   • PDFtoolkit ActiveX/.NET
   to print the PDF to a local printer.

The requirement cannot be met if users want to merely work with a browser.

The solution is similar to an Internet-based video and voice chat application such as Yahoo! Messenger. The chat application does not run inside a browser. It has been created as a separate desktop application so that it can access the Web camera and the sound card, something that a web page cannot do. To work, the chat client interfaces with a chat service running on a Web server.

A move away from browser-based Web applications to a combination Web service plus desktop client applications is a straightforward answer.

Lately, top IT companies have sugested cross-platform alternatives such as Adobe Air, Google Gears, Microsoft SilverLight, and Mozilla Prizm. However, they differ greatly in terms of capability, maturity, and acceptance. Compatibility of the vast ecosystem of existing software components, many of which have been built over decades and have never been cross-platform, is another question mark hanging over them.

Update 1 (24-February-2015)

It has been six years since this article was written, and we continue to receive the same question over and over again. In the meantime, browsers have gained the ability to access the microphone and camera (with your conscious permission) and increased local storage. Our product lines and component mix have also changed. We now have ASP.NET and HTML5 controls that can display PDF content inside a web page without requiring Adobe Reader installed on the client. Apart from PDF, we our controls that can display other document formats (DOC, DOCX) and image formats unfamiliar to browsers (TIFF, EMF, WMF) inside a web page. These controls support client-side printing. (Go to DEMOS.GNOSTICE.COM to see for yourself.) But, the premise of this article still holds. All of these controls will show the end-user (at the client-side) a preview of the current document/image and the end-user has to consciously click on the OK button on the browser print dialog for printing on the local printer.

Update 2 (24-March-2015)

We published a new article showing how a web page can print a DOCX, DOC or PDF to a client-side printer without having to display the document. The demo web page has Print button but no document is shown. When the end-user clicks it, a Print dialog appears and the end-user selects a local printer for printing.

---o0O0o---

* - Even JavaScript can be used in place of VBScript.