[OpenJDK 2D-Dev] RFR 6870661 : Setting a custom PrintService on a PrinterJob leads to a PrinterException

[Phil Race]

Yes, the driverDoes* fields should be reset, even though
I am not sure we need them any more because I think
that ever since XP drivers always do their own collation.
But some of this code was written when win9x/win nt was supported.


@run main/manual=yesno
Can be used to write a manual test for dialogs.

The test then generally has to have a window with instructions in it,
and the tester has to tell the harness if it passed based on understanding
and following the instructions.

-phil.


On 6/18/2013 2:04 PM, Patrick Reinhart wrote:
> Hi Phil,
>
> I will do the suggested changes and check the dialog and enhance my 
> test accordingly.
>
> Do you think that the fields driverDoesMultipleCopies and 
> driverDoesCollation should be reset on setPrintService() as follows, 
> because the actual native settings will be obsolete in that case anyway?
>
>
> @@ -587,11 +586,11 @@
>      public void setPrintService(PrintService service)
>          throws PrinterException {
>          super.setPrintService(service);
> -        if (service instanceof StreamPrintService) {
> +        driverDoesMultipleCopies = false;
> +        driverDoesCollation = false;
> +        if (!(service instanceof Win32PrintService)) {
>              return;
>          }
> -        driverDoesMultipleCopies = false;
> -        driverDoesCollation = false;
>          setNativePrintService(service.getName());
>      }
>
>
> At last could you give me a hint, how you do a test for dialogs with 
> Jtreg?
>
> Cheers
>
> Patrick
>
> Am 17.06.13 23:51, schrieb Phil Race:
>> 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
>>>
>