The superclass does check that the service will (claims to) support
printable/pageable.
I've looked at what we did in the implementation when it comes to print
which
is that for such a custom service we implicitly head it off to the
javax.print API
so it probably could work.
But the dialog code probably does need to be tweaked to always invoke
the cross-platform dialog in this case. Right now its bailing from native
only if it sees a StreamPrintService.
So line 560 and maybe line 590 should be
if (!(service instanceof Win32PrintService)) ...
pageDialog() needs similar treatment.
Try those and see if you get sensible behaviour when showing the dialog.
-phil.
On 6/17/2013 2:00 PM, Patrick Reinhart wrote:
Hi Phil,
What irritates me though is the fact, that there is no check for the
support/not support of 2D printing and also that the PrinterException
does not reflect the described cases of the spec:
java.awt.print.PrinterException: Invalid name of PrintService.
I can not see any relation to one of the referred cases of the spec:
The spec. for PrinterJob.setPrintService() says :-
*Throws:*
|PrinterException
<http://docs.oracle.com/javase/6/docs/api/java/awt/print/PrinterException.html>|
- if the specified service does not support 2D printing,
or this PrinterJob class does not support setting a 2D print
service,
or the specified service is otherwise not a valid print service.
So an exception is expected.
If I understand your fix you want to change it so that WPrinterJob
simply
doesn't go down to native so is less specific about what Service it will
accept? But WPrinterJob is completely tied to Win32PrintService
and windows native printing. The Windows print dialog for example
will know nothing about your service.
So this seems like not a bug. You should just use javax.print APIs in
this case.
Well in my case I had the plan to capture the printer interaction for
testing reasons instead of using real printers. In my case a 3th party
product was using the setPrintService() method internally, where I did
not have the possibility of using the javax.print API in this case.
Also irritating was the fact, that under Linux the same method call
behaved not the same, in fact there it worked without any problem.
Also it seems to be no problem if the print service is of type
StreamPrintService where it does more or less the same as my supposed
fix. So it can not be tied that completely to the WIn32PrintService.
Cheers Patrick
-phil.
On 6/15/2013 8:19 AM, Patrick Reinhart wrote:
Could someone review my fix?
http://reinharts.dyndns.org/6870661/webrev.00
Cheers
Patrick
On 06/11/2013 10:32 PM, Patrick Reinhart wrote:
Hi Phil,
I just started looking into this Bug and have already written a
test to prove a later fix though. As it seems that there missing
two checks make sure, that the actual PrintService is a instance of
W32PrintService before passing it to the native method
setNativePrintService()
Fix proposal for this bug is as follows:
http://reinharts.dyndns.org/6870661/webrev.00
Can you take a look into it and give me some feedback on it.
Unfortunally I did not get the Jtreg test running under Windows
(executing it as plain Java application at least does work)
Cheers
Patrick
