Client-side printing ?

[Jurjen de Groot]

I'm about to start a new ASP.NET application, this application will
generate several types of documents (PDF HTML XML-DOC) wich have to be
printed at the client-side... (probably on different printers A3 and A4
type)
At this time I'm trying to figure out what would be the best way to
accomplish this :

1. printing through HTML in a IE windows will result in page title &
nr as header and URL + Date as footer, wich is far from acceptable. Problem
with HTML is also that (as far as I know) there's no 'page-break' command,
so how do I accomplish making a HTML-document wich prints neatly every
letter on a new page without it being a new IE of HTML editor for every
letter, then the user would have to confirm each print-out.

2. Printing by way of streaming for instance PDF or XML-DOC to the
client will impose a burden on the client since the user will have to do
extra handling, accepting the download (or accidentally pressing save), and
printing the document by the selecting the right printer (and possibly
paper-tray in case of pre-printed paper), wich is also not acceptable.

3. One other way I can think of is creating a little winforms app
hiding in the system-tray wich is polling via webservice for instance for
documents needed to be printed, and then downloading and printing these
documents to pre-defined printers (and trays). But that would mean that
every pc using the ASP.NET application would have to have to .NET framework
+ the client print-application installed which almost nullifies the
advantage of the ASP.NET application being available on 'any machine with
internet connection'.

Any thoughts ....

Jurjen.

[Hans Kesting]

Jurjen de Groot wrote:

1. printing through HTML in a IE windows will result in page
title & nr as header and URL + Date as footer, wich is far from
acceptable. Problem with HTML is also that (as far as I know) there's
no 'page-break' command, so how do I accomplish making a
HTML-document wich prints neatly every letter on a new page without
it being a new IE of HTML editor for every letter, then the user
would have to confirm each print-out.

There is a css-command: page-break-after, which forces a pagebreak when printing.

see http://msdn.microsoft.com/workshop/author/ dhtml/reference/properties/pagebreakafter.asp

Hans Kesting

[Anand[MVP]]

A possible work around could be to use a ActiveX Control/Windows Forms
control. This will autoinstall on the client, though you may have to have
extra privileges/manual intervention the first time.

Once the control is installed, it can directly interact with the printer
etc. This can be a viable compromise between using a full fledged windows app
and inadequacies of IE based printing.

--
Rgds,
Anand
VB.NET MVP
http://www.dotnetindia.com
"Jurjen de Groot" wrote:

I'm about to start a new ASP.NET application, this application will
generate several types of documents (PDF HTML XML-DOC) wich have to be
printed at the client-side... (probably on different printers A3 and A4
type)
At this time I'm trying to figure out what would be the best way to
accomplish this :

1. printing through HTML in a IE windows will result in page title &
nr as header and URL + Date as footer, wich is far from acceptable. Problem
with HTML is also that (as far as I know) there's no 'page-break' command,
so how do I accomplish making a HTML-document wich prints neatly every
letter on a new page without it being a new IE of HTML editor for every
letter, then the user would have to confirm each print-out.

2. Printing by way of streaming for instance PDF or XML-DOC to the
client will impose a burden on the client since the user will have to do
extra handling, accepting the download (or accidentally pressing save), and
printing the document by the selecting the right printer (and possibly
paper-tray in case of pre-printed paper), wich is also not acceptable.

3. One other way I can think of is creating a little winforms app
hiding in the system-tray wich is polling via webservice for instance for
documents needed to be printed, and then downloading and printing these
documents to pre-defined printers (and trays). But that would mean that
every pc using the ASP.NET application would have to have to .NET framework
+ the client print-application installed which almost nullifies the
advantage of the ASP.NET application being available on 'any machine with
internet connection'.

Any thoughts ....

Jurjen.