Programmatically set printer, copy count, paper size, zoom, and other propeties for job

  • Thread starter Thread starter Bruce Hensley
  • Start date Start date
B

Bruce Hensley

We have a very large document management system containing PDF, TIF, Office,
and other format files. We would like to programmatically print from it
based on predefined print settings (destination printer, copy count, paper
size, zoom, etc) for each document. The code could be VBS, VB, VBA, WSH,
JavaScript, ASP, or other. Essentially, we would like to spawn a print job
from code and programmatically specify settings normally entered in the
Print>Properties dialog of most applications.

Any hints, ideas, code examples, or 3rd party utility recommendations would
be greatly appreciated.

Thanks,
Bruce
---------------------
Environment:
Win 2000 (servers and workstations)
IE 5.5
Office 2000
Acrobat and Reader 5
 
You will have to call various spooler APIs.

Towards the bottom of the documentation for DocumentProperties, it explains
how to make changes to print settings. Several steps must be followed. If
you do not follow these steps, some drivers will be unreliable:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/prntspol_7k1f.asp

What you are doing is creating and modifying a DEVMODE structure. You then
pass this to CreateDC to create a Device Context. You then pass that to
StartDoc.

With all the types of code you mention, you would have to write a DLL, for
example an automation server (formerly known as an OLE automation server,
it's a COM server) or an ISAPI application in the case of ASP.

I think that ASP.net can call the spooler APIs directly, I'm not sure. That
would be a question for one of the .net newsgroups.

If you are using 3rd party software to print, eg. Adobe Acrobat Reader to
print a PDF file, you may find that you cannot specify the print settings.

Paul
 
Paul,

Thanks! This is a good head start.

I see I wasn't clear ... when I listed all the types of code, I meant that
we only needed one solution in any one of them, not a solution for each.

The kludge I was considering before I got your note went along these lines
....

- temporarily set default printer to a print-to-file printer configuration

- print to file using InvokeVerb &Print to get the right print command based
on file association

- append PJL commands to the print file to set print parameters such as copy
count, paper size, and separators

- copy print file to printer

Using DEVMODE looks like a more solid solution.

Thanks again,
Bruce
 
Bruce,

WSH is a client solution. ASP is a server solution. So I'm not sure what
kind of situation you are talking about. Depending on what you are doing,
this may work for you:

Add a printer and set the Printing Defaults to the properties you want. Use
this printer. You can pass a printer name to Adobe Acrobat Reader using a
command line like this, thereby avoidiing having to temporarily change the
default printer:
C:\...\Acrord32.exe /t "<file name>" "<printer name>" WINSPOOL

I am not sure about other third party software that registers a "print" verb
for your documents.

This will work if you need to be able to specify print settings but there is
only one set of print settings. If you need to be able to specify print
settings on demand, you do need to use the print spooler API. The easiest
way to call a print spooler API is, of course, a standalone EXE. However,
*this* only works if you use the Device Context and print job you created
that are associated with the settings you want. If you pass it off to third
party software, they'll create their own DeviceContext and print job with
their own settings (most likely the defaults) and you didn't achieve
anything.

I guess there are a lot of unknowns here that it would be helpful for you to
clear up.

Paul
 
Paul,

Sorry to be so vague ... it's partly because we have a fairly controlled
environment (limited number of trained users, controlled workstation
configuration, limited set of target printers and configurations (page
size), limited number of filetypes ... pdf, tif, MS Office), and so we have
the luxury of being open to a number of solutions, e.g. either a client app
or server app will work for us.

The situation is a reproduction department printing documents for
distribution from a docbase. Although it can be different for each
document, the docbase knows the distribution requirements (e.g. who gets how
many copies of each document in each page size). Based on an external
administrative (non-electronic) trigger, a staff member would initiate
printing a specific doc for distribution, specifying the target printer.
The app would figure out the rest of the requirements (e.g. how many copies
of each size, recipient names to go on separators) based on the info in the
docbase, and then do the printing.

We had thought we could use the "printto" verb for each doc type (there's
one for each of the doc types we use) to specify the printer without needing
a separate routine for each doc type, but don't know how to specify the
additional parameters using InvokeVerb. So, we considered either changing
the default printer, as described, (in order to have a single routine) or
building a separate routine for each doc type based on the command in the
printto verb, as you suggest for pdf files.

On the third-party front, we thought there might be a utility that we could
call that did much of what we were after, e.g. SpecialPrint (FileToPrint,
Printer, CopyCount, PageSize, IncludeSeparator, TitleOnSeparator). If not,
we would build one using what we were considering, or what you have shared
with us. Then we could call it for each distribution instance.

Thanks again for your suggestions.

Bruce
 
Bruce,

This page is the closest I can find to an explanation of the "printto" verb:
http://msdn.microsoft.com/library/e...asics_extending/fileassociations/fa_verbs.asp

So the first parameter is the file name and the second is the printer name.
I don't know for sure, but I think that you can specify these parameters in
a call to ShellExecuteEx by appending them to lpFile.

ShellExecuteEx:
http://msdn.microsoft.com/library/d.../shell/reference/functions/shellexecuteex.asp

The shell uses the "printto" verb when you drag and drop a file to a
printer.

Depending on the kind of development you are doing, you may have difficulty
calling ShellExecuteEx. You might find it easier to run a command line. For
example, WSH has a WshShellObject with Exec and Run methods:
http://msdn.microsoft.com/library/d...script56/html/wsoriWshShellObjectPropMeth.asp

To determine the command line, look at File Types in Explorer and look at
the properties of the "printto" verb (and I already gave you the command
line for Acrobat Reader).

I would tend to make it a server so that you only have to install and
configure Acrobat Reader, Word, printers, etc. on one machine.

Paul
 
Bruce,
It sounds like our product, Virtual Port Monitor,
can satisfy a great deal of your requirements. The
post-print application feature runs the application
with most of the DEVMODE elements populated into the
environment. We also include a printto command which
can be used to copy files of selected extensions to
a printer icon via drag and drop, or programmatically
using rundll32.exe. Its free to evaluate. We also have
a VBS script along with an ASP page, available upon
request, to demonstrate these features.

http://www.alphatronics.com/AVPMon.html

Greg
 
Back
Top