Fog Creek Software
Discussion Board




Advice needed: printing from a web app

[Note: I posted this in the .Net discussion, but due to limited traffic and expanded scope, I'm re-posting it here.]

I have a VB6 app that I'd like to port to a web app, but I need to be able to print formatted labels to a local printer.  As far as I can tell I have 2-3 options:

1) Create & embed a .Net windows control.  Drawbacks:
* requires .Net framework on users' PC's.
* requires IE

2) Create & embed an ActiveX component.  Drawback:
* requires IE

3) Create a Java applet. Drawbacks:
* don't know if the sandbox will allow this.
* JVM version compatibility.

I've dabbled in each of these but am proficient with none.  Any advice which path I should go?

Thanks

anon
Monday, February 02, 2004

Believe printing from Flash is a lot better than it used to be. Make a RIA.

Flasher
Monday, February 02, 2004

To be honest, if I had to resort to using Flash just to print from a web app, I'd be shocked.  But mostly I'd be pissed off that the folks at MS and Sun hadn't provided for it.

anon
Monday, February 02, 2004

Write to PDF, get users to print that.

Almost Anonymous
Monday, February 02, 2004

I don't think PDF is feasible.  The users print to a small label printer (typically connected to an LPT port).  Some users might print hundreds of labels per day.  Adding the extra step of opening the PDF and printing it would be a major hassle for them.

anon
Monday, February 02, 2004

On a side note, printing straight HTML works fine for these labels.  The only problem is that the users might have a header and footer in their page setup.  If I could figure out a way to retrieve that, clear it, then reset it programmatically, then I'd be fine.  I searched for a way to do it in IE, but no luck.

anon
Monday, February 02, 2004

I'm a Java guy, so I don't know the steps of how you can "translate" this procedure to VB or ASP.NET, but I imagine it can be done.  I would write a servlet that can call the free iText library (http://www.lowagie.com/iText/), and stream the resulting PDF with a content type of "application/pdf".  Under IE and Mozilla (in Windows and Linux), this would automatically open Acrobat Reader in the web browser, where printing is just a click away...

I just noticed a C# port of iText here:  http://itextsharp.sourceforge.net/ .

joev
Monday, February 02, 2004

These thin clients are so cool, aren't they?

Simon Lucy
Monday, February 02, 2004

"I don't think PDF is feasible.  The users print to a small label printer (typically connected to an LPT port).  Some users might print hundreds of labels per day.  Adding the extra step of opening the PDF and printing it would be a major hassle for them."

You're basically out of luck.  You can't reasonably print from a web applications.  If printing is such a huge function of your application, then it's best to leave it as a fat client.

Almost Anonymous
Monday, February 02, 2004

Take a look at the Office Web Components - I don't know if they solve your problem. Downside is that users need Word installed.

Personally, I'd say commit to users needing the .Net framework and go with a browser-deployed winforms app.

Philo

Philo
Monday, February 02, 2004

Assuming fat client (I'm not clear about your issue with user's setting a header & footer on the label printer) you still haven't given enough info to decide if .NET or ActiveX is best.

Seems like ActiveX might be an easier port from your existing VB6 app and fewer dependencies for the client


Monday, February 02, 2004

CSS has some pretty good elements for printing, like page breaks. 

In IE there are 2 issues with printing, margins, and footers/headers, neither can be set by the incoming script.  I wish this statement was false and would love to be proven wrong.

Margins are especially annoying, b/c there seems to be no standard for the minimums across different IE installations, and this isn't an attribute you can set in the IEAK.

Christopher Hester
Monday, February 02, 2004

Try StyleSheets.  Here is a good link for some info.

(Specifically Printing)
http://www.yourhtmlsource.com/stylesheets/cssmediatypes.html


(All kinds of CSS topics)
http://www.yourhtmlsource.com/stylesheets/


Mike

MikeG
Monday, February 02, 2004

I ran into a problem like this a couple of years ago. My client wanted a web app, but no ActiveX stuff on the client side and wanted to print.

I create a web interface which would create printjobs in the database which were then exposed via xml-rpc. I wrote a little windows service in python which then queried the server every second to check for print jobs. It was a bit of a hack but it worked pretty well - we were printing labels as well.

Feel free to contact me if you have any questions.

Andrew Murray
Monday, February 02, 2004

We ran into somewhat of a similar problem at a gov't agency I worked for. Users wanted to have headers and footers auto-generated, as well as portrait or landscape set when they hit the button from the web page, regardless of what their settings were.

We found several options, but the one we chose was Scriptx from a company called meadco (www.meadco.com). The downside was that it required IE and a plugin (and cost money), but it allowed us to change headers, footers, page loayout, etc on the fly from a web page.

So it is definately do-able, but I think you will find it is a horrible mess to try to support all of the browsers if you use CSS or Javascript tricks.

Cory
Monday, February 02, 2004

>>2) Create & embed an ActiveX component.  Drawback: * requires IE

Considering that IE is used by 98% of Windows users, which themselves represent 95% of client hosts... is that really an issue?

FredF
Monday, February 02, 2004

anon,

It can be done, but you may not like my answer.  It's basically changing a couple of registry keys in client side script before you print and then saving back the original values. 

It requires elevated security privileges in IE though.  I added the local intranet into the trusted sites group under IE.

I'll try to dig up the code, but I'm guessing it's lost somewhere on my computer.

GuyINCOGNITO
Monday, February 02, 2004

http://support.microsoft.com/default.aspx?scid=kb;en-us;236777

GuyINCOGNITO
Monday, February 02, 2004

>>Considering that IE is used by 98% of Windows users, which themselves represent 95% of client hosts... is that really an issue?

No. But since I knew some Firebird/Mozilla/Opera zealot would mention it, I figure I would preemptively so I wouldn't have to read it in the responses.

As far as .Net vs. ActiveX, my main concern was the target machines.  This app will be used in manufacturing and warehouse environments.  As a rule of thumb, the PC's that sit on the manufacturing floor are often the oldest in the company.  Running a .Net app might grind them to a halt.

So on the face of it ActiveX would be a better choice.  But, if MS has made the development of Windows controls far easier than ActiveX, then I might just say screw it and go with .Net.

Looking at the default security setting for IE in the Local Intranet zone, .Net components are enabled whether they are signed or not.  But, the default settings for unsigned ActiveX components in the Intranet zone is disabled.  So, it would seem that .Net would eliminate the need to either get the component signed or have the users change their security settings for the Local Intranet.

anon
Tuesday, February 03, 2004

Perhaps a Java applet with the right setup?

This might help:
http://builder.com.com/5100-6370-1050757.html

I don't know if they used this method, but these guys seem to have a created Java solution as well (I didn't test it completely, as my Java version is apparently "insufficient". *sniff*).

http://www.kandasoft.com/javaprinter/JPrint.html

Chris Altmann
Tuesday, February 03, 2004

As you pointed out, old machines may well preclude .NET.

The reason .NET components don't need to be signed is "code access security" - by default they are in a sandbox and won't be allowed to do much (including printing!).  An administrator would have to enable access to client resources such as the printer, which he would normally only do for signed code.

Since you already have a VB6 implementation I suggest you go for ActiveX.

Joe
Tuesday, February 03, 2004

I've had really good luck with PDF.  You aren't going to force them to have an extra step of downloading and opening the file.  You're going to stream it right to their browser.  Much more practical.  There's a great library at http://www.pdflib.org

Clay Dowling
Tuesday, February 03, 2004

Is this web app going to be run in-house?  If so, the local printers can be made accessible from the network, and you could send the print job from the server.

T. Norman
Wednesday, February 04, 2004

*  Recent Topics

*  Fog Creek Home