A PrinterJob is a job and a DocPrintJob is a job
So you created a PrinterJob, set some properties on that job and then a
DocPrinterJob and expect
the job properties to migrate from one to the other ?
I would not expect that to work as they are distinct jobs. Moreover
dpj.print(Doc, PrintJRequestAttributeSet)
clearly provides the properties such as copies in that second argument.
Are you expecting (hoping) that " pj.setCopies(2)" some how sets printer
defaults ?
Sorry, bu that has to be done through an administration dialog somewhere
in Windows.
-phil.
On 7/19/2011 2:39 PM, Patrick Reinhart wrote:
Hi there,
I have a question considering the relation between the "old"
PrinterJob and the "new" PrintService:
Should the job settings (for example amount of copies or the job name)
be held only within the PrinterJob and not be passed to the
PrinterService as set by PrinterJob.setPrintService(PrintService)?
Here's a small szenario for my question:
The following code is beeing executed by the customer:
> PrintService ps = xx //lookup thru
PrintServiceLookup.lookupPrintServices() method
> PrinterJob pj = PrinterJob.getPrinterJob();
> pj.setPrinterService(ps);
> pj.setCopies(2);
> pj.setJobName("theTestJob");
> pj.print();
When the print() method is called, the following methods where called
on the PrintService returned by the lookup:
> ps.createDocPrintJob()
and finally on the DocPrintJob:
> dpj.print(Doc, PrintJRequestAttributeSet)
Now: Why does the print request attribute set not contain the Copies
attribute? Is this not intended or a bug?
Thanks for some more explanation, I would like to help as soon I
understand the correct behavior..
Regards
Patrick
