I'm in the process of rewriting a kiosk application. It was originally written in C#.Net as a Windows app. We want make it web based so it can be available to people with laptops, iPhones, iPads, etc. in addition to the dedicated kiosks.

The problem is that printer output is necessary, and it seems that for security reasons, browsers do not allow direct printing. I need some help to at least understand the kinds of approaches that would work.

Here are my assumptions and requirements:

• The server can be platform specific, and is capable of generating the information to be printed (HTML, JSON, XML, PDF, Whatever).
• All client software must be cross-platform (Linux, Windows, Mac, PDA).
• All client software must be cross-browser (OK to limit to HTML5).
• Client software is preferred to be open-source.
• It's ok to assume printing on a default printer.
• Printing must be automatic, with no printer dialog allowed.

I've spent about 10 hours so far researching possible solutions. I have come up with a couple of possibilities, but there are certain parts I don't know how to do yet.

Rather than lengthen this post, I'd like to invite ideas first. Someone may come up with something better than what I have thought of, that may get lost if the conversation gets started in a specific direction. I'll post my concepts in a day or two if no better ideas show up first.

I would suggest doing the printing via a plugin that you would write using a technology with printing support. Java (signed applet) or Silverlight would do it.

Can a plug-in be created that would work in all browsers? (See 3rd bullet point in original post) Or would I have to write one for each potential browser?

Thanks for your reply.

yes and no, browsers differ in how they handle plug-ins and each browser has a different API, so while you don't have to write a 'different' plug-in for each browser you would have to create a 'port' of that plug-in for each browser that is to say re-write the parts that actually interact with the browser and perhaps the operating system, however the main logic most likely could remain the same.

You would definitely not have to write a different plugin for each browser. PDAs might be a problem, but if your plugin is in Java then none of the other platforms you listed would be.

Cross-browser compatibility is one of the reasons that Java applets were invented in the first place.

Each browser does not have a different API. Both Silverlight applications (which are plugins) and Java applets (which are plugins) have access to the DOMs of the webpages they are embedded in. DOM representations are standard. (Which is not to say all browsers follow standards and that no testing is necessary, of course).

The only interacting you'll do with the operating system is print. You will not have to rewrite that for each platform.

If you're talking about differences beyond these then I need an example.

Thanks. This gives me something to digest over the weekend. I'm starting to like this suggestion, even through I have no idea yet how to write a plug-in.

Would the plugin need to be installed on each client machine?

Isn't Silverlight MS proprietary?

Plugins are loaded from the server. They're embedded in the HTML pretty much the same way images are.

And yes, Silverlight is proprietary. There's also an open source implementation called Moonlight. I would personally pick Java over either.

Adobe Flex (used for writing business applications as Flash plugins) is another possibility (because it supports printing). It's proprietary too.

Any server-initiated access to a printer that happens without human intervention would be seen by me as a huge security vulnerability. If you do get that working, please tell us all so we can see to it that the browsers you use to do that get fixed. Imagine what fun net-vandals would have using all of your printer paper/toner/ink without your approval.
--- rod.

@theNombr: This is how Java addresses the issue you brought up:

http://stackoverflow.com/questions/4.../438589#438589

It's also definitely capable of printing without displaying a "print setup" dialog (I just checked).

Sure, I can set up something and grant it permission to print. That's my definition of user intervention.
--- rod.

um no, Plug-ins are NOT loaded from the server or embedded in the html, the content handled by the plugin IS, but the plugin itself is on the client and is operating system/browser specific.
in linux, plugins (such as the flash plugin for instance) have a .so extension and are ELF binaries, in windows they are probably dll files. they are at the very least, operating system specific, but then again there are also browser add-ons such as firebug which are browser sepecific.

True. What I obviously meant was to recommend writing "content" that would be handled by the plugin. For example, a Java applet. Which would be handled by the JRE plugin.