[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-2d-dev
Subject:    Re: [OpenJDK 2D-Dev] RFR 6870661 : Setting a custom PrintService on a PrinterJob leads to a PrinterE
From:       Patrick Reinhart <patrick () reini ! net>
Date:       2013-06-25 21:11:56
Message-ID: 51CA079C.6040002 () reini ! net
[Download RAW message or body]

Hi Phil,

Did not hear from you lately, had you got the time to look into my 
supposed fix?

Cheers

Patrick

Am 19.06.13 22:40, schrieb Patrick Reinhart:
> Hi Phil,
>
> I implemented your suggested changes in the class WPrinterJob now. I 
> also created a simple test for showing a print dialog after register 
> the custom PrintService on the PrintServiceLookup class and setting it 
> to the PrinterJob using setPrintService().
>
> http://reinharts.dyndns.org/6870661/webrev.01/
>
> According to the manual test. I did found different implementations 
> where sometimes the instructions where just printed to the console and 
> others where a applet was used. Could you point me out a existing test 
> where it is done the way you want it to be?
>
> Cheers
>
> Patrick
>
>
>
> On 06/18/2013 11:35 PM, Phil Race wrote:
>> 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.
>

[prev in list] [next in list] [prev in thread] [next in thread]