From sergey.bylokhov at oracle.com  Wed Mar  1 18:37:37 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 1 Mar 2017 21:37:37 +0300
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8176046 Replace package.html
 files with package-info.java in the java.desktop module
Message-ID: <A4C406E9-1C33-4E86-B36D-76B57C023F9D@oracle.com>

Hello,
Please review the fix for jdk9. This is the last request which covers all packages in java.desktop(except javax.swing and java.awt which were covered earlier)
 - All "package.html" files were replaced by "package-info.java", even for internal packages like eawt.
 - All <tag> were replaced by {@tag }.
 - All files were manually reformatted - 80 chars per line.
 - <sup><font size="-2">TM</font></sup> was replaced by &trade; This is why the specdiff contains some diffs.

Bug: https://bugs.openjdk.java.net/browse/JDK-8176046
Webrev can be found at: http://cr.openjdk.java.net/~serb/8176046/webrev.00/
Specdiff: http://cr.openjdk.java.net/~serb/8176046/specdiff/overview-summary.html

From alexandr.scherbatiy at oracle.com  Fri Mar  3 16:15:42 2017
From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy)
Date: Fri, 3 Mar 2017 19:15:42 +0300
Subject: [OpenJDK 2D-Dev] <Swing Dev> [9] Review Request: 8176046
 Replace package.html files with package-info.java in the java.desktop
 module
In-Reply-To: <A4C406E9-1C33-4E86-B36D-76B57C023F9D@oracle.com>
References: <A4C406E9-1C33-4E86-B36D-76B57C023F9D@oracle.com>
Message-ID: <3df4087c-7290-5e55-236a-5707ac50be50@oracle.com>

The fix looks good to me.

Thanks,
Alexandr.

On 3/1/2017 9:37 PM, Sergey Bylokhov wrote:
> Hello,
> Please review the fix for jdk9. This is the last request which covers all packages in java.desktop(except javax.swing and java.awt which were covered earlier)
>   - All "package.html" files were replaced by "package-info.java", even for internal packages like eawt.
>   - All <tag> were replaced by {@tag }.
>   - All files were manually reformatted - 80 chars per line.
>   - <sup><font size="-2">TM</font></sup> was replaced by &trade; This is why the specdiff contains some diffs.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8176046
> Webrev can be found at: http://cr.openjdk.java.net/~serb/8176046/webrev.00/
> Specdiff: http://cr.openjdk.java.net/~serb/8176046/specdiff/overview-summary.html



From sergey.bylokhov at oracle.com  Sun Mar  5 18:20:23 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Sun, 5 Mar 2017 21:20:23 +0300
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8152683 Deadlock when resuming
 from sleep with different monitor setup
Message-ID: <660D8F36-5EDE-4F5E-B986-E48330938D75@oracle.com>

Hello,
Please review the fix for jdk9.

Bug: https://bugs.openjdk.java.net/browse/JDK-8152683
Webrev can be found at: http://cr.openjdk.java.net/~serb/8152683/webrev.00/

In the fix we update the mainDisplayId when the list of displays are updated on Appkit thread, instead of reading it each time from the different threads. No new issues were found by jck and jtreg tests.

The fix was contributed by Karl von Randow <karl at xk72.com>:
[1] http://mail.openjdk.java.net/pipermail/2d-dev/2017-January/008087.html



From vadim.pakhnushev at oracle.com  Mon Mar  6 18:20:45 2017
From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev)
Date: Mon, 6 Mar 2017 21:20:45 +0300
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8152683 Deadlock when
 resuming from sleep with different monitor setup
In-Reply-To: <660D8F36-5EDE-4F5E-B986-E48330938D75@oracle.com>
References: <660D8F36-5EDE-4F5E-B986-E48330938D75@oracle.com>
Message-ID: <67e24fcb-6ddf-a479-f463-ad4b4c0232e0@oracle.com>

Looks good.

Vadim

On 05.03.2017 21:20, Sergey Bylokhov wrote:
> Hello,
> Please review the fix for jdk9.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8152683
> Webrev can be found at: http://cr.openjdk.java.net/~serb/8152683/webrev.00/
>
> In the fix we update the mainDisplayId when the list of displays are updated on Appkit thread, instead of reading it each time from the different threads. No new issues were found by jck and jtreg tests.
>
> The fix was contributed by Karl von Randow <karl at xk72.com>:
> [1] http://mail.openjdk.java.net/pipermail/2d-dev/2017-January/008087.html
>



From philip.race at oracle.com  Fri Mar 10 22:26:57 2017
From: philip.race at oracle.com (Phil Race)
Date: Fri, 10 Mar 2017 14:26:57 -0800
Subject: [OpenJDK 2D-Dev] RFR: 8088395: Print dialogs are not blocking/modal
 w.r.t specified owner windows
Message-ID: <2c022a82-abb3-ac14-3393-6f618f29f419@oracle.com>

This has an FX bug + webrev :
https://bugs.openjdk.java.net/browse/JDK-8088395
http://cr.openjdk.java.net/~prr/8088395/index.html 
<http://cr.openjdk.java.net/%7Eprr/8088395/index.html>

and also a JDK-side fix and webrev :-
https://bugs.openjdk.java.net/browse/JDK-8176530
http://cr.openjdk.java.net/~prr/8176350/

The problem is FX modal dialogs are ignoring the Window parameter.
We can fix the problem with disabling the modal parent on the FX side
and that is why most files in FX are updated.

But it does not fix the "on top" issue which requires the JDK fixes and
to pass in the DialogOnTop private attribute.
The JDK code is there solely for FX and won't have any visibility
unless FX passes in the private attribute.

On Linux it uses the standard AWT "always on top" modality
On windows it uses the HWND for the FX window and windows native modality
On Mac you won't see anything since Mac does this automatically

-phil.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20170310/75de50d5/attachment.html>

From prasanta.sadhukhan at oracle.com  Mon Mar 13 06:49:38 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Mon, 13 Mar 2017 12:19:38 +0530
Subject: [OpenJDK 2D-Dev] [9] JDK-8176287 :[macosx] The print test crashed
	with Nimbus L&F
Message-ID: <cd19de59-2d2c-9e0b-a553-6e83102abdfd@oracle.com>

Hi All,

Please review a jck print test crash fix for jdk9. The issue was seen 
with only Nimbus L&F which seems to use Linear gradient path
and not in other L&F (such as Aqua) .

Bug: https://bugs.openjdk.java.net/browse/JDK-8176287
webrev: http://cr.openjdk.java.net/~psadhukhan/8176287/webrev.00/

Linear Gradient path collects the gradient colors and fractions values 
in native obtained from Java and allocates several arrays to store the 
same in setupGradient() method.
It seems even after being freed, in subsequent call to the same gradient 
path routine, it may get the same allocated pointer the next time the 
array is allocated causing it to crash citing "memory being modified 
after freed".

Optimise setupGradient() method to allocate fewer pointer. The JCK test 
works now.
Also, the JDK-8162796 testcase LinearGradientPrintingTest and 
RadialGradientPrintingTest works with this optimisation.

Regards
Prasanta


From philip.race at oracle.com  Tue Mar 14 04:54:12 2017
From: philip.race at oracle.com (Philip Race)
Date: Mon, 13 Mar 2017 21:54:12 -0700
Subject: [OpenJDK 2D-Dev] [9] JDK-8176287 :[macosx] The print test
 crashed with Nimbus L&F
In-Reply-To: <cd19de59-2d2c-9e0b-a553-6e83102abdfd@oracle.com>
References: <cd19de59-2d2c-9e0b-a553-6e83102abdfd@oracle.com>
Message-ID: <58C77774.90600@oracle.com>

The problem seems to have been that you were allocating zero bytes in 
the old code :

  950         CGFloat* colors= (CGFloat*)calloc(0, sizeof(CGFloat)*length);


960         qsdo->gradientInfo->colordata = (CGFloat*)calloc(0, sizeof(CGFloat)*4*length);

Regarding the new code, whilst it seems like it fixes the problem I have a nit

937             int i;
  938             for (i=0; i<length; i++)

Since this code appears at the start of a block I'd expect all compilers 
to be happy with
   for (int i=0; i<length; i++)

is this not so ? Assuming yes, pls fix before push.

Also I wonder if the regression test we created for LGP passes only 
because it is "short".
Perhaps later we can improve on that.

The fix will also need to be backported since the original fix was 
backported.

So "+1" with those comments ..

-phil.

On 3/12/17, 11:49 PM, Prasanta Sadhukhan wrote:
> Hi All,
>
> Please review a jck print test crash fix for jdk9. The issue was seen 
> with only Nimbus L&F which seems to use Linear gradient path
> and not in other L&F (such as Aqua) .
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8176287
> webrev: http://cr.openjdk.java.net/~psadhukhan/8176287/webrev.00/
>
> Linear Gradient path collects the gradient colors and fractions values 
> in native obtained from Java and allocates several arrays to store the 
> same in setupGradient() method.
> It seems even after being freed, in subsequent call to the same 
> gradient path routine, it may get the same allocated pointer the next 
> time the array is allocated causing it to crash citing "memory being 
> modified after freed".
>
> Optimise setupGradient() method to allocate fewer pointer. The JCK 
> test works now.
> Also, the JDK-8162796 testcase LinearGradientPrintingTest and 
> RadialGradientPrintingTest works with this optimisation.
>
> Regards
> Prasanta
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20170313/7c4a4cae/attachment.html>

From prasanta.sadhukhan at oracle.com  Tue Mar 14 05:14:15 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Tue, 14 Mar 2017 10:44:15 +0530
Subject: [OpenJDK 2D-Dev] [9] JDK-8176287 :[macosx] The print test
 crashed with Nimbus L&F
In-Reply-To: <58C77774.90600@oracle.com>
References: <cd19de59-2d2c-9e0b-a553-6e83102abdfd@oracle.com>
 <58C77774.90600@oracle.com>
Message-ID: <3238af15-a7fc-836d-b5d1-e64e8676087b@oracle.com>



On 3/14/2017 10:24 AM, Philip Race wrote:
> The problem seems to have been that you were allocating zero bytes in 
> the old code :
> 950 CGFloat* colors= (CGFloat*)calloc(0, sizeof(CGFloat)*length);
> 960 qsdo->gradientInfo->colordata = (CGFloat*)calloc(0, 
> sizeof(CGFloat)*4*length); Regarding the new code, whilst it seems 
> like it fixes the problem I have a nit
> 937             int i;
>  938             for (i=0; i<length; i++)
>
> Since this code appears at the start of a block I'd expect all 
> compilers to be happy with
>   for (int i=0; i<length; i++)
>
> is this not so ? Assuming yes, pls fix before push.
Yes, it should be ok. I got a problem with jdk8u JPRT build (during 
earlier backport) citing C99 compiler failure but I guess that was 
because variable was declared not at blockstart.
Will again do a JPRT and if its ok, I will push with this change.
>
> Also I wonder if the regression test we created for LGP passes only 
> because it is "short".
> Perhaps later we can improve on that.
>
> The fix will also need to be backported since the original fix was 
> backported.
>
ok.
> So "+1" with those comments ..
>
Thanks

Regards
Prasanta
> -phil.
>
> On 3/12/17, 11:49 PM, Prasanta Sadhukhan wrote:
>> Hi All,
>>
>> Please review a jck print test crash fix for jdk9. The issue was seen 
>> with only Nimbus L&F which seems to use Linear gradient path
>> and not in other L&F (such as Aqua) .
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8176287
>> webrev: http://cr.openjdk.java.net/~psadhukhan/8176287/webrev.00/
>>
>> Linear Gradient path collects the gradient colors and fractions 
>> values in native obtained from Java and allocates several arrays to 
>> store the same in setupGradient() method.
>> It seems even after being freed, in subsequent call to the same 
>> gradient path routine, it may get the same allocated pointer the next 
>> time the array is allocated causing it to crash citing "memory being 
>> modified after freed".
>>
>> Optimise setupGradient() method to allocate fewer pointer. The JCK 
>> test works now.
>> Also, the JDK-8162796 testcase LinearGradientPrintingTest and 
>> RadialGradientPrintingTest works with this optimisation.
>>
>> Regards
>> Prasanta

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20170314/82248d12/attachment.html>

From philip.race at oracle.com  Tue Mar 14 05:17:45 2017
From: philip.race at oracle.com (Philip Race)
Date: Mon, 13 Mar 2017 22:17:45 -0700
Subject: [OpenJDK 2D-Dev] [9] JDK-8176287 :[macosx] The print test
 crashed with Nimbus L&F
In-Reply-To: <3238af15-a7fc-836d-b5d1-e64e8676087b@oracle.com>
References: <cd19de59-2d2c-9e0b-a553-6e83102abdfd@oracle.com>
 <58C77774.90600@oracle.com> <3238af15-a7fc-836d-b5d1-e64e8676087b@oracle.com>
Message-ID: <58C77CF9.4070908@oracle.com>



On 3/13/17, 10:14 PM, Prasanta Sadhukhan wrote:
>
>
>
> On 3/14/2017 10:24 AM, Philip Race wrote:
>> The problem seems to have been that you were allocating zero bytes in 
>> the old code :
>>   950         CGFloat* colors= (CGFloat*)calloc(0, sizeof(CGFloat)*length);
>>
>> 960         qsdo->gradientInfo->colordata = (CGFloat*)calloc(0, sizeof(CGFloat)*4*length);
>>
>> Regarding the new code, whilst it seems like it fixes the problem I have a nit
>> 937             int i;
>>  938             for (i=0; i<length; i++)
>>
>> Since this code appears at the start of a block I'd expect all 
>> compilers to be happy with
>>   for (int i=0; i<length; i++)
>>
>> is this not so ? Assuming yes, pls fix before push.
> Yes, it should be ok. I got a problem with jdk8u JPRT build (during 
> earlier backport) citing C99 compiler failure but I guess that was 
> because variable was declared not at blockstart.
> Will again do a JPRT and if its ok, I will push with this change.

Testing the 8u backport via JPRT is good since that will use VS2010 which
wins the "most likely to barf" award on such an issue.

-phil
>>
>> Also I wonder if the regression test we created for LGP passes only 
>> because it is "short".
>> Perhaps later we can improve on that.
>>
>> The fix will also need to be backported since the original fix was 
>> backported.
>>
> ok.
>> So "+1" with those comments ..
>>
> Thanks
>
> Regards
> Prasanta
>> -phil.
>>
>> On 3/12/17, 11:49 PM, Prasanta Sadhukhan wrote:
>>> Hi All,
>>>
>>> Please review a jck print test crash fix for jdk9. The issue was 
>>> seen with only Nimbus L&F which seems to use Linear gradient path
>>> and not in other L&F (such as Aqua) .
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8176287
>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8176287/webrev.00/
>>>
>>> Linear Gradient path collects the gradient colors and fractions 
>>> values in native obtained from Java and allocates several arrays to 
>>> store the same in setupGradient() method.
>>> It seems even after being freed, in subsequent call to the same 
>>> gradient path routine, it may get the same allocated pointer the 
>>> next time the array is allocated causing it to crash citing "memory 
>>> being modified after freed".
>>>
>>> Optimise setupGradient() method to allocate fewer pointer. The JCK 
>>> test works now.
>>> Also, the JDK-8162796 testcase LinearGradientPrintingTest and 
>>> RadialGradientPrintingTest works with this optimisation.
>>>
>>> Regards
>>> Prasanta
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20170313/6c8745d4/attachment.html>

From prasanta.sadhukhan at oracle.com  Tue Mar 14 09:31:27 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Tue, 14 Mar 2017 15:01:27 +0530
Subject: [OpenJDK 2D-Dev] [9] JDK-8176287 :[macosx] The print test
 crashed with Nimbus L&F
In-Reply-To: <58C77CF9.4070908@oracle.com>
References: <cd19de59-2d2c-9e0b-a553-6e83102abdfd@oracle.com>
 <58C77774.90600@oracle.com> <3238af15-a7fc-836d-b5d1-e64e8676087b@oracle.com>
 <58C77CF9.4070908@oracle.com>
Message-ID: <0bd81696-1e17-9321-30ae-d414d9a279a0@oracle.com>

JPRT 8u build resulted in failure, so I had to modify at 2 other places.

QuartzSurfaceData.m:287 and QuartzSurfaceData.m:328

Other things remains same.
http://cr.openjdk.java.net/~psadhukhan/8176287/webrev.01/

Regards
Prasanta
On 3/14/2017 10:47 AM, Philip Race wrote:
>
>
> On 3/13/17, 10:14 PM, Prasanta Sadhukhan wrote:
>>
>>
>>
>> On 3/14/2017 10:24 AM, Philip Race wrote:
>>> The problem seems to have been that you were allocating zero bytes 
>>> in the old code :
>>> 950 CGFloat* colors= (CGFloat*)calloc(0, sizeof(CGFloat)*length);
>>> 960 qsdo->gradientInfo->colordata = (CGFloat*)calloc(0, 
>>> sizeof(CGFloat)*4*length); Regarding the new code, whilst it seems 
>>> like it fixes the problem I have a nit
>>> 937             int i;
>>>  938             for (i=0; i<length; i++)
>>>
>>> Since this code appears at the start of a block I'd expect all 
>>> compilers to be happy with
>>>   for (int i=0; i<length; i++)
>>>
>>> is this not so ? Assuming yes, pls fix before push.
>> Yes, it should be ok. I got a problem with jdk8u JPRT build (during 
>> earlier backport) citing C99 compiler failure but I guess that was 
>> because variable was declared not at blockstart.
>> Will again do a JPRT and if its ok, I will push with this change.
>
> Testing the 8u backport via JPRT is good since that will use VS2010 which
> wins the "most likely to barf" award on such an issue.
>
> -phil
>>>
>>> Also I wonder if the regression test we created for LGP passes only 
>>> because it is "short".
>>> Perhaps later we can improve on that.
>>>
>>> The fix will also need to be backported since the original fix was 
>>> backported.
>>>
>> ok.
>>> So "+1" with those comments ..
>>>
>> Thanks
>>
>> Regards
>> Prasanta
>>> -phil.
>>>
>>> On 3/12/17, 11:49 PM, Prasanta Sadhukhan wrote:
>>>> Hi All,
>>>>
>>>> Please review a jck print test crash fix for jdk9. The issue was 
>>>> seen with only Nimbus L&F which seems to use Linear gradient path
>>>> and not in other L&F (such as Aqua) .
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8176287
>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8176287/webrev.00/
>>>>
>>>> Linear Gradient path collects the gradient colors and fractions 
>>>> values in native obtained from Java and allocates several arrays to 
>>>> store the same in setupGradient() method.
>>>> It seems even after being freed, in subsequent call to the same 
>>>> gradient path routine, it may get the same allocated pointer the 
>>>> next time the array is allocated causing it to crash citing "memory 
>>>> being modified after freed".
>>>>
>>>> Optimise setupGradient() method to allocate fewer pointer. The JCK 
>>>> test works now.
>>>> Also, the JDK-8162796 testcase LinearGradientPrintingTest and 
>>>> RadialGradientPrintingTest works with this optimisation.
>>>>
>>>> Regards
>>>> Prasanta
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20170314/2f966d4f/attachment.html>

From prasanta.sadhukhan at oracle.com  Tue Mar 14 11:25:50 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Tue, 14 Mar 2017 16:55:50 +0530
Subject: [OpenJDK 2D-Dev] RFR: 8088395: Print dialogs are not
 blocking/modal w.r.t specified owner windows
In-Reply-To: <2c022a82-abb3-ac14-3393-6f618f29f419@oracle.com>
References: <2c022a82-abb3-ac14-3393-6f618f29f419@oracle.com>
Message-ID: <1a4e6e78-a526-c195-dee1-532aef0902da@oracle.com>

Looks ok to me.

Regards
Prasanta
On 3/11/2017 3:56 AM, Phil Race wrote:
> This has an FX bug + webrev :
> https://bugs.openjdk.java.net/browse/JDK-8088395
> http://cr.openjdk.java.net/~prr/8088395/index.html 
> <http://cr.openjdk.java.net/%7Eprr/8088395/index.html>
>
> and also a JDK-side fix and webrev :-
> https://bugs.openjdk.java.net/browse/JDK-8176530
> http://cr.openjdk.java.net/~prr/8176350/
>
> The problem is FX modal dialogs are ignoring the Window parameter.
> We can fix the problem with disabling the modal parent on the FX side
> and that is why most files in FX are updated.
>
> But it does not fix the "on top" issue which requires the JDK fixes and
> to pass in the DialogOnTop private attribute.
> The JDK code is there solely for FX and won't have any visibility
> unless FX passes in the private attribute.
>
> On Linux it uses the standard AWT "always on top" modality
> On windows it uses the HWND for the FX window and windows native modality
> On Mac you won't see anything since Mac does this automatically
>
> -phil.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20170314/c2056cc6/attachment.html>

From philip.race at oracle.com  Tue Mar 14 11:41:33 2017
From: philip.race at oracle.com (Philip Race)
Date: Tue, 14 Mar 2017 04:41:33 -0700
Subject: [OpenJDK 2D-Dev] [9] JDK-8176287 :[macosx] The print test
 crashed with Nimbus L&F
In-Reply-To: <0bd81696-1e17-9321-30ae-d414d9a279a0@oracle.com>
References: <cd19de59-2d2c-9e0b-a553-6e83102abdfd@oracle.com>
 <58C77774.90600@oracle.com> <3238af15-a7fc-836d-b5d1-e64e8676087b@oracle.com>
 <58C77CF9.4070908@oracle.com>
 <0bd81696-1e17-9321-30ae-d414d9a279a0@oracle.com>
Message-ID: <58C7D6ED.2050304@oracle.com>

 >Since this is mac specific code, I guess VS2010 will not play any part 
in building this.

Ah, yes :-)

Updated fix looks OK.

-phil.

On 3/14/17, 2:31 AM, Prasanta Sadhukhan wrote:
>
> JPRT 8u build resulted in failure, so I had to modify at 2 other places.
>
> QuartzSurfaceData.m:287 and QuartzSurfaceData.m:328
> Other things remains same.
> http://cr.openjdk.java.net/~psadhukhan/8176287/webrev.01/
>
> Regards
> Prasanta
> On 3/14/2017 10:47 AM, Philip Race wrote:
>>
>>
>> On 3/13/17, 10:14 PM, Prasanta Sadhukhan wrote:
>>>
>>>
>>>
>>> On 3/14/2017 10:24 AM, Philip Race wrote:
>>>> The problem seems to have been that you were allocating zero bytes 
>>>> in the old code :
>>>>   950         CGFloat* colors= (CGFloat*)calloc(0, sizeof(CGFloat)*length);
>>>>
>>>> 960         qsdo->gradientInfo->colordata = (CGFloat*)calloc(0, sizeof(CGFloat)*4*length);
>>>>
>>>> Regarding the new code, whilst it seems like it fixes the problem I have a nit
>>>> 937             int i;
>>>>  938             for (i=0; i<length; i++)
>>>>
>>>> Since this code appears at the start of a block I'd expect all 
>>>> compilers to be happy with
>>>>   for (int i=0; i<length; i++)
>>>>
>>>> is this not so ? Assuming yes, pls fix before push.
>>> Yes, it should be ok. I got a problem with jdk8u JPRT build (during 
>>> earlier backport) citing C99 compiler failure but I guess that was 
>>> because variable was declared not at blockstart.
>>> Will again do a JPRT and if its ok, I will push with this change.
>>
>> Testing the 8u backport via JPRT is good since that will use VS2010 which
>> wins the "most likely to barf" award on such an issue.
>>
>> -phil
>>>>
>>>> Also I wonder if the regression test we created for LGP passes only 
>>>> because it is "short".
>>>> Perhaps later we can improve on that.
>>>>
>>>> The fix will also need to be backported since the original fix was 
>>>> backported.
>>>>
>>> ok.
>>>> So "+1" with those comments ..
>>>>
>>> Thanks
>>>
>>> Regards
>>> Prasanta
>>>> -phil.
>>>>
>>>> On 3/12/17, 11:49 PM, Prasanta Sadhukhan wrote:
>>>>> Hi All,
>>>>>
>>>>> Please review a jck print test crash fix for jdk9. The issue was 
>>>>> seen with only Nimbus L&F which seems to use Linear gradient path
>>>>> and not in other L&F (such as Aqua) .
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8176287
>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8176287/webrev.00/
>>>>>
>>>>> Linear Gradient path collects the gradient colors and fractions 
>>>>> values in native obtained from Java and allocates several arrays 
>>>>> to store the same in setupGradient() method.
>>>>> It seems even after being freed, in subsequent call to the same 
>>>>> gradient path routine, it may get the same allocated pointer the 
>>>>> next time the array is allocated causing it to crash citing 
>>>>> "memory being modified after freed".
>>>>>
>>>>> Optimise setupGradient() method to allocate fewer pointer. The JCK 
>>>>> test works now.
>>>>> Also, the JDK-8162796 testcase LinearGradientPrintingTest and 
>>>>> RadialGradientPrintingTest works with this optimisation.
>>>>>
>>>>> Regards
>>>>> Prasanta
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20170314/cc802fdb/attachment.html>

From philip.race at oracle.com  Tue Mar 14 15:09:06 2017
From: philip.race at oracle.com (Philip Race)
Date: Tue, 14 Mar 2017 08:09:06 -0700
Subject: [OpenJDK 2D-Dev] JDK9 will be in RDP2 after March 16th PDT
Message-ID: <58C80792.7010007@oracle.com>

All,

There will I am sure be an official email to jdk9-dev soon but I'd at least
to give a reminder about this change in JDK 9 rules as it winds down 
towards release.

If you have anything you need to push without incurring extra process 
you have
just 2 and a half days to do it.

After March 16th *all* pushes to any forest require some kind of 
explicit approval.
For changes in product code, you will need a "jdk9-critical-request" 
label and a
justification about why it is a critical or stopper bug for JDK9. That 
justification
will be evaluated.

P3 and above "test" and "doc" bugs can still go in with a  much less 
formal "nod"
which for the lists above you can get from me. I will monitor the lists
for such issues.

That is just a very brief and rough summary of what happens *after* 
Thursday.
Others will give a more precise rundown of the rules.

The main message here from me is
(1) Push soon or incur process
(2) After Thursday DO NOT push without approval.

-phil.


From sergey.bylokhov at oracle.com  Tue Mar 14 16:02:09 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 14 Mar 2017 19:02:09 +0300
Subject: [OpenJDK 2D-Dev] RFR: 8088395: Print dialogs are not
 blocking/modal w.r.t specified owner windows
In-Reply-To: <2c022a82-abb3-ac14-3393-6f618f29f419@oracle.com>
References: <2c022a82-abb3-ac14-3393-6f618f29f419@oracle.com>
Message-ID: <BCA29947-C881-4A9B-861D-CE677C88FAA4@oracle.com>

Hi, Phil.
I have only two questions:
 - Does it mean that we do not support "ontop" property via public API in idk?
 - Probably the name should contain ?owner? instead of ?parent??, But since this is not a public API I guess it is not an issue.

> 
> 
> This has an FX bug + webrev :
> https://bugs.openjdk.java.net/browse/JDK-8088395 <https://bugs.openjdk.java.net/browse/JDK-8088395>
> http://cr.openjdk.java.net/~prr/8088395/index.html <http://cr.openjdk.java.net/%7Eprr/8088395/index.html>
> 
> and also a JDK-side fix and webrev :-
> https://bugs.openjdk.java.net/browse/JDK-8176530 <https://bugs.openjdk.java.net/browse/JDK-8176530>
> http://cr.openjdk.java.net/~prr/8176350/ <http://cr.openjdk.java.net/~prr/8176350/>
> 
> The problem is FX modal dialogs are ignoring the Window parameter.
> We can fix the problem with disabling the modal parent on the FX side
> and that is why most files in FX are updated.
> 
> But it does not fix the "on top" issue which requires the JDK fixes and
> to pass in the DialogOnTop private attribute.
> The JDK code is there solely for FX and won't have any visibility
> unless FX passes in the private attribute.
> 
> On Linux it uses the standard AWT "always on top" modality
> On windows it uses the HWND for the FX window and windows native modality
> On Mac you won't see anything since Mac does this automatically
> 
> -phil.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20170314/c989c175/attachment.html>

From sergey.bylokhov at oracle.com  Tue Mar 14 16:04:27 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 14 Mar 2017 19:04:27 +0300
Subject: [OpenJDK 2D-Dev] <AWT Dev> TrayIcon not working with LXDE on
	Raspberry Pi
In-Reply-To: <58C289C9.1030302@cjnash.com>
References: <58BDF944.4040501@cjnash.com>
 <5109DD1B-7830-4477-9A8C-A7A6AFC1C6D5@oracle.com>
 <58BEDABD.1080503@cjnash.com> <58C289C9.1030302@cjnash.com>
Message-ID: <870318EB-CC25-440B-954A-E88C34E683DD@oracle.com>


>> For steps to reproduce, it is necessary to have a test application that creates
>> a tray icon with a menu.  I can put this together but it will take a day or two.
> The test case is done now.  Before filing the bug, I retested on the latest
> version of Raspbian (released on 2017-03-02) and the problem does not occur.
> The problem occurs with an older version of Raspbian from 2006-03-18 that
> I was using previously.  Because of this, I am not sure if there is still
> any need to file the bug and my test case but I would be happy to do this
> if it might assist other users.

CC 2d-dev:
Since Dsun.java2d.xrender affects the bug means that this is related to xrender libarary, and probably some bugs were fixed in the latest version of Raspbian

> 
> Simon
> 
>> Simon
>>>> The TrayIcon display of messages, hover text and pop-up menus appeara to be
>>>> broken when running JDK9 EA build 159 on Raspbian LXDE.  In all cases, the
>>>> background is drawn but there is no foreground text.  Selecting the invisible
>>>> text of a menu item works as expected.  Is this a known issue or should I
>>>> create a bug report?
>>>> 
>>>> Simon Nash

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20170314/9d96c0f8/attachment.html>

From sergey.bylokhov at oracle.com  Tue Mar 14 16:21:08 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 14 Mar 2017 19:21:08 +0300
Subject: [OpenJDK 2D-Dev] [9] JDK-8176287 :[macosx] The print test
 crashed with Nimbus L&F
In-Reply-To: <58C7D6ED.2050304@oracle.com>
References: <cd19de59-2d2c-9e0b-a553-6e83102abdfd@oracle.com>
 <58C77774.90600@oracle.com> <3238af15-a7fc-836d-b5d1-e64e8676087b@oracle.com>
 <58C77CF9.4070908@oracle.com>
 <0bd81696-1e17-9321-30ae-d414d9a279a0@oracle.com>
 <58C7D6ED.2050304@oracle.com>
Message-ID: <AA800756-9F73-4702-AF4A-DF363FDA1F8F@oracle.com>


> 14 ????? 2017 ?., ? 14:41, Philip Race <philip.race at oracle.com> ???????(?):
> 
> >Since this is mac specific code, I guess VS2010 will not play any part in building this.
> 
> Ah, yes :-)
> 
> Updated fix looks OK.

Should we memset the data allocated via malloc(calloc was used before)?

> 
> -phil.
> 
> On 3/14/17, 2:31 AM, Prasanta Sadhukhan wrote:
>> 
>> JPRT 8u build resulted in failure, so I had to modify at 2 other places.
>> 
>> QuartzSurfaceData.m:287 and QuartzSurfaceData.m:328
>> Other things remains same.
>> http://cr.openjdk.java.net/~psadhukhan/8176287/webrev.01/ <http://cr.openjdk.java.net/%7Epsadhukhan/8176287/webrev.01/>
>> 
>> Regards
>> Prasanta
>> On 3/14/2017 10:47 AM, Philip Race wrote:
>>> 
>>> 
>>> On 3/13/17, 10:14 PM, Prasanta Sadhukhan wrote:
>>>> 
>>>> 
>>>> 
>>>> On 3/14/2017 10:24 AM, Philip Race wrote:
>>>>> The problem seems to have been that you were allocating zero bytes in the old code :
>>>>>  950         CGFloat* colors= (CGFloat*)calloc(0, sizeof(CGFloat)*length);
>>>>> 
>>>>> 960         qsdo->gradientInfo->colordata = (CGFloat*)calloc(0, sizeof(CGFloat)*4*length);
>>>>> 
>>>>> Regarding the new code, whilst it seems like it fixes the problem I have a nit 
>>>>> 937             int i;
>>>>>  938             for (i=0; i<length; i++)
>>>>> 
>>>>> Since this code appears at the start of a block I'd expect all compilers to be happy with
>>>>>   for (int i=0; i<length; i++)
>>>>> 
>>>>> is this not so ? Assuming yes, pls fix before push.
>>>> Yes, it should be ok. I got a problem with jdk8u JPRT build (during earlier backport) citing C99 compiler failure but I guess that was because variable was declared not at blockstart.
>>>> Will again do a JPRT and if its ok, I will push with this change.
>>> 
>>> Testing the 8u backport via JPRT is good since that will use VS2010 which
>>> wins the "most likely to barf" award on such an issue.
>>> 
>>> -phil
>>>>> 
>>>>> Also I wonder if the regression test we created for LGP passes only because it is "short".
>>>>> Perhaps later we can improve on that.
>>>>> 
>>>>> The fix will also need to be backported since the original fix was backported.
>>>>> 
>>>> ok.
>>>>> So "+1" with those comments ..
>>>>> 
>>>> Thanks
>>>> 
>>>> Regards
>>>> Prasanta
>>>>> -phil.
>>>>> 
>>>>> On 3/12/17, 11:49 PM, Prasanta Sadhukhan wrote:
>>>>>> 
>>>>>> Hi All, 
>>>>>> 
>>>>>> Please review a jck print test crash fix for jdk9. The issue was seen with only Nimbus L&F which seems to use Linear gradient path 
>>>>>> and not in other L&F (such as Aqua) . 
>>>>>> 
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8176287 <https://bugs.openjdk.java.net/browse/JDK-8176287> 
>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8176287/webrev.00/ <http://cr.openjdk.java.net/%7Epsadhukhan/8176287/webrev.00/> 
>>>>>> 
>>>>>> Linear Gradient path collects the gradient colors and fractions values in native obtained from Java and allocates several arrays to store the same in setupGradient() method. 
>>>>>> It seems even after being freed, in subsequent call to the same gradient path routine, it may get the same allocated pointer the next time the array is allocated causing it to crash citing "memory being modified after freed". 
>>>>>> 
>>>>>> Optimise setupGradient() method to allocate fewer pointer. The JCK test works now. 
>>>>>> Also, the JDK-8162796 testcase LinearGradientPrintingTest and RadialGradientPrintingTest works with this optimisation. 
>>>>>> 
>>>>>> Regards 
>>>>>> Prasanta 
>>>> 
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20170314/fc06b409/attachment.html>

From philip.race at oracle.com  Tue Mar 14 17:32:55 2017
From: philip.race at oracle.com (Phil Race)
Date: Tue, 14 Mar 2017 10:32:55 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8088395: Print dialogs are not
 blocking/modal w.r.t specified owner windows
In-Reply-To: <BCA29947-C881-4A9B-861D-CE677C88FAA4@oracle.com>
References: <2c022a82-abb3-ac14-3393-6f618f29f419@oracle.com>
 <BCA29947-C881-4A9B-861D-CE677C88FAA4@oracle.com>
Message-ID: <10d9895a-4fbe-52a0-124d-9bffeded915e@oracle.com>

I have updated webrevs described below, and also I answer your questions

FX is updated only to fix trailing white space and one modifier ordering
http://cr.openjdk.java.net/~prr/8088395.1/

The JDK side has a few modifications :
http://cr.openjdk.java.net/~prr/8176350.1/
(a) awt_PrintDialog.cpp and awt_PrintJob.cpp have an added safety check.
We now call ::IsWindowHandle(id) as we do elsewhere to make sure its valid.

(b) The Page Setup Dialog on Linux was not seeing the AlwaysOnTop property.
In part this was because it wasn't being checked in 
ServiceDialog.initPageDialog() - fixed
In other part it is because the attributes weren't propagated. The 
reason for this is
a bit lengthy to explain but the main thing to say is that we have an 
instance variable
attributes as well as a local variable in some places.
I didn't want to touch any code that even theoretically might affect 2D 
printing so
instead I cached the attribute as we do the owner id so it is passed on 
properly
Thanks to Kevin for spotting this problem


On 03/14/2017 09:02 AM, Sergey Bylokhov wrote:
> Hi, Phil.
> I have only two questions:
>  - Does it mean that we do not support "ontop" property via public API 
> in idk?

There is no API for the "alwaysOnTop" AWT property for the print dialogs.
I actually don't think it can be implemented for the windows native 
print controls.
There is an internal way to make an AWT window owner for the Swing print 
dialog
but nothing public and it doesn't help here as the owner is not an AWT 
window.


>  - Probably the name should contain ?owner? instead of ?parent??, But 
> since this is not a public API I guess it is not an issue.

I suppose that is more correct. Something to address if it ever makes 
its way into API or docs.

-phil.

>
>>
>>
>> This has an FX bug + webrev :
>> https://bugs.openjdk.java.net/browse/JDK-8088395
>> http://cr.openjdk.java.net/~prr/8088395/index.html 
>> <http://cr.openjdk.java.net/%7Eprr/8088395/index.html>
>>
>> and also a JDK-side fix and webrev :-
>> https://bugs.openjdk.java.net/browse/JDK-8176530
>> http://cr.openjdk.java.net/~prr/8176350/
>>
>> The problem is FX modal dialogs are ignoring the Window parameter.
>> We can fix the problem with disabling the modal parent on the FX side
>> and that is why most files in FX are updated.
>>
>> But it does not fix the "on top" issue which requires the JDK fixes and
>> to pass in the DialogOnTop private attribute.
>> The JDK code is there solely for FX and won't have any visibility
>> unless FX passes in the private attribute.
>>
>> On Linux it uses the standard AWT "always on top" modality
>> On windows it uses the HWND for the FX window and windows native modality
>> On Mac you won't see anything since Mac does this automatically
>>
>> -phil.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20170314/16fc3abf/attachment.html>

From kevin.rushforth at oracle.com  Tue Mar 14 18:01:36 2017
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 14 Mar 2017 11:01:36 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8088395: Print dialogs are not
 blocking/modal w.r.t specified owner windows
In-Reply-To: <10d9895a-4fbe-52a0-124d-9bffeded915e@oracle.com>
References: <2c022a82-abb3-ac14-3393-6f618f29f419@oracle.com>
 <BCA29947-C881-4A9B-861D-CE677C88FAA4@oracle.com>
 <10d9895a-4fbe-52a0-124d-9bffeded915e@oracle.com>
Message-ID: <58C83000.7060507@oracle.com>

Changes look good to me. All testing is fine, too.

+1 for both halves of the fix

-- Kevin


Phil Race wrote:
> I have updated webrevs described below, and also I answer your questions
>
> FX is updated only to fix trailing white space and one modifier ordering
> http://cr.openjdk.java.net/~prr/8088395.1/
>
> The JDK side has a few modifications :
> http://cr.openjdk.java.net/~prr/8176350.1/
> (a) awt_PrintDialog.cpp and awt_PrintJob.cpp have an added safety check.
> We now call ::IsWindowHandle(id) as we do elsewhere to make sure its 
> valid.
>
> (b) The Page Setup Dialog on Linux was not seeing the AlwaysOnTop 
> property.
> In part this was because it wasn't being checked in 
> ServiceDialog.initPageDialog() - fixed
> In other part it is because the attributes weren't propagated. The 
> reason for this is
> a bit lengthy to explain but the main thing to say is that we have an 
> instance variable
> attributes as well as a local variable in some places.
> I didn't want to touch any code that even theoretically might affect 
> 2D printing so
> instead I cached the attribute as we do the owner id so it is passed 
> on properly
> Thanks to Kevin for spotting this problem
>
>
> On 03/14/2017 09:02 AM, Sergey Bylokhov wrote:
>> Hi, Phil.
>> I have only two questions:
>>  - Does it mean that we do not support "ontop" property via public 
>> API in idk?
>
> There is no API for the "alwaysOnTop" AWT property for the print dialogs.
> I actually don't think it can be implemented for the windows native 
> print controls.
> There is an internal way to make an AWT window owner for the Swing 
> print dialog
> but nothing public and it doesn't help here as the owner is not an AWT 
> window.
>
>
>>  - Probably the name should contain ?owner? instead of ?parent??, But 
>> since this is not a public API I guess it is not an issue.
>
> I suppose that is more correct. Something to address if it ever makes 
> its way into API or docs.
>
> -phil.
>
>>
>>>
>>>
>>> This has an FX bug + webrev :
>>> https://bugs.openjdk.java.net/browse/JDK-8088395
>>> http://cr.openjdk.java.net/~prr/8088395/index.html 
>>> <http://cr.openjdk.java.net/%7Eprr/8088395/index.html>
>>>
>>> and also a JDK-side fix and webrev :-
>>> https://bugs.openjdk.java.net/browse/JDK-8176530
>>> http://cr.openjdk.java.net/~prr/8176350/
>>>
>>> The problem is FX modal dialogs are ignoring the Window parameter.
>>> We can fix the problem with disabling the modal parent on the FX side
>>> and that is why most files in FX are updated.
>>>
>>> But it does not fix the "on top" issue which requires the JDK fixes and
>>> to pass in the DialogOnTop private attribute.
>>> The JDK code is there solely for FX and won't have any visibility
>>> unless FX passes in the private attribute.
>>>
>>> On Linux it uses the standard AWT "always on top" modality
>>> On windows it uses the HWND for the FX window and windows native 
>>> modality
>>> On Mac you won't see anything since Mac does this automatically
>>>
>>> -phil.
>>
>


From sergey.bylokhov at oracle.com  Tue Mar 14 18:28:26 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 14 Mar 2017 21:28:26 +0300
Subject: [OpenJDK 2D-Dev] RFR: 8088395: Print dialogs are not
 blocking/modal w.r.t specified owner windows
In-Reply-To: <10d9895a-4fbe-52a0-124d-9bffeded915e@oracle.com>
References: <2c022a82-abb3-ac14-3393-6f618f29f419@oracle.com>
 <BCA29947-C881-4A9B-861D-CE677C88FAA4@oracle.com>
 <10d9895a-4fbe-52a0-124d-9bffeded915e@oracle.com>
Message-ID: <77CF29CD-E8D5-4307-8189-6E88A7BAB1DF@oracle.com>


> There is no API for the "alwaysOnTop" AWT property for the print dialogs.
> I actually don't think it can be implemented for the windows native print controls.
> There is an internal way to make an AWT window owner for the Swing print dialog
> but nothing public and it doesn't help here as the owner is not an AWT window.

Ok.

> 
> 
>>  - Probably the name should contain ?owner? instead of ?parent??, But since this is not a public API I guess it is not an issue.
> 
> I suppose that is more correct. Something to address if it ever makes its way into API or docs.
> 
> -phil.
> 
>> 
>>> 
>>> 
>>> This has an FX bug + webrev :
>>> https://bugs.openjdk.java.net/browse/JDK-8088395 <https://bugs.openjdk.java.net/browse/JDK-8088395>
>>> http://cr.openjdk.java.net/~prr/8088395/index.html <http://cr.openjdk.java.net/%7Eprr/8088395/index.html>
>>> 
>>> and also a JDK-side fix and webrev :-
>>> https://bugs.openjdk.java.net/browse/JDK-8176530 <https://bugs.openjdk.java.net/browse/JDK-8176530>
>>> http://cr.openjdk.java.net/~prr/8176350/ <http://cr.openjdk.java.net/%7Eprr/8176350/>
>>> 
>>> The problem is FX modal dialogs are ignoring the Window parameter.
>>> We can fix the problem with disabling the modal parent on the FX side
>>> and that is why most files in FX are updated.
>>> 
>>> But it does not fix the "on top" issue which requires the JDK fixes and
>>> to pass in the DialogOnTop private attribute.
>>> The JDK code is there solely for FX and won't have any visibility
>>> unless FX passes in the private attribute.
>>> 
>>> On Linux it uses the standard AWT "always on top" modality
>>> On windows it uses the HWND for the FX window and windows native modality
>>> On Mac you won't see anything since Mac does this automatically
>>> 
>>> -phil.
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20170314/48aa954d/attachment.html>

From prasanta.sadhukhan at oracle.com  Wed Mar 15 05:13:24 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Wed, 15 Mar 2017 10:43:24 +0530
Subject: [OpenJDK 2D-Dev] [9] JDK-8176287 :[macosx] The print test
 crashed with Nimbus L&F
In-Reply-To: <AA800756-9F73-4702-AF4A-DF363FDA1F8F@oracle.com>
References: <cd19de59-2d2c-9e0b-a553-6e83102abdfd@oracle.com>
 <58C77774.90600@oracle.com> <3238af15-a7fc-836d-b5d1-e64e8676087b@oracle.com>
 <58C77CF9.4070908@oracle.com>
 <0bd81696-1e17-9321-30ae-d414d9a279a0@oracle.com>
 <58C7D6ED.2050304@oracle.com>
 <AA800756-9F73-4702-AF4A-DF363FDA1F8F@oracle.com>
Message-ID: <1c37e0dc-239e-90c6-5843-4eb108029e11@oracle.com>



On 3/14/2017 9:51 PM, Sergey Bylokhov wrote:
>
>> 14 ????? 2017 ?., ? 14:41, Philip Race <philip.race at oracle.com 
>> <mailto:philip.race at oracle.com>> ???????(?):
>>
>> >Since this is mac specific code, I guess VS2010 will not play any 
>> part in building this.
>>
>> Ah, yes :-)
>>
>> Updated fix looks OK.
>
> Should we memset the data allocated via malloc(calloc was used before)?
>
Should be a good practice to do it, I guess .
Modified webrev adding memset:
http://cr.openjdk.java.net/~psadhukhan/8176287/webrev.02/

Regards
Prasanta
>>
>> -phil.
>>
>> On 3/14/17, 2:31 AM, Prasanta Sadhukhan wrote:
>>>
>>> JPRT 8u build resulted in failure, so I had to modify at 2 other places.
>>>
>>> QuartzSurfaceData.m:287 and QuartzSurfaceData.m:328
>>> Other things remains same.
>>> http://cr.openjdk.java.net/~psadhukhan/8176287/webrev.01/
>>>
>>> Regards
>>> Prasanta
>>> On 3/14/2017 10:47 AM, Philip Race wrote:
>>>>
>>>>
>>>> On 3/13/17, 10:14 PM, Prasanta Sadhukhan wrote:
>>>>>
>>>>>
>>>>>
>>>>> On 3/14/2017 10:24 AM, Philip Race wrote:
>>>>>> The problem seems to have been that you were allocating zero 
>>>>>> bytes in the old code :
>>>>>> 950 CGFloat* colors= (CGFloat*)calloc(0, sizeof(CGFloat)*length);
>>>>>> 960 qsdo->gradientInfo->colordata = (CGFloat*)calloc(0, 
>>>>>> sizeof(CGFloat)*4*length); Regarding the new code, whilst it 
>>>>>> seems like it fixes the problem I have a nit
>>>>>> 937             int i;
>>>>>>  938             for (i=0; i<length; i++)
>>>>>>
>>>>>> Since this code appears at the start of a block I'd expect all 
>>>>>> compilers to be happy with
>>>>>>   for (int i=0; i<length; i++)
>>>>>>
>>>>>> is this not so ? Assuming yes, pls fix before push.
>>>>> Yes, it should be ok. I got a problem with jdk8u JPRT build 
>>>>> (during earlier backport) citing C99 compiler failure but I guess 
>>>>> that was because variable was declared not at blockstart.
>>>>> Will again do a JPRT and if its ok, I will push with this change.
>>>>
>>>> Testing the 8u backport via JPRT is good since that will use VS2010 
>>>> which
>>>> wins the "most likely to barf" award on such an issue.
>>>>
>>>> -phil
>>>>>>
>>>>>> Also I wonder if the regression test we created for LGP passes 
>>>>>> only because it is "short".
>>>>>> Perhaps later we can improve on that.
>>>>>>
>>>>>> The fix will also need to be backported since the original fix 
>>>>>> was backported.
>>>>>>
>>>>> ok.
>>>>>> So "+1" with those comments ..
>>>>>>
>>>>> Thanks
>>>>>
>>>>> Regards
>>>>> Prasanta
>>>>>> -phil.
>>>>>>
>>>>>> On 3/12/17, 11:49 PM, Prasanta Sadhukhan wrote:
>>>>>>> Hi All,
>>>>>>>
>>>>>>> Please review a jck print test crash fix for jdk9. The issue was 
>>>>>>> seen with only Nimbus L&F which seems to use Linear gradient path
>>>>>>> and not in other L&F (such as Aqua) .
>>>>>>>
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8176287
>>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8176287/webrev.00/
>>>>>>>
>>>>>>> Linear Gradient path collects the gradient colors and fractions 
>>>>>>> values in native obtained from Java and allocates several arrays 
>>>>>>> to store the same in setupGradient() method.
>>>>>>> It seems even after being freed, in subsequent call to the same 
>>>>>>> gradient path routine, it may get the same allocated pointer the 
>>>>>>> next time the array is allocated causing it to crash citing 
>>>>>>> "memory being modified after freed".
>>>>>>>
>>>>>>> Optimise setupGradient() method to allocate fewer pointer. The 
>>>>>>> JCK test works now.
>>>>>>> Also, the JDK-8162796 testcase LinearGradientPrintingTest and 
>>>>>>> RadialGradientPrintingTest works with this optimisation.
>>>>>>>
>>>>>>> Regards
>>>>>>> Prasanta
>>>>>
>>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20170315/d48773b7/attachment.html>

From prasanta.sadhukhan at oracle.com  Wed Mar 15 05:36:05 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Wed, 15 Mar 2017 11:06:05 +0530
Subject: [OpenJDK 2D-Dev] RFR: 8088395: Print dialogs are not
 blocking/modal w.r.t specified owner windows
In-Reply-To: <10d9895a-4fbe-52a0-124d-9bffeded915e@oracle.com>
References: <2c022a82-abb3-ac14-3393-6f618f29f419@oracle.com>
 <BCA29947-C881-4A9B-861D-CE677C88FAA4@oracle.com>
 <10d9895a-4fbe-52a0-124d-9bffeded915e@oracle.com>
Message-ID: <09b06da8-8127-caa3-4125-63297641187b@oracle.com>

Looks good to me.

Regards
Prasanta
On 3/14/2017 11:02 PM, Phil Race wrote:
> I have updated webrevs described below, and also I answer your questions
>
> FX is updated only to fix trailing white space and one modifier ordering
> http://cr.openjdk.java.net/~prr/8088395.1/
>
> The JDK side has a few modifications :
> http://cr.openjdk.java.net/~prr/8176350.1/
> (a) awt_PrintDialog.cpp and awt_PrintJob.cpp have an added safety check.
> We now call ::IsWindowHandle(id) as we do elsewhere to make sure its 
> valid.
>
> (b) The Page Setup Dialog on Linux was not seeing the AlwaysOnTop 
> property.
> In part this was because it wasn't being checked in 
> ServiceDialog.initPageDialog() - fixed
> In other part it is because the attributes weren't propagated. The 
> reason for this is
> a bit lengthy to explain but the main thing to say is that we have an 
> instance variable
> attributes as well as a local variable in some places.
> I didn't want to touch any code that even theoretically might affect 
> 2D printing so
> instead I cached the attribute as we do the owner id so it is passed 
> on properly
> Thanks to Kevin for spotting this problem
>
>
> On 03/14/2017 09:02 AM, Sergey Bylokhov wrote:
>> Hi, Phil.
>> I have only two questions:
>>  - Does it mean that we do not support "ontop" property via public 
>> API in idk?
>
> There is no API for the "alwaysOnTop" AWT property for the print dialogs.
> I actually don't think it can be implemented for the windows native 
> print controls.
> There is an internal way to make an AWT window owner for the Swing 
> print dialog
> but nothing public and it doesn't help here as the owner is not an AWT 
> window.
>
>
>>  - Probably the name should contain ?owner? instead of ?parent??, But 
>> since this is not a public API I guess it is not an issue.
>
> I suppose that is more correct. Something to address if it ever makes 
> its way into API or docs.
>
> -phil.
>
>>
>>>
>>>
>>> This has an FX bug + webrev :
>>> https://bugs.openjdk.java.net/browse/JDK-8088395
>>> http://cr.openjdk.java.net/~prr/8088395/index.html 
>>> <http://cr.openjdk.java.net/%7Eprr/8088395/index.html>
>>>
>>> and also a JDK-side fix and webrev :-
>>> https://bugs.openjdk.java.net/browse/JDK-8176530
>>> http://cr.openjdk.java.net/~prr/8176350/
>>>
>>> The problem is FX modal dialogs are ignoring the Window parameter.
>>> We can fix the problem with disabling the modal parent on the FX side
>>> and that is why most files in FX are updated.
>>>
>>> But it does not fix the "on top" issue which requires the JDK fixes and
>>> to pass in the DialogOnTop private attribute.
>>> The JDK code is there solely for FX and won't have any visibility
>>> unless FX passes in the private attribute.
>>>
>>> On Linux it uses the standard AWT "always on top" modality
>>> On windows it uses the HWND for the FX window and windows native 
>>> modality
>>> On Mac you won't see anything since Mac does this automatically
>>>
>>> -phil.
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20170315/bf01314b/attachment.html>

From sergey.bylokhov at oracle.com  Wed Mar 15 17:57:45 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 15 Mar 2017 20:57:45 +0300
Subject: [OpenJDK 2D-Dev] [9] JDK-8176287 :[macosx] The print test
 crashed with Nimbus L&F
In-Reply-To: <1c37e0dc-239e-90c6-5843-4eb108029e11@oracle.com>
References: <cd19de59-2d2c-9e0b-a553-6e83102abdfd@oracle.com>
 <58C77774.90600@oracle.com> <3238af15-a7fc-836d-b5d1-e64e8676087b@oracle.com>
 <58C77CF9.4070908@oracle.com>
 <0bd81696-1e17-9321-30ae-d414d9a279a0@oracle.com>
 <58C7D6ED.2050304@oracle.com>
 <AA800756-9F73-4702-AF4A-DF363FDA1F8F@oracle.com>
 <1c37e0dc-239e-90c6-5843-4eb108029e11@oracle.com>
Message-ID: <3FFB08F7-F271-44AB-BBC0-75F85746AA11@oracle.com>

> 
> On 3/14/2017 9:51 PM, Sergey Bylokhov wrote:
>> 
>>> 14 ????? 2017 ?., ? 14:41, Philip Race <philip.race at oracle.com <mailto:philip.race at oracle.com>> ???????(?):
>>> 
>>> >Since this is mac specific code, I guess VS2010 will not play any part in building this.
>>> 
>>> Ah, yes :-)
>>> 
>>> Updated fix looks OK.
>> 
>> Should we memset the data allocated via malloc(calloc was used before)?
>> 
> Should be a good practice to do it, I guess .
> Modified webrev adding memset:
> http://cr.openjdk.java.net/~psadhukhan/8176287/webrev.02/ <http://cr.openjdk.java.net/~psadhukhan/8176287/webrev.02/>

This looks fine to me, but I wonder why the calloc was replaced by malloc? 

> 
> Regards
> Prasanta
>>> 
>>> -phil.
>>> 
>>> On 3/14/17, 2:31 AM, Prasanta Sadhukhan wrote:
>>>> 
>>>> JPRT 8u build resulted in failure, so I had to modify at 2 other places.
>>>> 
>>>> QuartzSurfaceData.m:287 and QuartzSurfaceData.m:328
>>>> Other things remains same.
>>>> http://cr.openjdk.java.net/~psadhukhan/8176287/webrev.01/ <http://cr.openjdk.java.net/%7Epsadhukhan/8176287/webrev.01/>
>>>> 
>>>> Regards
>>>> Prasanta
>>>> On 3/14/2017 10:47 AM, Philip Race wrote:
>>>>> 
>>>>> 
>>>>> On 3/13/17, 10:14 PM, Prasanta Sadhukhan wrote:
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On 3/14/2017 10:24 AM, Philip Race wrote:
>>>>>>> The problem seems to have been that you were allocating zero bytes in the old code :
>>>>>>>  950         CGFloat* colors= (CGFloat*)calloc(0, sizeof(CGFloat)*length);
>>>>>>> 
>>>>>>> 960         qsdo->gradientInfo->colordata = (CGFloat*)calloc(0, sizeof(CGFloat)*4*length);
>>>>>>> 
>>>>>>> Regarding the new code, whilst it seems like it fixes the problem I have a nit 
>>>>>>> 937             int i;
>>>>>>>  938             for (i=0; i<length; i++)
>>>>>>> 
>>>>>>> Since this code appears at the start of a block I'd expect all compilers to be happy with
>>>>>>>   for (int i=0; i<length; i++)
>>>>>>> 
>>>>>>> is this not so ? Assuming yes, pls fix before push.
>>>>>> Yes, it should be ok. I got a problem with jdk8u JPRT build (during earlier backport) citing C99 compiler failure but I guess that was because variable was declared not at blockstart.
>>>>>> Will again do a JPRT and if its ok, I will push with this change.
>>>>> 
>>>>> Testing the 8u backport via JPRT is good since that will use VS2010 which
>>>>> wins the "most likely to barf" award on such an issue.
>>>>> 
>>>>> -phil
>>>>>>> 
>>>>>>> Also I wonder if the regression test we created for LGP passes only because it is "short".
>>>>>>> Perhaps later we can improve on that.
>>>>>>> 
>>>>>>> The fix will also need to be backported since the original fix was backported.
>>>>>>> 
>>>>>> ok.
>>>>>>> So "+1" with those comments ..
>>>>>>> 
>>>>>> Thanks
>>>>>> 
>>>>>> Regards
>>>>>> Prasanta
>>>>>>> -phil.
>>>>>>> 
>>>>>>> On 3/12/17, 11:49 PM, Prasanta Sadhukhan wrote:
>>>>>>>> 
>>>>>>>> Hi All, 
>>>>>>>> 
>>>>>>>> Please review a jck print test crash fix for jdk9. The issue was seen with only Nimbus L&F which seems to use Linear gradient path 
>>>>>>>> and not in other L&F (such as Aqua) . 
>>>>>>>> 
>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8176287 <https://bugs.openjdk.java.net/browse/JDK-8176287> 
>>>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8176287/webrev.00/ <http://cr.openjdk.java.net/%7Epsadhukhan/8176287/webrev.00/> 
>>>>>>>> 
>>>>>>>> Linear Gradient path collects the gradient colors and fractions values in native obtained from Java and allocates several arrays to store the same in setupGradient() method. 
>>>>>>>> It seems even after being freed, in subsequent call to the same gradient path routine, it may get the same allocated pointer the next time the array is allocated causing it to crash citing "memory being modified after freed". 
>>>>>>>> 
>>>>>>>> Optimise setupGradient() method to allocate fewer pointer. The JCK test works now. 
>>>>>>>> Also, the JDK-8162796 testcase LinearGradientPrintingTest and RadialGradientPrintingTest works with this optimisation. 
>>>>>>>> 
>>>>>>>> Regards 
>>>>>>>> Prasanta 
>>>>>> 
>>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20170315/3be4d655/attachment.html>

From philip.race at oracle.com  Wed Mar 15 18:02:49 2017
From: philip.race at oracle.com (Philip Race)
Date: Wed, 15 Mar 2017 11:02:49 -0700
Subject: [OpenJDK 2D-Dev] [9] JDK-8176287 :[macosx] The print test
 crashed with Nimbus L&F
In-Reply-To: <3FFB08F7-F271-44AB-BBC0-75F85746AA11@oracle.com>
References: <cd19de59-2d2c-9e0b-a553-6e83102abdfd@oracle.com>
 <58C77774.90600@oracle.com> <3238af15-a7fc-836d-b5d1-e64e8676087b@oracle.com>
 <58C77CF9.4070908@oracle.com>
 <0bd81696-1e17-9321-30ae-d414d9a279a0@oracle.com>
 <58C7D6ED.2050304@oracle.com>
 <AA800756-9F73-4702-AF4A-DF363FDA1F8F@oracle.com>
 <1c37e0dc-239e-90c6-5843-4eb108029e11@oracle.com>
 <3FFB08F7-F271-44AB-BBC0-75F85746AA11@oracle.com>
Message-ID: <58C981C9.9050003@oracle.com>

I wondered that too but since it appeared we then had a loop
that explicitly initialised all elements it should not matter.

But I supposed it was sort of an accidental byproduct of trying 
different things.

-phil.

On 3/15/17, 10:57 AM, Sergey Bylokhov wrote:
>>
>> On 3/14/2017 9:51 PM, Sergey Bylokhov wrote:
>>>
>>>> 14 ????? 2017 ?., ? 14:41, Philip Race <philip.race at oracle.com 
>>>> <mailto:philip.race at oracle.com>> ???????(?):
>>>>
>>>> >Since this is mac specific code, I guess VS2010 will not play any 
>>>> part in building this.
>>>>
>>>> Ah, yes :-)
>>>>
>>>> Updated fix looks OK.
>>>
>>> Should we memset the data allocated via malloc(calloc was used before)?
>>>
>> Should be a good practice to do it, I guess .
>> Modified webrev adding memset:
>> http://cr.openjdk.java.net/~psadhukhan/8176287/webrev.02/ 
>> <http://cr.openjdk.java.net/%7Epsadhukhan/8176287/webrev.02/>
>
> This looks fine to me, but I wonder why the calloc was replaced by 
> malloc?
>
>>
>> Regards
>> Prasanta
>>>>
>>>> -phil.
>>>>
>>>> On 3/14/17, 2:31 AM, Prasanta Sadhukhan wrote:
>>>>>
>>>>> JPRT 8u build resulted in failure, so I had to modify at 2 other 
>>>>> places.
>>>>>
>>>>> QuartzSurfaceData.m:287 and QuartzSurfaceData.m:328
>>>>> Other things remains same.
>>>>> http://cr.openjdk.java.net/~psadhukhan/8176287/webrev.01/
>>>>>
>>>>> Regards
>>>>> Prasanta
>>>>> On 3/14/2017 10:47 AM, Philip Race wrote:
>>>>>>
>>>>>>
>>>>>> On 3/13/17, 10:14 PM, Prasanta Sadhukhan wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 3/14/2017 10:24 AM, Philip Race wrote:
>>>>>>>> The problem seems to have been that you were allocating zero 
>>>>>>>> bytes in the old code :
>>>>>>>>   950         CGFloat* colors= (CGFloat*)calloc(0, sizeof(CGFloat)*length);
>>>>>>>>
>>>>>>>> 960         qsdo->gradientInfo->colordata = (CGFloat*)calloc(0, sizeof(CGFloat)*4*length);
>>>>>>>>
>>>>>>>> Regarding the new code, whilst it seems like it fixes the problem I have a nit
>>>>>>>> 937             int i;
>>>>>>>>  938             for (i=0; i<length; i++)
>>>>>>>>
>>>>>>>> Since this code appears at the start of a block I'd expect all 
>>>>>>>> compilers to be happy with
>>>>>>>>   for (int i=0; i<length; i++)
>>>>>>>>
>>>>>>>> is this not so ? Assuming yes, pls fix before push.
>>>>>>> Yes, it should be ok. I got a problem with jdk8u JPRT build 
>>>>>>> (during earlier backport) citing C99 compiler failure but I 
>>>>>>> guess that was because variable was declared not at blockstart.
>>>>>>> Will again do a JPRT and if its ok, I will push with this change.
>>>>>>
>>>>>> Testing the 8u backport via JPRT is good since that will use 
>>>>>> VS2010 which
>>>>>> wins the "most likely to barf" award on such an issue.
>>>>>>
>>>>>> -phil
>>>>>>>>
>>>>>>>> Also I wonder if the regression test we created for LGP passes 
>>>>>>>> only because it is "short".
>>>>>>>> Perhaps later we can improve on that.
>>>>>>>>
>>>>>>>> The fix will also need to be backported since the original fix 
>>>>>>>> was backported.
>>>>>>>>
>>>>>>> ok.
>>>>>>>> So "+1" with those comments ..
>>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>> Regards
>>>>>>> Prasanta
>>>>>>>> -phil.
>>>>>>>>
>>>>>>>> On 3/12/17, 11:49 PM, Prasanta Sadhukhan wrote:
>>>>>>>>> Hi All,
>>>>>>>>>
>>>>>>>>> Please review a jck print test crash fix for jdk9. The issue 
>>>>>>>>> was seen with only Nimbus L&F which seems to use Linear 
>>>>>>>>> gradient path
>>>>>>>>> and not in other L&F (such as Aqua) .
>>>>>>>>>
>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8176287
>>>>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8176287/webrev.00/
>>>>>>>>>
>>>>>>>>> Linear Gradient path collects the gradient colors and 
>>>>>>>>> fractions values in native obtained from Java and allocates 
>>>>>>>>> several arrays to store the same in setupGradient() method.
>>>>>>>>> It seems even after being freed, in subsequent call to the 
>>>>>>>>> same gradient path routine, it may get the same allocated 
>>>>>>>>> pointer the next time the array is allocated causing it to 
>>>>>>>>> crash citing "memory being modified after freed".
>>>>>>>>>
>>>>>>>>> Optimise setupGradient() method to allocate fewer pointer. The 
>>>>>>>>> JCK test works now.
>>>>>>>>> Also, the JDK-8162796 testcase LinearGradientPrintingTest and 
>>>>>>>>> RadialGradientPrintingTest works with this optimisation.
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> Prasanta
>>>>>>>
>>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20170315/19d5b13f/attachment.html>

From anton.litvinov at oracle.com  Fri Mar 17 17:29:39 2017
From: anton.litvinov at oracle.com (Anton Litvinov)
Date: Fri, 17 Mar 2017 20:29:39 +0300
Subject: [OpenJDK 2D-Dev] [9] Review request for 8167102: [macosx]
 PrintRequestAttributeSet breaks page size set using PageFormat
Message-ID: <17a96ade-ea01-95bd-728a-ec3106d1fbfa@oracle.com>

Hello,

Could you please review the following fix for the bug.

Bug: https://bugs.openjdk.java.net/browse/JDK-8167102
Webrev: http://cr.openjdk.java.net/~alitvinov/8167102/jdk9/webrev.00

The bug consists in the fact that, if the user's application specifies 
the required page size (media size) through "java.awt.print.PrinterJob" 
API particularly via "java.awt.print.PageFormat" instance supplied to 
the method "PrinterJob.setPrintable(Printable, PageFormat)" and calls 
"PrinterJob.print(PrintRequestAttributeSet)" with 
"javax.print.attribute.PrintRequestAttributeSet" containing at least 1 
any "PrintRequestAttribute", then the page or pages will be printed with 
"PageFormat" describing the default page size of the printer which is 
different from the expected and originally set by the user's application 
"PageFormat".

Debugging showed that the new "PageFormat" with unexpected media size is 
created in the method 
"sun.print.RasterPrinterJob.getPageFormatFromAttributes()" which is 
invoked from the native function 
"jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m::javaPrinterJobToNSPrintInfo". 
The method "RasterPrinterJob.getPageFormatFromAttributes()" returns a 
new "PageFormat" always, if the provided by the user 
"PrintRequestAttributeSet" is not empty, and the default values are set 
to particular instance variables of this "PageFormat", if 
"PrintRequestAttributeSet" does not contain the searched 
"OrientationRequested", "MediaSizeName", "MediaPrintableArea" attributes.

THE SOLUTION:
Although it is clearly stated in Java Platform SE 8 API Specification 
(documentation of the method "PrinterJob.print(PrintRequestAttributeSet)")
Specification URL: 
http://docs.oracle.com/javase/8/docs/api/java/awt/print/PrinterJob.html#print-javax.print.attribute.PrintRequestAttributeSet-

that media size, orientation and imageable area attributes specified in 
"PrintRequestAttributeSet" supplied to the method "PrinterJob.print" 
will be used for construction of a new "PageFormat", which will be 
passed to "Printable" object, instead of the original "PageFormat" 
instance set through "PrinterJob.setPrintable" method, the observed in 
this issue behavior is a bug, because in the bug test case neither media 
size, nor orientation, nor imageable area attributes are specified in 
"PrintRequestAttributeSet".

The fix alters the method 
"sun.print.RasterPrinterJob.getPageFormatFromAttributes()" to use 
corresponding values from "PageFormat" instance originally set through 
"PrinterJob" API during construction of the new "PageFormat", when it is 
found out that "OrientationRequested", or "MediaSizeName", or 
"MediaPrintableArea" attribute is not specified in 
"PrintRequestAttributeSet" supplied to "PrinterJob.print" method.

Thank you,
Anton


From prasanta.sadhukhan at oracle.com  Tue Mar 21 09:52:13 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Tue, 21 Mar 2017 15:22:13 +0530
Subject: [OpenJDK 2D-Dev] [9] Review request for 8167102: [macosx]
 PrintRequestAttributeSet breaks page size set using PageFormat
In-Reply-To: <17a96ade-ea01-95bd-728a-ec3106d1fbfa@oracle.com>
References: <17a96ade-ea01-95bd-728a-ec3106d1fbfa@oracle.com>
Message-ID: <ae716330-c0c4-9b2c-4f6b-c30855e659dc@oracle.com>

I think the real problem is not in 
RasterPrinterJob.getPageFormatFromAttributes().

One can see that, when we call RasterPrinterJob.setPrintable(), we call 
updatePageAttributes() which in turn calls 
updateAttributesWithPageFormat() where orientation, media and 
mediaprintablearea "attributes" get populated/cached from the 
"pageformat" supplied by the user.

But, when PrinterJob.print(PrintRequestAttributeSet) is called, it calls 
setAttributes(attributes) where "attributes" is what is populated by the 
user. It does not contain orientation,media and mediaprintablearea 
attributes for this bug, so setAttributes sets cached attribute with 
this user-set attribute instance
/>>else {//
//>>            // for AWT where pageable is not an instance of OpenBook,//
//>>            // we need to save paper info//
// >>           this.attributes = attributes;//
// >>       }//
/

//thereby losing the attributes it has cached earlier from user 
pageformat. I think we should check if this.attributes is not null, then 
retain those attributes unless explicitly set by the user in 
user-defined attributes.

But, this code is used by windows,linux,mac so it needs to be tested 
against all those platforms to ensure we are not regressing anything.

Also, I think user should call validatePage(PageFormat) in application 
to check if the settings passed is compatible with the printer or not, 
get compatible/adjusted pageformat and call setPrintable() with that 
"adjusted" pageformat. If user pass 0,0,fullpaperwidth,fullpaperheight 
as imageablearea, then he should not expect this setting to be used 
since printer will have its own hardware limitation (and use some offset 
printing)

BTW, a regression testcase (even if it is manual) should be created with 
the fix.

Regards
Prasanta
On 3/17/2017 10:59 PM, Anton Litvinov wrote:
> Hello,
>
> Could you please review the following fix for the bug.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8167102
> Webrev: http://cr.openjdk.java.net/~alitvinov/8167102/jdk9/webrev.00
>
> The bug consists in the fact that, if the user's application specifies 
> the required page size (media size) through 
> "java.awt.print.PrinterJob" API particularly via 
> "java.awt.print.PageFormat" instance supplied to the method 
> "PrinterJob.setPrintable(Printable, PageFormat)" and calls 
> "PrinterJob.print(PrintRequestAttributeSet)" with 
> "javax.print.attribute.PrintRequestAttributeSet" containing at least 1 
> any "PrintRequestAttribute", then the page or pages will be printed 
> with "PageFormat" describing the default page size of the printer 
> which is different from the expected and originally set by the user's 
> application "PageFormat".
>
> Debugging showed that the new "PageFormat" with unexpected media size 
> is created in the method 
> "sun.print.RasterPrinterJob.getPageFormatFromAttributes()" which is 
> invoked from the native function 
> "jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m::javaPrinterJobToNSPrintInfo". 
> The method "RasterPrinterJob.getPageFormatFromAttributes()" returns a 
> new "PageFormat" always, if the provided by the user 
> "PrintRequestAttributeSet" is not empty, and the default values are 
> set to particular instance variables of this "PageFormat", if 
> "PrintRequestAttributeSet" does not contain the searched 
> "OrientationRequested", "MediaSizeName", "MediaPrintableArea" attributes.
>
> THE SOLUTION:
> Although it is clearly stated in Java Platform SE 8 API Specification 
> (documentation of the method 
> "PrinterJob.print(PrintRequestAttributeSet)")
> Specification URL: 
> http://docs.oracle.com/javase/8/docs/api/java/awt/print/PrinterJob.html#print-javax.print.attribute.PrintRequestAttributeSet-
>
> that media size, orientation and imageable area attributes specified 
> in "PrintRequestAttributeSet" supplied to the method 
> "PrinterJob.print" will be used for construction of a new 
> "PageFormat", which will be passed to "Printable" object, instead of 
> the original "PageFormat" instance set through 
> "PrinterJob.setPrintable" method, the observed in this issue behavior 
> is a bug, because in the bug test case neither media size, nor 
> orientation, nor imageable area attributes are specified in 
> "PrintRequestAttributeSet".
>
> The fix alters the method 
> "sun.print.RasterPrinterJob.getPageFormatFromAttributes()" to use 
> corresponding values from "PageFormat" instance originally set through 
> "PrinterJob" API during construction of the new "PageFormat", when it 
> is found out that "OrientationRequested", or "MediaSizeName", or 
> "MediaPrintableArea" attribute is not specified in 
> "PrintRequestAttributeSet" supplied to "PrinterJob.print" method.
>
> Thank you,
> Anton

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20170321/efed4964/attachment.html>

From anton.litvinov at oracle.com  Tue Mar 21 14:45:54 2017
From: anton.litvinov at oracle.com (Anton Litvinov)
Date: Tue, 21 Mar 2017 17:45:54 +0300
Subject: [OpenJDK 2D-Dev] [9] Review request for 8167102: [macosx]
 PrintRequestAttributeSet breaks page size set using PageFormat
In-Reply-To: <ae716330-c0c4-9b2c-4f6b-c30855e659dc@oracle.com>
References: <17a96ade-ea01-95bd-728a-ec3106d1fbfa@oracle.com>
 <ae716330-c0c4-9b2c-4f6b-c30855e659dc@oracle.com>
Message-ID: <7d710d7a-386f-a6c3-7f6d-13e56a7309a6@oracle.com>

Hello Prasanta,

Thank you for review of this fix. I have tried to apply the approach 
which you suggested and it allowed to resolve the issue. In this case I 
agree that it would be more correct to resolve the issue in 
"RasterPrinterJob.setAttributes(PrintRequestAttributeSet)" method. In 
the first version of the fix I decided to change the method 
"RasterPrinterJob.getPageFormatFromAttributes()", because it is invoked 
only from 1 place in JDK code and this place is located in OS X specific 
code 
"jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m", so 
that would automatically minimize the affected by the fix platforms to 
OS X only.

Starting to work on implementation of the second version of the fix 
including the regression test.

Thank you,
Anton

On 3/21/2017 12:52 PM, Prasanta Sadhukhan wrote:
>
> I think the real problem is not in 
> RasterPrinterJob.getPageFormatFromAttributes().
>
> One can see that, when we call RasterPrinterJob.setPrintable(), we 
> call updatePageAttributes() which in turn calls 
> updateAttributesWithPageFormat() where orientation, media and 
> mediaprintablearea "attributes" get populated/cached from the 
> "pageformat" supplied by the user.
>
> But, when PrinterJob.print(PrintRequestAttributeSet) is called, it 
> calls setAttributes(attributes) where "attributes" is what is 
> populated by the user. It does not contain orientation,media and 
> mediaprintablearea attributes for this bug, so setAttributes sets 
> cached attribute with this user-set attribute instance
> />>else {//
> //>>            // for AWT where pageable is not an instance of 
> OpenBook,//
> //>>            // we need to save paper info//
> // >>           this.attributes = attributes;//
> // >>       }//
> /
>
> //thereby losing the attributes it has cached earlier from user 
> pageformat. I think we should check if this.attributes is not null, 
> then retain those attributes unless explicitly set by the user in 
> user-defined attributes.
>
> But, this code is used by windows,linux,mac so it needs to be tested 
> against all those platforms to ensure we are not regressing anything.
>
> Also, I think user should call validatePage(PageFormat) in application 
> to check if the settings passed is compatible with the printer or not, 
> get compatible/adjusted pageformat and call setPrintable() with that 
> "adjusted" pageformat. If user pass 0,0,fullpaperwidth,fullpaperheight 
> as imageablearea, then he should not expect this setting to be used 
> since printer will have its own hardware limitation (and use some 
> offset printing)
>
> BTW, a regression testcase (even if it is manual) should be created 
> with the fix.
>
> Regards
> Prasanta
> On 3/17/2017 10:59 PM, Anton Litvinov wrote:
>> Hello,
>>
>> Could you please review the following fix for the bug.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8167102
>> Webrev: http://cr.openjdk.java.net/~alitvinov/8167102/jdk9/webrev.00
>>
>> The bug consists in the fact that, if the user's application 
>> specifies the required page size (media size) through 
>> "java.awt.print.PrinterJob" API particularly via 
>> "java.awt.print.PageFormat" instance supplied to the method 
>> "PrinterJob.setPrintable(Printable, PageFormat)" and calls 
>> "PrinterJob.print(PrintRequestAttributeSet)" with 
>> "javax.print.attribute.PrintRequestAttributeSet" containing at least 
>> 1 any "PrintRequestAttribute", then the page or pages will be printed 
>> with "PageFormat" describing the default page size of the printer 
>> which is different from the expected and originally set by the user's 
>> application "PageFormat".
>>
>> Debugging showed that the new "PageFormat" with unexpected media size 
>> is created in the method 
>> "sun.print.RasterPrinterJob.getPageFormatFromAttributes()" which is 
>> invoked from the native function 
>> "jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m::javaPrinterJobToNSPrintInfo". 
>> The method "RasterPrinterJob.getPageFormatFromAttributes()" returns a 
>> new "PageFormat" always, if the provided by the user 
>> "PrintRequestAttributeSet" is not empty, and the default values are 
>> set to particular instance variables of this "PageFormat", if 
>> "PrintRequestAttributeSet" does not contain the searched 
>> "OrientationRequested", "MediaSizeName", "MediaPrintableArea" 
>> attributes.
>>
>> THE SOLUTION:
>> Although it is clearly stated in Java Platform SE 8 API Specification 
>> (documentation of the method 
>> "PrinterJob.print(PrintRequestAttributeSet)")
>> Specification URL: 
>> http://docs.oracle.com/javase/8/docs/api/java/awt/print/PrinterJob.html#print-javax.print.attribute.PrintRequestAttributeSet-
>>
>> that media size, orientation and imageable area attributes specified 
>> in "PrintRequestAttributeSet" supplied to the method 
>> "PrinterJob.print" will be used for construction of a new 
>> "PageFormat", which will be passed to "Printable" object, instead of 
>> the original "PageFormat" instance set through 
>> "PrinterJob.setPrintable" method, the observed in this issue behavior 
>> is a bug, because in the bug test case neither media size, nor 
>> orientation, nor imageable area attributes are specified in 
>> "PrintRequestAttributeSet".
>>
>> The fix alters the method 
>> "sun.print.RasterPrinterJob.getPageFormatFromAttributes()" to use 
>> corresponding values from "PageFormat" instance originally set 
>> through "PrinterJob" API during construction of the new "PageFormat", 
>> when it is found out that "OrientationRequested", or "MediaSizeName", 
>> or "MediaPrintableArea" attribute is not specified in 
>> "PrintRequestAttributeSet" supplied to "PrinterJob.print" method.
>>
>> Thank you,
>> Anton
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20170321/98855f4d/attachment.html>

From prasanta.sadhukhan at oracle.com  Wed Mar 22 04:42:10 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Wed, 22 Mar 2017 10:12:10 +0530
Subject: [OpenJDK 2D-Dev] [9] Review request for 8167102: [macosx]
 PrintRequestAttributeSet breaks page size set using PageFormat
In-Reply-To: <7d710d7a-386f-a6c3-7f6d-13e56a7309a6@oracle.com>
References: <17a96ade-ea01-95bd-728a-ec3106d1fbfa@oracle.com>
 <ae716330-c0c4-9b2c-4f6b-c30855e659dc@oracle.com>
 <7d710d7a-386f-a6c3-7f6d-13e56a7309a6@oracle.com>
Message-ID: <b5efdb91-dd13-045f-18bd-f95830ba61fe@oracle.com>

Hi Anton,

I thought about your point and have a question: does this issue not 
reproduce in non-mac platform?
I thought it probably would so suggested modifying setAttributes() . 
But, if it is only reproduced in mac, we need to find out why despite 
this setAttributes() flaw, how this is working in non-mac platform?

It probably might work in windows/linux because in 
RasterPrinterJob.print(attr) method, after it calls setAttributes(), it 
calls printPage() where it gets the original PageFormat
by calling getPageFormat(pageIndex) and gets the orientation, imageablearea
and not by constructing pageFormat from attributes as it is done in mac.
So, probably, in mac also, we need to do away with 
getPageFormatFromAttributes() call  and call getPageFormat(pageIndex) 
from CPrinterJob.m#javaPrinterJobToNSPrintInfo().

Regards
Prasanta
On 3/21/2017 8:15 PM, Anton Litvinov wrote:
> Hello Prasanta,
>
> Thank you for review of this fix. I have tried to apply the approach 
> which you suggested and it allowed to resolve the issue. In this case 
> I agree that it would be more correct to resolve the issue in 
> "RasterPrinterJob.setAttributes(PrintRequestAttributeSet)" method. In 
> the first version of the fix I decided to change the method 
> "RasterPrinterJob.getPageFormatFromAttributes()", because it is 
> invoked only from 1 place in JDK code and this place is located in OS 
> X specific code 
> "jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m", 
> so that would automatically minimize the affected by the fix platforms 
> to OS X only.
>
> Starting to work on implementation of the second version of the fix 
> including the regression test.
>
> Thank you,
> Anton
>
> On 3/21/2017 12:52 PM, Prasanta Sadhukhan wrote:
>>
>> I think the real problem is not in 
>> RasterPrinterJob.getPageFormatFromAttributes().
>>
>> One can see that, when we call RasterPrinterJob.setPrintable(), we 
>> call updatePageAttributes() which in turn calls 
>> updateAttributesWithPageFormat() where orientation, media and 
>> mediaprintablearea "attributes" get populated/cached from the 
>> "pageformat" supplied by the user.
>>
>> But, when PrinterJob.print(PrintRequestAttributeSet) is called, it 
>> calls setAttributes(attributes) where "attributes" is what is 
>> populated by the user. It does not contain orientation,media and 
>> mediaprintablearea attributes for this bug, so setAttributes sets 
>> cached attribute with this user-set attribute instance
>> />>else {//
>> //>>            // for AWT where pageable is not an instance of 
>> OpenBook,//
>> //>>            // we need to save paper info//
>> // >>           this.attributes = attributes;//
>> // >>       }//
>> /
>>
>> //thereby losing the attributes it has cached earlier from user 
>> pageformat. I think we should check if this.attributes is not null, 
>> then retain those attributes unless explicitly set by the user in 
>> user-defined attributes.
>>
>> But, this code is used by windows,linux,mac so it needs to be tested 
>> against all those platforms to ensure we are not regressing anything.
>>
>> Also, I think user should call validatePage(PageFormat) in 
>> application to check if the settings passed is compatible with the 
>> printer or not, get compatible/adjusted pageformat and call 
>> setPrintable() with that "adjusted" pageformat. If user pass 
>> 0,0,fullpaperwidth,fullpaperheight as imageablearea, then he should 
>> not expect this setting to be used since printer will have its own 
>> hardware limitation (and use some offset printing)
>>
>> BTW, a regression testcase (even if it is manual) should be created 
>> with the fix.
>>
>> Regards
>> Prasanta
>> On 3/17/2017 10:59 PM, Anton Litvinov wrote:
>>> Hello,
>>>
>>> Could you please review the following fix for the bug.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8167102
>>> Webrev: http://cr.openjdk.java.net/~alitvinov/8167102/jdk9/webrev.00
>>>
>>> The bug consists in the fact that, if the user's application 
>>> specifies the required page size (media size) through 
>>> "java.awt.print.PrinterJob" API particularly via 
>>> "java.awt.print.PageFormat" instance supplied to the method 
>>> "PrinterJob.setPrintable(Printable, PageFormat)" and calls 
>>> "PrinterJob.print(PrintRequestAttributeSet)" with 
>>> "javax.print.attribute.PrintRequestAttributeSet" containing at least 
>>> 1 any "PrintRequestAttribute", then the page or pages will be 
>>> printed with "PageFormat" describing the default page size of the 
>>> printer which is different from the expected and originally set by 
>>> the user's application "PageFormat".
>>>
>>> Debugging showed that the new "PageFormat" with unexpected media 
>>> size is created in the method 
>>> "sun.print.RasterPrinterJob.getPageFormatFromAttributes()" which is 
>>> invoked from the native function 
>>> "jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m::javaPrinterJobToNSPrintInfo". 
>>> The method "RasterPrinterJob.getPageFormatFromAttributes()" returns 
>>> a new "PageFormat" always, if the provided by the user 
>>> "PrintRequestAttributeSet" is not empty, and the default values are 
>>> set to particular instance variables of this "PageFormat", if 
>>> "PrintRequestAttributeSet" does not contain the searched 
>>> "OrientationRequested", "MediaSizeName", "MediaPrintableArea" 
>>> attributes.
>>>
>>> THE SOLUTION:
>>> Although it is clearly stated in Java Platform SE 8 API 
>>> Specification (documentation of the method 
>>> "PrinterJob.print(PrintRequestAttributeSet)")
>>> Specification URL: 
>>> http://docs.oracle.com/javase/8/docs/api/java/awt/print/PrinterJob.html#print-javax.print.attribute.PrintRequestAttributeSet-
>>>
>>> that media size, orientation and imageable area attributes specified 
>>> in "PrintRequestAttributeSet" supplied to the method 
>>> "PrinterJob.print" will be used for construction of a new 
>>> "PageFormat", which will be passed to "Printable" object, instead of 
>>> the original "PageFormat" instance set through 
>>> "PrinterJob.setPrintable" method, the observed in this issue 
>>> behavior is a bug, because in the bug test case neither media size, 
>>> nor orientation, nor imageable area attributes are specified in 
>>> "PrintRequestAttributeSet".
>>>
>>> The fix alters the method 
>>> "sun.print.RasterPrinterJob.getPageFormatFromAttributes()" to use 
>>> corresponding values from "PageFormat" instance originally set 
>>> through "PrinterJob" API during construction of the new 
>>> "PageFormat", when it is found out that "OrientationRequested", or 
>>> "MediaSizeName", or "MediaPrintableArea" attribute is not specified 
>>> in "PrintRequestAttributeSet" supplied to "PrinterJob.print" method.
>>>
>>> Thank you,
>>> Anton
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20170322/b163cf76/attachment.html>

From sergey.bylokhov at oracle.com  Thu Mar 23 14:24:29 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 23 Mar 2017 17:24:29 +0300
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8177461 Wrong references are
 used in the javadoc in the java.desktop module
Message-ID: <553C207F-3FC6-4A78-8F82-3F30E5150B19@oracle.com>

Hello,
Please review the fix for jdk9.

In java.desktop module in a various places we use incorrect links.
Most of them are in the documentation in non-public classes/methods(But there are two places in public API - specdiff is provided)

Common issues:
 - The method is referenced without #
 - The method which have some parameters is referenced as ?#method()? instead of ?#method? or ?#method(ParameterDescription)"
 - The type which is referenced is not imported
 - The reference to non-existed method/type.
 - Copy pasted javadoc was removed.
 - The type was renamed (like AppReOpenedListener to AppReopenedListener)


Bug: https://bugs.openjdk.java.net/browse/JDK-8177461
Webrev can be found at: http://cr.openjdk.java.net/~serb/8177461/webrev.00
Specdiff: http://cr.openjdk.java.net/~serb/8177461/specdiff/overview-summary.html

From anton.litvinov at oracle.com  Sun Mar 26 22:02:10 2017
From: anton.litvinov at oracle.com (Anton Litvinov)
Date: Mon, 27 Mar 2017 01:02:10 +0300
Subject: [OpenJDK 2D-Dev] [9] Review request for 8167102: [macosx]
 PrintRequestAttributeSet breaks page size set using PageFormat
In-Reply-To: <b5efdb91-dd13-045f-18bd-f95830ba61fe@oracle.com>
References: <17a96ade-ea01-95bd-728a-ec3106d1fbfa@oracle.com>
 <ae716330-c0c4-9b2c-4f6b-c30855e659dc@oracle.com>
 <7d710d7a-386f-a6c3-7f6d-13e56a7309a6@oracle.com>
 <b5efdb91-dd13-045f-18bd-f95830ba61fe@oracle.com>
Message-ID: <89b66f3b-d1f0-5c88-1b7c-6065ad6ce4da@oracle.com>

Hello Prasanta,

I verified that the bug is not reproducible using JDK 9 compiled from 
the latest version of "jdk9/client" forest neither on Windows, nor on 
Linux platform, therefore, yes, this bug is only Mac specific. Debugging 
showed that on Windows platform the behavior is exactly like you 
described, on Windows "RasterPrinterJob.print(PrintRequestAttributeSet)" 
method is responsible for printing the documents and in this method 
"RasterPrinterJob.printPage(Pageable, int)" is called for each page 
separately, and in this "printPage" method "PageFormat" instance used 
for printing of the page is extracted from the the transferred as the 
method argument instance of "Pageable" by the expression "origPage = 
document.getPageFormat(pageIndex);".

The new version of the fix was created. Could you please review the 
second version of the fix.

Webrev (the 2nd version): 
http://cr.openjdk.java.net/~alitvinov/8167102/jdk9/webrev.01

In the second version of the fix:
1. Calling for "RasterPrinterJob.getPageFormatFromAttributes()" was 
substituted for "sun.lwawt.macosx.CPrinterJob.getPageFormat(int)" in the 
native method "CPrinterJob.m#javaPrinterJobToNSPrintInfo".
2. The method "RasterPrinterJob.getPageFormatFromAttributes()" was 
removed, since it is not called from any other code in "jdk" repository.
3. The manual regression test was created.

Also on OS X I executed all manual and automatic "jtreg" regression 
tests related to printing from the listed below directories and the 
corresponding directories in the closed repositories using both JDK 9 
compiled without and with the fix, and I verified that no new test 
failed on JDK 9 with the fix.

The directories with the regression tests from open repositories:
- "jdk/test/java/awt/print"
- "jdk/test/javax/print"

Thank you,
Anton

On 3/22/2017 7:42 AM, Prasanta Sadhukhan wrote:
>
> Hi Anton,
>
> I thought about your point and have a question: does this issue not 
> reproduce in non-mac platform?
> I thought it probably would so suggested modifying setAttributes() . 
> But, if it is only reproduced in mac, we need to find out why despite 
> this setAttributes() flaw, how this is working in non-mac platform?
>
> It probably might work in windows/linux because in 
> RasterPrinterJob.print(attr) method, after it calls setAttributes(), 
> it calls printPage() where it gets the original PageFormat
> by calling getPageFormat(pageIndex) and gets the orientation, 
> imageablearea
> and not by constructing pageFormat from attributes as it is done in mac.
> So, probably, in mac also, we need to do away with 
> getPageFormatFromAttributes() call  and call getPageFormat(pageIndex) 
> from CPrinterJob.m#javaPrinterJobToNSPrintInfo().
>
> Regards
> Prasanta
> On 3/21/2017 8:15 PM, Anton Litvinov wrote:
>> Hello Prasanta,
>>
>> Thank you for review of this fix. I have tried to apply the approach 
>> which you suggested and it allowed to resolve the issue. In this case 
>> I agree that it would be more correct to resolve the issue in 
>> "RasterPrinterJob.setAttributes(PrintRequestAttributeSet)" method. In 
>> the first version of the fix I decided to change the method 
>> "RasterPrinterJob.getPageFormatFromAttributes()", because it is 
>> invoked only from 1 place in JDK code and this place is located in OS 
>> X specific code 
>> "jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m", 
>> so that would automatically minimize the affected by the fix 
>> platforms to OS X only.
>>
>> Starting to work on implementation of the second version of the fix 
>> including the regression test.
>>
>> Thank you,
>> Anton
>>
>> On 3/21/2017 12:52 PM, Prasanta Sadhukhan wrote:
>>>
>>> I think the real problem is not in 
>>> RasterPrinterJob.getPageFormatFromAttributes().
>>>
>>> One can see that, when we call RasterPrinterJob.setPrintable(), we 
>>> call updatePageAttributes() which in turn calls 
>>> updateAttributesWithPageFormat() where orientation, media and 
>>> mediaprintablearea "attributes" get populated/cached from the 
>>> "pageformat" supplied by the user.
>>>
>>> But, when PrinterJob.print(PrintRequestAttributeSet) is called, it 
>>> calls setAttributes(attributes) where "attributes" is what is 
>>> populated by the user. It does not contain orientation,media and 
>>> mediaprintablearea attributes for this bug, so setAttributes sets 
>>> cached attribute with this user-set attribute instance
>>> />>else {//
>>> //>>            // for AWT where pageable is not an instance of 
>>> OpenBook,//
>>> //>>            // we need to save paper info//
>>> // >>           this.attributes = attributes;//
>>> // >>       }//
>>> /
>>>
>>> //thereby losing the attributes it has cached earlier from user 
>>> pageformat. I think we should check if this.attributes is not null, 
>>> then retain those attributes unless explicitly set by the user in 
>>> user-defined attributes.
>>>
>>> But, this code is used by windows,linux,mac so it needs to be tested 
>>> against all those platforms to ensure we are not regressing anything.
>>>
>>> Also, I think user should call validatePage(PageFormat) in 
>>> application to check if the settings passed is compatible with the 
>>> printer or not, get compatible/adjusted pageformat and call 
>>> setPrintable() with that "adjusted" pageformat. If user pass 
>>> 0,0,fullpaperwidth,fullpaperheight as imageablearea, then he should 
>>> not expect this setting to be used since printer will have its own 
>>> hardware limitation (and use some offset printing)
>>>
>>> BTW, a regression testcase (even if it is manual) should be created 
>>> with the fix.
>>>
>>> Regards
>>> Prasanta
>>> On 3/17/2017 10:59 PM, Anton Litvinov wrote:
>>>> Hello,
>>>>
>>>> Could you please review the following fix for the bug.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8167102
>>>> Webrev: http://cr.openjdk.java.net/~alitvinov/8167102/jdk9/webrev.00
>>>>
>>>> The bug consists in the fact that, if the user's application 
>>>> specifies the required page size (media size) through 
>>>> "java.awt.print.PrinterJob" API particularly via 
>>>> "java.awt.print.PageFormat" instance supplied to the method 
>>>> "PrinterJob.setPrintable(Printable, PageFormat)" and calls 
>>>> "PrinterJob.print(PrintRequestAttributeSet)" with 
>>>> "javax.print.attribute.PrintRequestAttributeSet" containing at 
>>>> least 1 any "PrintRequestAttribute", then the page or pages will be 
>>>> printed with "PageFormat" describing the default page size of the 
>>>> printer which is different from the expected and originally set by 
>>>> the user's application "PageFormat".
>>>>
>>>> Debugging showed that the new "PageFormat" with unexpected media 
>>>> size is created in the method 
>>>> "sun.print.RasterPrinterJob.getPageFormatFromAttributes()" which is 
>>>> invoked from the native function 
>>>> "jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m::javaPrinterJobToNSPrintInfo". 
>>>> The method "RasterPrinterJob.getPageFormatFromAttributes()" returns 
>>>> a new "PageFormat" always, if the provided by the user 
>>>> "PrintRequestAttributeSet" is not empty, and the default values are 
>>>> set to particular instance variables of this "PageFormat", if 
>>>> "PrintRequestAttributeSet" does not contain the searched 
>>>> "OrientationRequested", "MediaSizeName", "MediaPrintableArea" 
>>>> attributes.
>>>>
>>>> THE SOLUTION:
>>>> Although it is clearly stated in Java Platform SE 8 API 
>>>> Specification (documentation of the method 
>>>> "PrinterJob.print(PrintRequestAttributeSet)")
>>>> Specification URL: 
>>>> http://docs.oracle.com/javase/8/docs/api/java/awt/print/PrinterJob.html#print-javax.print.attribute.PrintRequestAttributeSet-
>>>>
>>>> that media size, orientation and imageable area attributes 
>>>> specified in "PrintRequestAttributeSet" supplied to the method 
>>>> "PrinterJob.print" will be used for construction of a new 
>>>> "PageFormat", which will be passed to "Printable" object, instead 
>>>> of the original "PageFormat" instance set through 
>>>> "PrinterJob.setPrintable" method, the observed in this issue 
>>>> behavior is a bug, because in the bug test case neither media size, 
>>>> nor orientation, nor imageable area attributes are specified in 
>>>> "PrintRequestAttributeSet".
>>>>
>>>> The fix alters the method 
>>>> "sun.print.RasterPrinterJob.getPageFormatFromAttributes()" to use 
>>>> corresponding values from "PageFormat" instance originally set 
>>>> through "PrinterJob" API during construction of the new 
>>>> "PageFormat", when it is found out that "OrientationRequested", or 
>>>> "MediaSizeName", or "MediaPrintableArea" attribute is not specified 
>>>> in "PrintRequestAttributeSet" supplied to "PrinterJob.print" method.
>>>>
>>>> Thank you,
>>>> Anton
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20170327/44869a6a/attachment.html>

From prasanta.sadhukhan at oracle.com  Mon Mar 27 06:52:31 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Mon, 27 Mar 2017 12:22:31 +0530
Subject: [OpenJDK 2D-Dev] [9] Review request for 8167102: [macosx]
 PrintRequestAttributeSet breaks page size set using PageFormat
In-Reply-To: <89b66f3b-d1f0-5c88-1b7c-6065ad6ce4da@oracle.com>
References: <17a96ade-ea01-95bd-728a-ec3106d1fbfa@oracle.com>
 <ae716330-c0c4-9b2c-4f6b-c30855e659dc@oracle.com>
 <7d710d7a-386f-a6c3-7f6d-13e56a7309a6@oracle.com>
 <b5efdb91-dd13-045f-18bd-f95830ba61fe@oracle.com>
 <89b66f3b-d1f0-5c88-1b7c-6065ad6ce4da@oracle.com>
Message-ID: <ce891f45-bc5e-ec00-8074-880e26b93f39@oracle.com>

Hi Anton,

Ok. So, it seems it mac specific. But, are you sure wrong page size is 
used in mac as is claimed in the bug?
I thought we could use automated regression test instead of manual by 
checking pageformat value in print() as compared to what user passes in 
setPrintable().

Then, I see in print() method in testcase, the "PageFormat" argument 
passed has same values as it is passed in setPrintable() in main() even 
without your fix.

If I reverse trace from print() method present in testcase, I see it is 
called from CPrinterJob.java#printAndGetPageFormatArea()
which is called from PrinterView.m#rectForPage. And before calling 
printAndGetPageFormatArea() it calls 
getPageformatPrintablePeekgraphics() which calls 
pageable.getPageFormat(pageIndex), so it should behave same as windows. 
Am I missing something?

Regards
Prasanta
On 3/27/2017 3:32 AM, Anton Litvinov wrote:
> Hello Prasanta,
>
> I verified that the bug is not reproducible using JDK 9 compiled from 
> the latest version of "jdk9/client" forest neither on Windows, nor on 
> Linux platform, therefore, yes, this bug is only Mac specific. 
> Debugging showed that on Windows platform the behavior is exactly like 
> you described, on Windows 
> "RasterPrinterJob.print(PrintRequestAttributeSet)" method is 
> responsible for printing the documents and in this method 
> "RasterPrinterJob.printPage(Pageable, int)" is called for each page 
> separately, and in this "printPage" method "PageFormat" instance used 
> for printing of the page is extracted from the the transferred as the 
> method argument instance of "Pageable" by the expression "origPage = 
> document.getPageFormat(pageIndex);".
>
> The new version of the fix was created. Could you please review the 
> second version of the fix.
>
> Webrev (the 2nd version): 
> http://cr.openjdk.java.net/~alitvinov/8167102/jdk9/webrev.01
>
> In the second version of the fix:
> 1. Calling for "RasterPrinterJob.getPageFormatFromAttributes()" was 
> substituted for "sun.lwawt.macosx.CPrinterJob.getPageFormat(int)" in 
> the native method "CPrinterJob.m#javaPrinterJobToNSPrintInfo".
> 2. The method "RasterPrinterJob.getPageFormatFromAttributes()" was 
> removed, since it is not called from any other code in "jdk" repository.
> 3. The manual regression test was created.
>
> Also on OS X I executed all manual and automatic "jtreg" regression 
> tests related to printing from the listed below directories and the 
> corresponding directories in the closed repositories using both JDK 9 
> compiled without and with the fix, and I verified that no new test 
> failed on JDK 9 with the fix.
>
> The directories with the regression tests from open repositories:
> - "jdk/test/java/awt/print"
> - "jdk/test/javax/print"
>
> Thank you,
> Anton
>
> On 3/22/2017 7:42 AM, Prasanta Sadhukhan wrote:
>>
>> Hi Anton,
>>
>> I thought about your point and have a question: does this issue not 
>> reproduce in non-mac platform?
>> I thought it probably would so suggested modifying setAttributes() . 
>> But, if it is only reproduced in mac, we need to find out why despite 
>> this setAttributes() flaw, how this is working in non-mac platform?
>>
>> It probably might work in windows/linux because in 
>> RasterPrinterJob.print(attr) method, after it calls setAttributes(), 
>> it calls printPage() where it gets the original PageFormat
>> by calling getPageFormat(pageIndex) and gets the orientation, 
>> imageablearea
>> and not by constructing pageFormat from attributes as it is done in mac.
>> So, probably, in mac also, we need to do away with 
>> getPageFormatFromAttributes() call  and call getPageFormat(pageIndex) 
>> from CPrinterJob.m#javaPrinterJobToNSPrintInfo().
>>
>> Regards
>> Prasanta
>> On 3/21/2017 8:15 PM, Anton Litvinov wrote:
>>> Hello Prasanta,
>>>
>>> Thank you for review of this fix. I have tried to apply the approach 
>>> which you suggested and it allowed to resolve the issue. In this 
>>> case I agree that it would be more correct to resolve the issue in 
>>> "RasterPrinterJob.setAttributes(PrintRequestAttributeSet)" method. 
>>> In the first version of the fix I decided to change the method 
>>> "RasterPrinterJob.getPageFormatFromAttributes()", because it is 
>>> invoked only from 1 place in JDK code and this place is located in 
>>> OS X specific code 
>>> "jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m", 
>>> so that would automatically minimize the affected by the fix 
>>> platforms to OS X only.
>>>
>>> Starting to work on implementation of the second version of the fix 
>>> including the regression test.
>>>
>>> Thank you,
>>> Anton
>>>
>>> On 3/21/2017 12:52 PM, Prasanta Sadhukhan wrote:
>>>>
>>>> I think the real problem is not in 
>>>> RasterPrinterJob.getPageFormatFromAttributes().
>>>>
>>>> One can see that, when we call RasterPrinterJob.setPrintable(), we 
>>>> call updatePageAttributes() which in turn calls 
>>>> updateAttributesWithPageFormat() where orientation, media and 
>>>> mediaprintablearea "attributes" get populated/cached from the 
>>>> "pageformat" supplied by the user.
>>>>
>>>> But, when PrinterJob.print(PrintRequestAttributeSet) is called, it 
>>>> calls setAttributes(attributes) where "attributes" is what is 
>>>> populated by the user. It does not contain orientation,media and 
>>>> mediaprintablearea attributes for this bug, so setAttributes sets 
>>>> cached attribute with this user-set attribute instance
>>>> />>else {//
>>>> //>>            // for AWT where pageable is not an instance of 
>>>> OpenBook,//
>>>> //>>            // we need to save paper info//
>>>> // >>           this.attributes = attributes;//
>>>> // >>       }//
>>>> /
>>>>
>>>> //thereby losing the attributes it has cached earlier from user 
>>>> pageformat. I think we should check if this.attributes is not null, 
>>>> then retain those attributes unless explicitly set by the user in 
>>>> user-defined attributes.
>>>>
>>>> But, this code is used by windows,linux,mac so it needs to be 
>>>> tested against all those platforms to ensure we are not regressing 
>>>> anything.
>>>>
>>>> Also, I think user should call validatePage(PageFormat) in 
>>>> application to check if the settings passed is compatible with the 
>>>> printer or not, get compatible/adjusted pageformat and call 
>>>> setPrintable() with that "adjusted" pageformat. If user pass 
>>>> 0,0,fullpaperwidth,fullpaperheight as imageablearea, then he should 
>>>> not expect this setting to be used since printer will have its own 
>>>> hardware limitation (and use some offset printing)
>>>>
>>>> BTW, a regression testcase (even if it is manual) should be created 
>>>> with the fix.
>>>>
>>>> Regards
>>>> Prasanta
>>>> On 3/17/2017 10:59 PM, Anton Litvinov wrote:
>>>>> Hello,
>>>>>
>>>>> Could you please review the following fix for the bug.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8167102
>>>>> Webrev: http://cr.openjdk.java.net/~alitvinov/8167102/jdk9/webrev.00
>>>>>
>>>>> The bug consists in the fact that, if the user's application 
>>>>> specifies the required page size (media size) through 
>>>>> "java.awt.print.PrinterJob" API particularly via 
>>>>> "java.awt.print.PageFormat" instance supplied to the method 
>>>>> "PrinterJob.setPrintable(Printable, PageFormat)" and calls 
>>>>> "PrinterJob.print(PrintRequestAttributeSet)" with 
>>>>> "javax.print.attribute.PrintRequestAttributeSet" containing at 
>>>>> least 1 any "PrintRequestAttribute", then the page or pages will 
>>>>> be printed with "PageFormat" describing the default page size of 
>>>>> the printer which is different from the expected and originally 
>>>>> set by the user's application "PageFormat".
>>>>>
>>>>> Debugging showed that the new "PageFormat" with unexpected media 
>>>>> size is created in the method 
>>>>> "sun.print.RasterPrinterJob.getPageFormatFromAttributes()" which 
>>>>> is invoked from the native function 
>>>>> "jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m::javaPrinterJobToNSPrintInfo". 
>>>>> The method "RasterPrinterJob.getPageFormatFromAttributes()" 
>>>>> returns a new "PageFormat" always, if the provided by the user 
>>>>> "PrintRequestAttributeSet" is not empty, and the default values 
>>>>> are set to particular instance variables of this "PageFormat", if 
>>>>> "PrintRequestAttributeSet" does not contain the searched 
>>>>> "OrientationRequested", "MediaSizeName", "MediaPrintableArea" 
>>>>> attributes.
>>>>>
>>>>> THE SOLUTION:
>>>>> Although it is clearly stated in Java Platform SE 8 API 
>>>>> Specification (documentation of the method 
>>>>> "PrinterJob.print(PrintRequestAttributeSet)")
>>>>> Specification URL: 
>>>>> http://docs.oracle.com/javase/8/docs/api/java/awt/print/PrinterJob.html#print-javax.print.attribute.PrintRequestAttributeSet-
>>>>>
>>>>> that media size, orientation and imageable area attributes 
>>>>> specified in "PrintRequestAttributeSet" supplied to the method 
>>>>> "PrinterJob.print" will be used for construction of a new 
>>>>> "PageFormat", which will be passed to "Printable" object, instead 
>>>>> of the original "PageFormat" instance set through 
>>>>> "PrinterJob.setPrintable" method, the observed in this issue 
>>>>> behavior is a bug, because in the bug test case neither media 
>>>>> size, nor orientation, nor imageable area attributes are specified 
>>>>> in "PrintRequestAttributeSet".
>>>>>
>>>>> The fix alters the method 
>>>>> "sun.print.RasterPrinterJob.getPageFormatFromAttributes()" to use 
>>>>> corresponding values from "PageFormat" instance originally set 
>>>>> through "PrinterJob" API during construction of the new 
>>>>> "PageFormat", when it is found out that "OrientationRequested", or 
>>>>> "MediaSizeName", or "MediaPrintableArea" attribute is not 
>>>>> specified in "PrintRequestAttributeSet" supplied to 
>>>>> "PrinterJob.print" method.
>>>>>
>>>>> Thank you,
>>>>> Anton
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20170327/464c51cf/attachment.html>

From anton.litvinov at oracle.com  Mon Mar 27 16:35:10 2017
From: anton.litvinov at oracle.com (Anton Litvinov)
Date: Mon, 27 Mar 2017 19:35:10 +0300
Subject: [OpenJDK 2D-Dev] [9] Review request for 8167102: [macosx]
 PrintRequestAttributeSet breaks page size set using PageFormat
In-Reply-To: <ce891f45-bc5e-ec00-8074-880e26b93f39@oracle.com>
References: <17a96ade-ea01-95bd-728a-ec3106d1fbfa@oracle.com>
 <ae716330-c0c4-9b2c-4f6b-c30855e659dc@oracle.com>
 <7d710d7a-386f-a6c3-7f6d-13e56a7309a6@oracle.com>
 <b5efdb91-dd13-045f-18bd-f95830ba61fe@oracle.com>
 <89b66f3b-d1f0-5c88-1b7c-6065ad6ce4da@oracle.com>
 <ce891f45-bc5e-ec00-8074-880e26b93f39@oracle.com>
Message-ID: <43402a5f-4e4b-ce6f-262d-e6b21176fb99@oracle.com>

Hello Prasanta,

Indeed it is Mac specific, as it was written in my previous e-mail, I 
verified this fact on Windows OS and Linux OS by your request.

Yes, I am fully sure that, when the bug occurs, the paper size of the 
printed page is wrong, as it is stated in the bug, and I am fully sure 
that with the applied any of 2 versions of the created fix, the paper 
size of the printed page becomes correct and as expected. Otherwise, I 
would not send the fix for review. The instruction, by following which 
the bug can be reproduced, is written in "STEPS TO FOLLOW TO REPRODUCE 
THE PROBLEM :" section of the description of the bug in JBS. This bug is 
raised by the user, who owns a support contract and requests for 
resolution of this bug, this can be seen in proper comments of the bug 
record.

The automated regression test is not possible for this bug, since it is 
necessary to verify visually that the document is physically printed on 
the paper of the expected size. Otherwise, I would send the 1st version 
of the fix with the automated test already, it is not the first bug in 
JDK on which I have been working. By your request the regression test, 
even though it is manual, was created and added to the 2nd version of 
the fix.

Yes, it is correct, the implemented by the test, and the test case 
method "Printable.print(Graphics, PageFormat, int)" receives the correct 
instance of "PageFormat" in runtime in scenario described in this bug, 
because, as you already described, it is extracted using the expression 
"pageable.getPageFormat(pageIndex)" in the Java method 
"sun.lwawt.macosx.CPrinterJob.getPageformatPrintablePeekgraphics(int)" 
called from "PrinterView.m::rectForPage:(NSInteger)" and further 
transferred in this method to the Java method 
"sun.lwawt.macosx.CPrinterJob.printAndGetPageFormatArea".

The wrong paper size which is returned from the method 
"RasterPrinterJob.getPageFormatFromAttributes()" and which is set to 
certain fields of the Objective-C  object "NSPrintInfo" in the function 
"CPrinterJob.m::javaPaperToNSPrintInfo" through the next call sequence

CPrinterJob.m::printLoop() --> 
CPrinterJob.m::javaPrinterJobToNSPrintInfo() --> 
CPrinterJob.m::javaPageFormatToNSPrintInfo() --> 
CPrinterJob.m::javaPaperToNSPrintInfo()

further influences physical size of all pages printed by 1 printer job.

Thus, I consider that firstly "PageFormat" returned from 
"RasterPrinterJob.getPageFormatFromAttributes()" is wrong, and secondly 
setting paper size from this wrong "PageFormat" to proper fields of 
"NSPrintInfo" object is also incorrect and is a root cause of this bug.

Implementation of Java Print Server API surely contains many issues, and 
only working on this bug I already encountered 2 additional different 
issues, which are described in one of my comments in this bug record in 
JBS. However, I prefer to resolve issues separately and to resolve this 
particular bug also separately from other issues which we can 
indefinitely find while looking at the code and debugging it, also 
because it is necessary to deliver the fix for this bug to "jdk8u-dev" 
repository finally, while JDK 9 is currently in RDP 2 phase at which 
large fixes affecting more platforms or large code scope would hardly be 
accepted by Group and Area leads or the release team.

I would like to bring also your attention again to the fact, which was 
mentioned in my previous e-mail, that I already ran all manual and 
automatic "jtreg" regression tests related to printing from open and 
closed parts of JDK on JDK 9 without the fix and with the fix, what is 
198 tests.

Do you find anything incorrect in the 2nd version of the fix? Will you 
approve the 2nd version of the fix?

Thank you,
Anton

On 3/27/2017 9:52 AM, Prasanta Sadhukhan wrote:
>
> Hi Anton,
>
> Ok. So, it seems it mac specific. But, are you sure wrong page size is 
> used in mac as is claimed in the bug?
> I thought we could use automated regression test instead of manual by 
> checking pageformat value in print() as compared to what user passes 
> in setPrintable().
>
> Then, I see in print() method in testcase, the "PageFormat" argument 
> passed has same values as it is passed in setPrintable() in main() 
> even without your fix.
>
> If I reverse trace from print() method present in testcase, I see it 
> is called from CPrinterJob.java#printAndGetPageFormatArea()
> which is called from PrinterView.m#rectForPage. And before calling 
> printAndGetPageFormatArea() it calls 
> getPageformatPrintablePeekgraphics() which calls 
> pageable.getPageFormat(pageIndex), so it should behave same as 
> windows. Am I missing something?
>
> Regards
> Prasanta
> On 3/27/2017 3:32 AM, Anton Litvinov wrote:
>> Hello Prasanta,
>>
>> I verified that the bug is not reproducible using JDK 9 compiled from 
>> the latest version of "jdk9/client" forest neither on Windows, nor on 
>> Linux platform, therefore, yes, this bug is only Mac specific. 
>> Debugging showed that on Windows platform the behavior is exactly 
>> like you described, on Windows 
>> "RasterPrinterJob.print(PrintRequestAttributeSet)" method is 
>> responsible for printing the documents and in this method 
>> "RasterPrinterJob.printPage(Pageable, int)" is called for each page 
>> separately, and in this "printPage" method "PageFormat" instance used 
>> for printing of the page is extracted from the the transferred as the 
>> method argument instance of "Pageable" by the expression "origPage = 
>> document.getPageFormat(pageIndex);".
>>
>> The new version of the fix was created. Could you please review the 
>> second version of the fix.
>>
>> Webrev (the 2nd version): 
>> http://cr.openjdk.java.net/~alitvinov/8167102/jdk9/webrev.01
>>
>> In the second version of the fix:
>> 1. Calling for "RasterPrinterJob.getPageFormatFromAttributes()" was 
>> substituted for "sun.lwawt.macosx.CPrinterJob.getPageFormat(int)" in 
>> the native method "CPrinterJob.m#javaPrinterJobToNSPrintInfo".
>> 2. The method "RasterPrinterJob.getPageFormatFromAttributes()" was 
>> removed, since it is not called from any other code in "jdk" repository.
>> 3. The manual regression test was created.
>>
>> Also on OS X I executed all manual and automatic "jtreg" regression 
>> tests related to printing from the listed below directories and the 
>> corresponding directories in the closed repositories using both JDK 9 
>> compiled without and with the fix, and I verified that no new test 
>> failed on JDK 9 with the fix.
>>
>> The directories with the regression tests from open repositories:
>> - "jdk/test/java/awt/print"
>> - "jdk/test/javax/print"
>>
>> Thank you,
>> Anton
>>
>> On 3/22/2017 7:42 AM, Prasanta Sadhukhan wrote:
>>>
>>> Hi Anton,
>>>
>>> I thought about your point and have a question: does this issue not 
>>> reproduce in non-mac platform?
>>> I thought it probably would so suggested modifying setAttributes() . 
>>> But, if it is only reproduced in mac, we need to find out why 
>>> despite this setAttributes() flaw, how this is working in non-mac 
>>> platform?
>>>
>>> It probably might work in windows/linux because in 
>>> RasterPrinterJob.print(attr) method, after it calls setAttributes(), 
>>> it calls printPage() where it gets the original PageFormat
>>> by calling getPageFormat(pageIndex) and gets the orientation, 
>>> imageablearea
>>> and not by constructing pageFormat from attributes as it is done in mac.
>>> So, probably, in mac also, we need to do away with 
>>> getPageFormatFromAttributes() call  and call 
>>> getPageFormat(pageIndex) from 
>>> CPrinterJob.m#javaPrinterJobToNSPrintInfo().
>>>
>>> Regards
>>> Prasanta
>>> On 3/21/2017 8:15 PM, Anton Litvinov wrote:
>>>> Hello Prasanta,
>>>>
>>>> Thank you for review of this fix. I have tried to apply the 
>>>> approach which you suggested and it allowed to resolve the issue. 
>>>> In this case I agree that it would be more correct to resolve the 
>>>> issue in "RasterPrinterJob.setAttributes(PrintRequestAttributeSet)" 
>>>> method. In the first version of the fix I decided to change the 
>>>> method "RasterPrinterJob.getPageFormatFromAttributes()", because it 
>>>> is invoked only from 1 place in JDK code and this place is located 
>>>> in OS X specific code 
>>>> "jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m", 
>>>> so that would automatically minimize the affected by the fix 
>>>> platforms to OS X only.
>>>>
>>>> Starting to work on implementation of the second version of the fix 
>>>> including the regression test.
>>>>
>>>> Thank you,
>>>> Anton
>>>>
>>>> On 3/21/2017 12:52 PM, Prasanta Sadhukhan wrote:
>>>>>
>>>>> I think the real problem is not in 
>>>>> RasterPrinterJob.getPageFormatFromAttributes().
>>>>>
>>>>> One can see that, when we call RasterPrinterJob.setPrintable(), we 
>>>>> call updatePageAttributes() which in turn calls 
>>>>> updateAttributesWithPageFormat() where orientation, media and 
>>>>> mediaprintablearea "attributes" get populated/cached from the 
>>>>> "pageformat" supplied by the user.
>>>>>
>>>>> But, when PrinterJob.print(PrintRequestAttributeSet) is called, it 
>>>>> calls setAttributes(attributes) where "attributes" is what is 
>>>>> populated by the user. It does not contain orientation,media and 
>>>>> mediaprintablearea attributes for this bug, so setAttributes sets 
>>>>> cached attribute with this user-set attribute instance
>>>>> />>else {//
>>>>> //>>            // for AWT where pageable is not an instance of 
>>>>> OpenBook,//
>>>>> //>>            // we need to save paper info//
>>>>> // >>           this.attributes = attributes;//
>>>>> // >>       }//
>>>>> /
>>>>>
>>>>> //thereby losing the attributes it has cached earlier from user 
>>>>> pageformat. I think we should check if this.attributes is not 
>>>>> null, then retain those attributes unless explicitly set by the 
>>>>> user in user-defined attributes.
>>>>>
>>>>> But, this code is used by windows,linux,mac so it needs to be 
>>>>> tested against all those platforms to ensure we are not regressing 
>>>>> anything.
>>>>>
>>>>> Also, I think user should call validatePage(PageFormat) in 
>>>>> application to check if the settings passed is compatible with the 
>>>>> printer or not, get compatible/adjusted pageformat and call 
>>>>> setPrintable() with that "adjusted" pageformat. If user pass 
>>>>> 0,0,fullpaperwidth,fullpaperheight as imageablearea, then he 
>>>>> should not expect this setting to be used since printer will have 
>>>>> its own hardware limitation (and use some offset printing)
>>>>>
>>>>> BTW, a regression testcase (even if it is manual) should be 
>>>>> created with the fix.
>>>>>
>>>>> Regards
>>>>> Prasanta
>>>>> On 3/17/2017 10:59 PM, Anton Litvinov wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Could you please review the following fix for the bug.
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8167102
>>>>>> Webrev: http://cr.openjdk.java.net/~alitvinov/8167102/jdk9/webrev.00
>>>>>>
>>>>>> The bug consists in the fact that, if the user's application 
>>>>>> specifies the required page size (media size) through 
>>>>>> "java.awt.print.PrinterJob" API particularly via 
>>>>>> "java.awt.print.PageFormat" instance supplied to the method 
>>>>>> "PrinterJob.setPrintable(Printable, PageFormat)" and calls 
>>>>>> "PrinterJob.print(PrintRequestAttributeSet)" with 
>>>>>> "javax.print.attribute.PrintRequestAttributeSet" containing at 
>>>>>> least 1 any "PrintRequestAttribute", then the page or pages will 
>>>>>> be printed with "PageFormat" describing the default page size of 
>>>>>> the printer which is different from the expected and originally 
>>>>>> set by the user's application "PageFormat".
>>>>>>
>>>>>> Debugging showed that the new "PageFormat" with unexpected media 
>>>>>> size is created in the method 
>>>>>> "sun.print.RasterPrinterJob.getPageFormatFromAttributes()" which 
>>>>>> is invoked from the native function 
>>>>>> "jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m::javaPrinterJobToNSPrintInfo". 
>>>>>> The method "RasterPrinterJob.getPageFormatFromAttributes()" 
>>>>>> returns a new "PageFormat" always, if the provided by the user 
>>>>>> "PrintRequestAttributeSet" is not empty, and the default values 
>>>>>> are set to particular instance variables of this "PageFormat", if 
>>>>>> "PrintRequestAttributeSet" does not contain the searched 
>>>>>> "OrientationRequested", "MediaSizeName", "MediaPrintableArea" 
>>>>>> attributes.
>>>>>>
>>>>>> THE SOLUTION:
>>>>>> Although it is clearly stated in Java Platform SE 8 API 
>>>>>> Specification (documentation of the method 
>>>>>> "PrinterJob.print(PrintRequestAttributeSet)")
>>>>>> Specification URL: 
>>>>>> http://docs.oracle.com/javase/8/docs/api/java/awt/print/PrinterJob.html#print-javax.print.attribute.PrintRequestAttributeSet-
>>>>>>
>>>>>> that media size, orientation and imageable area attributes 
>>>>>> specified in "PrintRequestAttributeSet" supplied to the method 
>>>>>> "PrinterJob.print" will be used for construction of a new 
>>>>>> "PageFormat", which will be passed to "Printable" object, instead 
>>>>>> of the original "PageFormat" instance set through 
>>>>>> "PrinterJob.setPrintable" method, the observed in this issue 
>>>>>> behavior is a bug, because in the bug test case neither media 
>>>>>> size, nor orientation, nor imageable area attributes are 
>>>>>> specified in "PrintRequestAttributeSet".
>>>>>>
>>>>>> The fix alters the method 
>>>>>> "sun.print.RasterPrinterJob.getPageFormatFromAttributes()" to use 
>>>>>> corresponding values from "PageFormat" instance originally set 
>>>>>> through "PrinterJob" API during construction of the new 
>>>>>> "PageFormat", when it is found out that "OrientationRequested", 
>>>>>> or "MediaSizeName", or "MediaPrintableArea" attribute is not 
>>>>>> specified in "PrintRequestAttributeSet" supplied to 
>>>>>> "PrinterJob.print" method.
>>>>>>
>>>>>> Thank you,
>>>>>> Anton
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20170327/f5e3f8e4/attachment.html>

From prasanta.sadhukhan at oracle.com  Tue Mar 28 09:46:32 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Tue, 28 Mar 2017 15:16:32 +0530
Subject: [OpenJDK 2D-Dev] [9] Review request for 8167102: [macosx]
 PrintRequestAttributeSet breaks page size set using PageFormat
In-Reply-To: <43402a5f-4e4b-ce6f-262d-e6b21176fb99@oracle.com>
References: <17a96ade-ea01-95bd-728a-ec3106d1fbfa@oracle.com>
 <ae716330-c0c4-9b2c-4f6b-c30855e659dc@oracle.com>
 <7d710d7a-386f-a6c3-7f6d-13e56a7309a6@oracle.com>
 <b5efdb91-dd13-045f-18bd-f95830ba61fe@oracle.com>
 <89b66f3b-d1f0-5c88-1b7c-6065ad6ce4da@oracle.com>
 <ce891f45-bc5e-ec00-8074-880e26b93f39@oracle.com>
 <43402a5f-4e4b-ce6f-262d-e6b21176fb99@oracle.com>
Message-ID: <2fad447d-2219-e3a6-68c5-91fc4822eb29@oracle.com>

Hi Anton,


On 3/27/2017 10:05 PM, Anton Litvinov wrote:
> Hello Prasanta,
>
> Indeed it is Mac specific, as it was written in my previous e-mail, I 
> verified this fact on Windows OS and Linux OS by your request.
>
> Yes, I am fully sure that, when the bug occurs, the paper size of the 
> printed page is wrong, as it is stated in the bug, and I am fully sure 
> that with the applied any of 2 versions of the created fix, the paper 
> size of the printed page becomes correct and as expected. Otherwise, I 
> would not send the fix for review. The instruction, by following which 
> the bug can be reproduced, is written in "STEPS TO FOLLOW TO REPRODUCE 
> THE PROBLEM :" section of the description of the bug in JBS. This bug 
> is raised by the user, who owns a support contract and requests for 
> resolution of this bug, this can be seen in proper comments of the bug 
> record.
>
> The automated regression test is not possible for this bug, since it 
> is necessary to verify visually that the document is physically 
> printed on the paper of the expected size. Otherwise, I would send the 
> 1st version of the fix with the automated test already, it is not the 
> first bug in JDK on which I have been working. By your request the 
> regression test, even though it is manual, was created and added to 
> the 2nd version of the fix.
>
> Yes, it is correct, the implemented by the test, and the test case 
> method "Printable.print(Graphics, PageFormat, int)" receives the 
> correct instance of "PageFormat" in runtime in scenario described in 
> this bug, because, as you already described, it is extracted using the 
> expression "pageable.getPageFormat(pageIndex)" in the Java method 
> "sun.lwawt.macosx.CPrinterJob.getPageformatPrintablePeekgraphics(int)" 
> called from "PrinterView.m::rectForPage:(NSInteger)" and further 
> transferred in this method to the Java method 
> "sun.lwawt.macosx.CPrinterJob.printAndGetPageFormatArea".
>
> The wrong paper size which is returned from the method 
> "RasterPrinterJob.getPageFormatFromAttributes()" and which is set to 
> certain fields of the Objective-C  object "NSPrintInfo" in the 
> function "CPrinterJob.m::javaPaperToNSPrintInfo" through the next call 
> sequence
>
> CPrinterJob.m::printLoop() --> 
> CPrinterJob.m::javaPrinterJobToNSPrintInfo() --> 
> CPrinterJob.m::javaPageFormatToNSPrintInfo() --> 
> CPrinterJob.m::javaPaperToNSPrintInfo()
>
> further influences physical size of all pages printed by 1 printer job.
>
> Thus, I consider that firstly "PageFormat" returned from 
> "RasterPrinterJob.getPageFormatFromAttributes()" is wrong, and 
> secondly setting paper size from this wrong "PageFormat" to proper 
> fields of "NSPrintInfo" object is also incorrect and is a root cause 
> of this bug.
OK. So, pageformat values set to native NSPrintInfo is different (wrong) 
compared to what is being passed to user.
>
> Implementation of Java Print Server API surely contains many issues, 
> and only working on this bug I already encountered 2 additional 
> different issues, which are described in one of my comments in this 
> bug record in JBS. However, I prefer to resolve issues separately and 
> to resolve this particular bug also separately from other issues which 
> we can indefinitely find while looking at the code and debugging it, 
> also because it is necessary to deliver the fix for this bug to 
> "jdk8u-dev" repository finally, while JDK 9 is currently in RDP 2 
> phase at which large fixes affecting more platforms or large code 
> scope would hardly be accepted by Group and Area leads or the release 
> team.
>
> I would like to bring also your attention again to the fact, which was 
> mentioned in my previous e-mail, that I already ran all manual and 
> automatic "jtreg" regression tests related to printing from open and 
> closed parts of JDK on JDK 9 without the fix and with the fix, what is 
> 198 tests.
>
> Do you find anything incorrect in the 2nd version of the fix? Will you 
> approve the 2nd version of the fix?
>
I think there might be a (probable) issue with this fix.  PageFormat of 
1st page only is used to get the information.

jobject page = JNFCallObjectMethod(env, srcPrinterJob, jm_getPageFormat, 
(jint)0);

What if user has set different pageformat to different page like this 
below? Will it not lose the 2nd page pageformat? I guess in 
windows/linux, we obtain pageformat for each pageindex

PrinterJob job = PrinterJob.getPrinterJob();
// Create a landscape pageformat
PageFormat pfl = job.defaultPage();
pfl.setOrientation(PageFormat.LANDSCAPE);
//Setup a book
Book bk = new Book();
bk.append(new xPrintable(), pfl); // 1st page landscape , can be diff. 
pagesize too
bk.append(new xxPrintable(), job.defaultPage()); //2nd page portrait
job.setPageable(bk);

Regards
Prasanta
> Thank you,
> Anton
>
> On 3/27/2017 9:52 AM, Prasanta Sadhukhan wrote:
>>
>> Hi Anton,
>>
>> Ok. So, it seems it mac specific. But, are you sure wrong page size 
>> is used in mac as is claimed in the bug?
>> I thought we could use automated regression test instead of manual by 
>> checking pageformat value in print() as compared to what user passes 
>> in setPrintable().
>>
>> Then, I see in print() method in testcase, the "PageFormat" argument 
>> passed has same values as it is passed in setPrintable() in main() 
>> even without your fix.
>>
>> If I reverse trace from print() method present in testcase, I see it 
>> is called from CPrinterJob.java#printAndGetPageFormatArea()
>> which is called from PrinterView.m#rectForPage. And before calling 
>> printAndGetPageFormatArea() it calls 
>> getPageformatPrintablePeekgraphics() which calls 
>> pageable.getPageFormat(pageIndex), so it should behave same as 
>> windows. Am I missing something?
>>
>> Regards
>> Prasanta
>> On 3/27/2017 3:32 AM, Anton Litvinov wrote:
>>> Hello Prasanta,
>>>
>>> I verified that the bug is not reproducible using JDK 9 compiled 
>>> from the latest version of "jdk9/client" forest neither on Windows, 
>>> nor on Linux platform, therefore, yes, this bug is only Mac 
>>> specific. Debugging showed that on Windows platform the behavior is 
>>> exactly like you described, on Windows 
>>> "RasterPrinterJob.print(PrintRequestAttributeSet)" method is 
>>> responsible for printing the documents and in this method 
>>> "RasterPrinterJob.printPage(Pageable, int)" is called for each page 
>>> separately, and in this "printPage" method "PageFormat" instance 
>>> used for printing of the page is extracted from the the transferred 
>>> as the method argument instance of "Pageable" by the expression 
>>> "origPage = document.getPageFormat(pageIndex);".
>>>
>>> The new version of the fix was created. Could you please review the 
>>> second version of the fix.
>>>
>>> Webrev (the 2nd version): 
>>> http://cr.openjdk.java.net/~alitvinov/8167102/jdk9/webrev.01
>>>
>>> In the second version of the fix:
>>> 1. Calling for "RasterPrinterJob.getPageFormatFromAttributes()" was 
>>> substituted for "sun.lwawt.macosx.CPrinterJob.getPageFormat(int)" in 
>>> the native method "CPrinterJob.m#javaPrinterJobToNSPrintInfo".
>>> 2. The method "RasterPrinterJob.getPageFormatFromAttributes()" was 
>>> removed, since it is not called from any other code in "jdk" repository.
>>> 3. The manual regression test was created.
>>>
>>> Also on OS X I executed all manual and automatic "jtreg" regression 
>>> tests related to printing from the listed below directories and the 
>>> corresponding directories in the closed repositories using both JDK 
>>> 9 compiled without and with the fix, and I verified that no new test 
>>> failed on JDK 9 with the fix.
>>>
>>> The directories with the regression tests from open repositories:
>>> - "jdk/test/java/awt/print"
>>> - "jdk/test/javax/print"
>>>
>>> Thank you,
>>> Anton
>>>
>>> On 3/22/2017 7:42 AM, Prasanta Sadhukhan wrote:
>>>>
>>>> Hi Anton,
>>>>
>>>> I thought about your point and have a question: does this issue not 
>>>> reproduce in non-mac platform?
>>>> I thought it probably would so suggested modifying setAttributes() 
>>>> . But, if it is only reproduced in mac, we need to find out why 
>>>> despite this setAttributes() flaw, how this is working in non-mac 
>>>> platform?
>>>>
>>>> It probably might work in windows/linux because in 
>>>> RasterPrinterJob.print(attr) method, after it calls 
>>>> setAttributes(), it calls printPage() where it gets the original 
>>>> PageFormat
>>>> by calling getPageFormat(pageIndex) and gets the orientation, 
>>>> imageablearea
>>>> and not by constructing pageFormat from attributes as it is done in 
>>>> mac.
>>>> So, probably, in mac also, we need to do away with 
>>>> getPageFormatFromAttributes() call  and call 
>>>> getPageFormat(pageIndex) from 
>>>> CPrinterJob.m#javaPrinterJobToNSPrintInfo().
>>>>
>>>> Regards
>>>> Prasanta
>>>> On 3/21/2017 8:15 PM, Anton Litvinov wrote:
>>>>> Hello Prasanta,
>>>>>
>>>>> Thank you for review of this fix. I have tried to apply the 
>>>>> approach which you suggested and it allowed to resolve the issue. 
>>>>> In this case I agree that it would be more correct to resolve the 
>>>>> issue in 
>>>>> "RasterPrinterJob.setAttributes(PrintRequestAttributeSet)" method. 
>>>>> In the first version of the fix I decided to change the method 
>>>>> "RasterPrinterJob.getPageFormatFromAttributes()", because it is 
>>>>> invoked only from 1 place in JDK code and this place is located in 
>>>>> OS X specific code 
>>>>> "jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m", 
>>>>> so that would automatically minimize the affected by the fix 
>>>>> platforms to OS X only.
>>>>>
>>>>> Starting to work on implementation of the second version of the 
>>>>> fix including the regression test.
>>>>>
>>>>> Thank you,
>>>>> Anton
>>>>>
>>>>> On 3/21/2017 12:52 PM, Prasanta Sadhukhan wrote:
>>>>>>
>>>>>> I think the real problem is not in 
>>>>>> RasterPrinterJob.getPageFormatFromAttributes().
>>>>>>
>>>>>> One can see that, when we call RasterPrinterJob.setPrintable(), 
>>>>>> we call updatePageAttributes() which in turn calls 
>>>>>> updateAttributesWithPageFormat() where orientation, media and 
>>>>>> mediaprintablearea "attributes" get populated/cached from the 
>>>>>> "pageformat" supplied by the user.
>>>>>>
>>>>>> But, when PrinterJob.print(PrintRequestAttributeSet) is called, 
>>>>>> it calls setAttributes(attributes) where "attributes" is what is 
>>>>>> populated by the user. It does not contain orientation,media and 
>>>>>> mediaprintablearea attributes for this bug, so setAttributes sets 
>>>>>> cached attribute with this user-set attribute instance
>>>>>> />>else {//
>>>>>> //>>            // for AWT where pageable is not an instance of 
>>>>>> OpenBook,//
>>>>>> //>>            // we need to save paper info//
>>>>>> // >>           this.attributes = attributes;//
>>>>>> // >>       }//
>>>>>> /
>>>>>>
>>>>>> //thereby losing the attributes it has cached earlier from user 
>>>>>> pageformat. I think we should check if this.attributes is not 
>>>>>> null, then retain those attributes unless explicitly set by the 
>>>>>> user in user-defined attributes.
>>>>>>
>>>>>> But, this code is used by windows,linux,mac so it needs to be 
>>>>>> tested against all those platforms to ensure we are not 
>>>>>> regressing anything.
>>>>>>
>>>>>> Also, I think user should call validatePage(PageFormat) in 
>>>>>> application to check if the settings passed is compatible with 
>>>>>> the printer or not, get compatible/adjusted pageformat and call 
>>>>>> setPrintable() with that "adjusted" pageformat. If user pass 
>>>>>> 0,0,fullpaperwidth,fullpaperheight as imageablearea, then he 
>>>>>> should not expect this setting to be used since printer will have 
>>>>>> its own hardware limitation (and use some offset printing)
>>>>>>
>>>>>> BTW, a regression testcase (even if it is manual) should be 
>>>>>> created with the fix.
>>>>>>
>>>>>> Regards
>>>>>> Prasanta
>>>>>> On 3/17/2017 10:59 PM, Anton Litvinov wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> Could you please review the following fix for the bug.
>>>>>>>
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8167102
>>>>>>> Webrev: 
>>>>>>> http://cr.openjdk.java.net/~alitvinov/8167102/jdk9/webrev.00
>>>>>>>
>>>>>>> The bug consists in the fact that, if the user's application 
>>>>>>> specifies the required page size (media size) through 
>>>>>>> "java.awt.print.PrinterJob" API particularly via 
>>>>>>> "java.awt.print.PageFormat" instance supplied to the method 
>>>>>>> "PrinterJob.setPrintable(Printable, PageFormat)" and calls 
>>>>>>> "PrinterJob.print(PrintRequestAttributeSet)" with 
>>>>>>> "javax.print.attribute.PrintRequestAttributeSet" containing at 
>>>>>>> least 1 any "PrintRequestAttribute", then the page or pages will 
>>>>>>> be printed with "PageFormat" describing the default page size of 
>>>>>>> the printer which is different from the expected and originally 
>>>>>>> set by the user's application "PageFormat".
>>>>>>>
>>>>>>> Debugging showed that the new "PageFormat" with unexpected media 
>>>>>>> size is created in the method 
>>>>>>> "sun.print.RasterPrinterJob.getPageFormatFromAttributes()" which 
>>>>>>> is invoked from the native function 
>>>>>>> "jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m::javaPrinterJobToNSPrintInfo". 
>>>>>>> The method "RasterPrinterJob.getPageFormatFromAttributes()" 
>>>>>>> returns a new "PageFormat" always, if the provided by the user 
>>>>>>> "PrintRequestAttributeSet" is not empty, and the default values 
>>>>>>> are set to particular instance variables of this "PageFormat", 
>>>>>>> if "PrintRequestAttributeSet" does not contain the searched 
>>>>>>> "OrientationRequested", "MediaSizeName", "MediaPrintableArea" 
>>>>>>> attributes.
>>>>>>>
>>>>>>> THE SOLUTION:
>>>>>>> Although it is clearly stated in Java Platform SE 8 API 
>>>>>>> Specification (documentation of the method 
>>>>>>> "PrinterJob.print(PrintRequestAttributeSet)")
>>>>>>> Specification URL: 
>>>>>>> http://docs.oracle.com/javase/8/docs/api/java/awt/print/PrinterJob.html#print-javax.print.attribute.PrintRequestAttributeSet-
>>>>>>>
>>>>>>> that media size, orientation and imageable area attributes 
>>>>>>> specified in "PrintRequestAttributeSet" supplied to the method 
>>>>>>> "PrinterJob.print" will be used for construction of a new 
>>>>>>> "PageFormat", which will be passed to "Printable" object, 
>>>>>>> instead of the original "PageFormat" instance set through 
>>>>>>> "PrinterJob.setPrintable" method, the observed in this issue 
>>>>>>> behavior is a bug, because in the bug test case neither media 
>>>>>>> size, nor orientation, nor imageable area attributes are 
>>>>>>> specified in "PrintRequestAttributeSet".
>>>>>>>
>>>>>>> The fix alters the method 
>>>>>>> "sun.print.RasterPrinterJob.getPageFormatFromAttributes()" to 
>>>>>>> use corresponding values from "PageFormat" instance originally 
>>>>>>> set through "PrinterJob" API during construction of the new 
>>>>>>> "PageFormat", when it is found out that "OrientationRequested", 
>>>>>>> or "MediaSizeName", or "MediaPrintableArea" attribute is not 
>>>>>>> specified in "PrintRequestAttributeSet" supplied to 
>>>>>>> "PrinterJob.print" method.
>>>>>>>
>>>>>>> Thank you,
>>>>>>> Anton
>>>>>>
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20170328/7dcd4016/attachment.html>

From anton.litvinov at oracle.com  Tue Mar 28 12:55:57 2017
From: anton.litvinov at oracle.com (Anton Litvinov)
Date: Tue, 28 Mar 2017 15:55:57 +0300
Subject: [OpenJDK 2D-Dev] [9] Review request for 8167102: [macosx]
 PrintRequestAttributeSet breaks page size set using PageFormat
In-Reply-To: <2fad447d-2219-e3a6-68c5-91fc4822eb29@oracle.com>
References: <17a96ade-ea01-95bd-728a-ec3106d1fbfa@oracle.com>
 <ae716330-c0c4-9b2c-4f6b-c30855e659dc@oracle.com>
 <7d710d7a-386f-a6c3-7f6d-13e56a7309a6@oracle.com>
 <b5efdb91-dd13-045f-18bd-f95830ba61fe@oracle.com>
 <89b66f3b-d1f0-5c88-1b7c-6065ad6ce4da@oracle.com>
 <ce891f45-bc5e-ec00-8074-880e26b93f39@oracle.com>
 <43402a5f-4e4b-ce6f-262d-e6b21176fb99@oracle.com>
 <2fad447d-2219-e3a6-68c5-91fc4822eb29@oracle.com>
Message-ID: <b6a5a113-d958-fb6d-4156-d49b9da9b4f1@oracle.com>

Hello Prasanta,

The correct "PageFormat" for each separate page is retrieved in the 
native function "PrinterView.m::rectForPage:(NSInteger)" by invoking the 
Java method "CPrinterJob.getPageformatPrintablePeekgraphics(int)" with 
the first expression specified below and getting the value of 
"PageFormat" from the returned array with the second expression 
specified below.

"jobjectArray objectArray = JNFCallObjectMethod(env, fPrinterJob, 
jm_getPageformatPrintablePeekgraphics, jPageNumber); // AWT_THREADING 
Safe (AWTRunLoopMode)"
"jobject pageFormat = (*env)->GetObjectArrayElement(env, objectArray, 0);"

But in that native method "PrinterView.m::rectForPage" only the page 
orientation field "mOrientation" of the retrieved "PageFormat" for each 
page is analyzed and is set to "NSPrintInfo" object through 
"NSPrintOperation". Thus for some reason at that method analysis of the 
paper size is ignored.

So obviously not taking into account individual paper size of the pages 
for the case, which you described, when the user's code specifies 
different "PageFormat" instances for different pages of the document, 
should take place in JDK, though I did not verify this practically. But 
this issue existed before my fix and is not a result of the fix.

I do not see anything bad in the hard coded "0" page number used in my 
fix, because we need to initialize "NSPrintInfo" with a valid page size 
and the page size of the first page of the document is the only correct 
or appropriate value for this moment, and because this approach already 
exists in "RasterPrinterJob.java" as the next expression.

"PageFormat pf = (PageFormat)pageable.getPageFormat(0).clone();"

 From my point of view, the issue about disrespect of different paper 
sizes for different pages of the document is the issue which is 
different from the issue described in this bug (JDK-8167102) and should 
be fixed separately from my bug, because:
- In my bug "java.awt.print.Printable" interface is involved, while in 
this new issue "java.awt.print.Pageable" interface is the explicit 
requirement;
- In my bug calling "PrinterJob.print(PrintRequestAttributeSet)" with a 
non-empty "PrintRequestAttributeSet" is the obligatory and the key 
requirement, while in the new issue this condition is irrelevant.
- For my bug one regression test is necessary, while for the new issue 
the different regression test is necessary.

Therefore I suggest to file a separate bug for the discovered issue and 
to address it separately from this bug (JDK-8167102). Would you agree 
with this suggestion? Would you approve the second version of the fix 
for the bug JDK-8167102?

Thank you,
Anton

On 3/28/2017 12:46 PM, Prasanta Sadhukhan wrote:
>
> Hi Anton,
>
>
> On 3/27/2017 10:05 PM, Anton Litvinov wrote:
>> Hello Prasanta,
>>
>> Indeed it is Mac specific, as it was written in my previous e-mail, I 
>> verified this fact on Windows OS and Linux OS by your request.
>>
>> Yes, I am fully sure that, when the bug occurs, the paper size of the 
>> printed page is wrong, as it is stated in the bug, and I am fully 
>> sure that with the applied any of 2 versions of the created fix, the 
>> paper size of the printed page becomes correct and as expected. 
>> Otherwise, I would not send the fix for review. The instruction, by 
>> following which the bug can be reproduced, is written in "STEPS TO 
>> FOLLOW TO REPRODUCE THE PROBLEM :" section of the description of the 
>> bug in JBS. This bug is raised by the user, who owns a support 
>> contract and requests for resolution of this bug, this can be seen in 
>> proper comments of the bug record.
>>
>> The automated regression test is not possible for this bug, since it 
>> is necessary to verify visually that the document is physically 
>> printed on the paper of the expected size. Otherwise, I would send 
>> the 1st version of the fix with the automated test already, it is not 
>> the first bug in JDK on which I have been working. By your request 
>> the regression test, even though it is manual, was created and added 
>> to the 2nd version of the fix.
>>
>> Yes, it is correct, the implemented by the test, and the test case 
>> method "Printable.print(Graphics, PageFormat, int)" receives the 
>> correct instance of "PageFormat" in runtime in scenario described in 
>> this bug, because, as you already described, it is extracted using 
>> the expression "pageable.getPageFormat(pageIndex)" in the Java method 
>> "sun.lwawt.macosx.CPrinterJob.getPageformatPrintablePeekgraphics(int)" 
>> called from "PrinterView.m::rectForPage:(NSInteger)" and further 
>> transferred in this method to the Java method 
>> "sun.lwawt.macosx.CPrinterJob.printAndGetPageFormatArea".
>>
>> The wrong paper size which is returned from the method 
>> "RasterPrinterJob.getPageFormatFromAttributes()" and which is set to 
>> certain fields of the Objective-C  object "NSPrintInfo" in the 
>> function "CPrinterJob.m::javaPaperToNSPrintInfo" through the next 
>> call sequence
>>
>> CPrinterJob.m::printLoop() --> 
>> CPrinterJob.m::javaPrinterJobToNSPrintInfo() --> 
>> CPrinterJob.m::javaPageFormatToNSPrintInfo() --> 
>> CPrinterJob.m::javaPaperToNSPrintInfo()
>>
>> further influences physical size of all pages printed by 1 printer job.
>>
>> Thus, I consider that firstly "PageFormat" returned from 
>> "RasterPrinterJob.getPageFormatFromAttributes()" is wrong, and 
>> secondly setting paper size from this wrong "PageFormat" to proper 
>> fields of "NSPrintInfo" object is also incorrect and is a root cause 
>> of this bug.
> OK. So, pageformat values set to native NSPrintInfo is different 
> (wrong) compared to what is being passed to user.
>>
>> Implementation of Java Print Server API surely contains many issues, 
>> and only working on this bug I already encountered 2 additional 
>> different issues, which are described in one of my comments in this 
>> bug record in JBS. However, I prefer to resolve issues separately and 
>> to resolve this particular bug also separately from other issues 
>> which we can indefinitely find while looking at the code and 
>> debugging it, also because it is necessary to deliver the fix for 
>> this bug to "jdk8u-dev" repository finally, while JDK 9 is currently 
>> in RDP 2 phase at which large fixes affecting more platforms or large 
>> code scope would hardly be accepted by Group and Area leads or the 
>> release team.
>>
>> I would like to bring also your attention again to the fact, which 
>> was mentioned in my previous e-mail, that I already ran all manual 
>> and automatic "jtreg" regression tests related to printing from open 
>> and closed parts of JDK on JDK 9 without the fix and with the fix, 
>> what is 198 tests.
>>
>> Do you find anything incorrect in the 2nd version of the fix? Will 
>> you approve the 2nd version of the fix?
>>
> I think there might be a (probable) issue with this fix. PageFormat of 
> 1st page only is used to get the information.
> jobject page = JNFCallObjectMethod(env, srcPrinterJob, 
> jm_getPageFormat, (jint)0);
> What if user has set different pageformat to different page like this 
> below? Will it not lose the 2nd page pageformat? I guess in 
> windows/linux, we obtain pageformat for each pageindex
>
> PrinterJob job = PrinterJob.getPrinterJob();
> // Create a landscape pageformat
> PageFormat pfl = job.defaultPage();
> pfl.setOrientation(PageFormat.LANDSCAPE);
> //Setup a book
> Book bk = new Book();
> bk.append(new xPrintable(), pfl); // 1st page landscape , can be diff. 
> pagesize too
> bk.append(new xxPrintable(), job.defaultPage()); //2nd page portrait
> job.setPageable(bk);
>
> Regards
> Prasanta
>> Thank you,
>> Anton
>>
>> On 3/27/2017 9:52 AM, Prasanta Sadhukhan wrote:
>>>
>>> Hi Anton,
>>>
>>> Ok. So, it seems it mac specific. But, are you sure wrong page size 
>>> is used in mac as is claimed in the bug?
>>> I thought we could use automated regression test instead of manual 
>>> by checking pageformat value in print() as compared to what user 
>>> passes in setPrintable().
>>>
>>> Then, I see in print() method in testcase, the "PageFormat" argument 
>>> passed has same values as it is passed in setPrintable() in main() 
>>> even without your fix.
>>>
>>> If I reverse trace from print() method present in testcase, I see it 
>>> is called from CPrinterJob.java#printAndGetPageFormatArea()
>>> which is called from PrinterView.m#rectForPage. And before calling 
>>> printAndGetPageFormatArea() it calls 
>>> getPageformatPrintablePeekgraphics() which calls 
>>> pageable.getPageFormat(pageIndex), so it should behave same as 
>>> windows. Am I missing something?
>>>
>>> Regards
>>> Prasanta
>>> On 3/27/2017 3:32 AM, Anton Litvinov wrote:
>>>> Hello Prasanta,
>>>>
>>>> I verified that the bug is not reproducible using JDK 9 compiled 
>>>> from the latest version of "jdk9/client" forest neither on Windows, 
>>>> nor on Linux platform, therefore, yes, this bug is only Mac 
>>>> specific. Debugging showed that on Windows platform the behavior is 
>>>> exactly like you described, on Windows 
>>>> "RasterPrinterJob.print(PrintRequestAttributeSet)" method is 
>>>> responsible for printing the documents and in this method 
>>>> "RasterPrinterJob.printPage(Pageable, int)" is called for each page 
>>>> separately, and in this "printPage" method "PageFormat" instance 
>>>> used for printing of the page is extracted from the the transferred 
>>>> as the method argument instance of "Pageable" by the expression 
>>>> "origPage = document.getPageFormat(pageIndex);".
>>>>
>>>> The new version of the fix was created. Could you please review the 
>>>> second version of the fix.
>>>>
>>>> Webrev (the 2nd version): 
>>>> http://cr.openjdk.java.net/~alitvinov/8167102/jdk9/webrev.01
>>>>
>>>> In the second version of the fix:
>>>> 1. Calling for "RasterPrinterJob.getPageFormatFromAttributes()" was 
>>>> substituted for "sun.lwawt.macosx.CPrinterJob.getPageFormat(int)" 
>>>> in the native method "CPrinterJob.m#javaPrinterJobToNSPrintInfo".
>>>> 2. The method "RasterPrinterJob.getPageFormatFromAttributes()" was 
>>>> removed, since it is not called from any other code in "jdk" 
>>>> repository.
>>>> 3. The manual regression test was created.
>>>>
>>>> Also on OS X I executed all manual and automatic "jtreg" regression 
>>>> tests related to printing from the listed below directories and the 
>>>> corresponding directories in the closed repositories using both JDK 
>>>> 9 compiled without and with the fix, and I verified that no new 
>>>> test failed on JDK 9 with the fix.
>>>>
>>>> The directories with the regression tests from open repositories:
>>>> - "jdk/test/java/awt/print"
>>>> - "jdk/test/javax/print"
>>>>
>>>> Thank you,
>>>> Anton
>>>>
>>>> On 3/22/2017 7:42 AM, Prasanta Sadhukhan wrote:
>>>>>
>>>>> Hi Anton,
>>>>>
>>>>> I thought about your point and have a question: does this issue 
>>>>> not reproduce in non-mac platform?
>>>>> I thought it probably would so suggested modifying setAttributes() 
>>>>> . But, if it is only reproduced in mac, we need to find out why 
>>>>> despite this setAttributes() flaw, how this is working in non-mac 
>>>>> platform?
>>>>>
>>>>> It probably might work in windows/linux because in 
>>>>> RasterPrinterJob.print(attr) method, after it calls 
>>>>> setAttributes(), it calls printPage() where it gets the original 
>>>>> PageFormat
>>>>> by calling getPageFormat(pageIndex) and gets the orientation, 
>>>>> imageablearea
>>>>> and not by constructing pageFormat from attributes as it is done 
>>>>> in mac.
>>>>> So, probably, in mac also, we need to do away with 
>>>>> getPageFormatFromAttributes() call  and call 
>>>>> getPageFormat(pageIndex) from 
>>>>> CPrinterJob.m#javaPrinterJobToNSPrintInfo().
>>>>>
>>>>> Regards
>>>>> Prasanta
>>>>> On 3/21/2017 8:15 PM, Anton Litvinov wrote:
>>>>>> Hello Prasanta,
>>>>>>
>>>>>> Thank you for review of this fix. I have tried to apply the 
>>>>>> approach which you suggested and it allowed to resolve the issue. 
>>>>>> In this case I agree that it would be more correct to resolve the 
>>>>>> issue in 
>>>>>> "RasterPrinterJob.setAttributes(PrintRequestAttributeSet)" 
>>>>>> method. In the first version of the fix I decided to change the 
>>>>>> method "RasterPrinterJob.getPageFormatFromAttributes()", because 
>>>>>> it is invoked only from 1 place in JDK code and this place is 
>>>>>> located in OS X specific code 
>>>>>> "jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m", 
>>>>>> so that would automatically minimize the affected by the fix 
>>>>>> platforms to OS X only.
>>>>>>
>>>>>> Starting to work on implementation of the second version of the 
>>>>>> fix including the regression test.
>>>>>>
>>>>>> Thank you,
>>>>>> Anton
>>>>>>
>>>>>> On 3/21/2017 12:52 PM, Prasanta Sadhukhan wrote:
>>>>>>>
>>>>>>> I think the real problem is not in 
>>>>>>> RasterPrinterJob.getPageFormatFromAttributes().
>>>>>>>
>>>>>>> One can see that, when we call RasterPrinterJob.setPrintable(), 
>>>>>>> we call updatePageAttributes() which in turn calls 
>>>>>>> updateAttributesWithPageFormat() where orientation, media and 
>>>>>>> mediaprintablearea "attributes" get populated/cached from the 
>>>>>>> "pageformat" supplied by the user.
>>>>>>>
>>>>>>> But, when PrinterJob.print(PrintRequestAttributeSet) is called, 
>>>>>>> it calls setAttributes(attributes) where "attributes" is what is 
>>>>>>> populated by the user. It does not contain orientation,media and 
>>>>>>> mediaprintablearea attributes for this bug, so setAttributes 
>>>>>>> sets cached attribute with this user-set attribute instance
>>>>>>> />>else {//
>>>>>>> //>>            // for AWT where pageable is not an instance of 
>>>>>>> OpenBook,//
>>>>>>> //>>            // we need to save paper info//
>>>>>>> // >>           this.attributes = attributes;//
>>>>>>> // >>       }//
>>>>>>> /
>>>>>>>
>>>>>>> //thereby losing the attributes it has cached earlier from user 
>>>>>>> pageformat. I think we should check if this.attributes is not 
>>>>>>> null, then retain those attributes unless explicitly set by the 
>>>>>>> user in user-defined attributes.
>>>>>>>
>>>>>>> But, this code is used by windows,linux,mac so it needs to be 
>>>>>>> tested against all those platforms to ensure we are not 
>>>>>>> regressing anything.
>>>>>>>
>>>>>>> Also, I think user should call validatePage(PageFormat) in 
>>>>>>> application to check if the settings passed is compatible with 
>>>>>>> the printer or not, get compatible/adjusted pageformat and call 
>>>>>>> setPrintable() with that "adjusted" pageformat. If user pass 
>>>>>>> 0,0,fullpaperwidth,fullpaperheight as imageablearea, then he 
>>>>>>> should not expect this setting to be used since printer will 
>>>>>>> have its own hardware limitation (and use some offset printing)
>>>>>>>
>>>>>>> BTW, a regression testcase (even if it is manual) should be 
>>>>>>> created with the fix.
>>>>>>>
>>>>>>> Regards
>>>>>>> Prasanta
>>>>>>> On 3/17/2017 10:59 PM, Anton Litvinov wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> Could you please review the following fix for the bug.
>>>>>>>>
>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8167102
>>>>>>>> Webrev: 
>>>>>>>> http://cr.openjdk.java.net/~alitvinov/8167102/jdk9/webrev.00
>>>>>>>>
>>>>>>>> The bug consists in the fact that, if the user's application 
>>>>>>>> specifies the required page size (media size) through 
>>>>>>>> "java.awt.print.PrinterJob" API particularly via 
>>>>>>>> "java.awt.print.PageFormat" instance supplied to the method 
>>>>>>>> "PrinterJob.setPrintable(Printable, PageFormat)" and calls 
>>>>>>>> "PrinterJob.print(PrintRequestAttributeSet)" with 
>>>>>>>> "javax.print.attribute.PrintRequestAttributeSet" containing at 
>>>>>>>> least 1 any "PrintRequestAttribute", then the page or pages 
>>>>>>>> will be printed with "PageFormat" describing the default page 
>>>>>>>> size of the printer which is different from the expected and 
>>>>>>>> originally set by the user's application "PageFormat".
>>>>>>>>
>>>>>>>> Debugging showed that the new "PageFormat" with unexpected 
>>>>>>>> media size is created in the method 
>>>>>>>> "sun.print.RasterPrinterJob.getPageFormatFromAttributes()" 
>>>>>>>> which is invoked from the native function 
>>>>>>>> "jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m::javaPrinterJobToNSPrintInfo". 
>>>>>>>> The method "RasterPrinterJob.getPageFormatFromAttributes()" 
>>>>>>>> returns a new "PageFormat" always, if the provided by the user 
>>>>>>>> "PrintRequestAttributeSet" is not empty, and the default values 
>>>>>>>> are set to particular instance variables of this "PageFormat", 
>>>>>>>> if "PrintRequestAttributeSet" does not contain the searched 
>>>>>>>> "OrientationRequested", "MediaSizeName", "MediaPrintableArea" 
>>>>>>>> attributes.
>>>>>>>>
>>>>>>>> THE SOLUTION:
>>>>>>>> Although it is clearly stated in Java Platform SE 8 API 
>>>>>>>> Specification (documentation of the method 
>>>>>>>> "PrinterJob.print(PrintRequestAttributeSet)")
>>>>>>>> Specification URL: 
>>>>>>>> http://docs.oracle.com/javase/8/docs/api/java/awt/print/PrinterJob.html#print-javax.print.attribute.PrintRequestAttributeSet-
>>>>>>>>
>>>>>>>> that media size, orientation and imageable area attributes 
>>>>>>>> specified in "PrintRequestAttributeSet" supplied to the method 
>>>>>>>> "PrinterJob.print" will be used for construction of a new 
>>>>>>>> "PageFormat", which will be passed to "Printable" object, 
>>>>>>>> instead of the original "PageFormat" instance set through 
>>>>>>>> "PrinterJob.setPrintable" method, the observed in this issue 
>>>>>>>> behavior is a bug, because in the bug test case neither media 
>>>>>>>> size, nor orientation, nor imageable area attributes are 
>>>>>>>> specified in "PrintRequestAttributeSet".
>>>>>>>>
>>>>>>>> The fix alters the method 
>>>>>>>> "sun.print.RasterPrinterJob.getPageFormatFromAttributes()" to 
>>>>>>>> use corresponding values from "PageFormat" instance originally 
>>>>>>>> set through "PrinterJob" API during construction of the new 
>>>>>>>> "PageFormat", when it is found out that "OrientationRequested", 
>>>>>>>> or "MediaSizeName", or "MediaPrintableArea" attribute is not 
>>>>>>>> specified in "PrintRequestAttributeSet" supplied to 
>>>>>>>> "PrinterJob.print" method.
>>>>>>>>
>>>>>>>> Thank you,
>>>>>>>> Anton
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20170328/ed356441/attachment.html>

From prasanta.sadhukhan at oracle.com  Tue Mar 28 14:23:21 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Tue, 28 Mar 2017 19:53:21 +0530
Subject: [OpenJDK 2D-Dev] [9] Review request for 8167102: [macosx]
 PrintRequestAttributeSet breaks page size set using PageFormat
In-Reply-To: <b6a5a113-d958-fb6d-4156-d49b9da9b4f1@oracle.com>
References: <17a96ade-ea01-95bd-728a-ec3106d1fbfa@oracle.com>
 <ae716330-c0c4-9b2c-4f6b-c30855e659dc@oracle.com>
 <7d710d7a-386f-a6c3-7f6d-13e56a7309a6@oracle.com>
 <b5efdb91-dd13-045f-18bd-f95830ba61fe@oracle.com>
 <89b66f3b-d1f0-5c88-1b7c-6065ad6ce4da@oracle.com>
 <ce891f45-bc5e-ec00-8074-880e26b93f39@oracle.com>
 <43402a5f-4e4b-ce6f-262d-e6b21176fb99@oracle.com>
 <2fad447d-2219-e3a6-68c5-91fc4822eb29@oracle.com>
 <b6a5a113-d958-fb6d-4156-d49b9da9b4f1@oracle.com>
Message-ID: <e79eadcb-1467-828b-023e-6c20951ac762@oracle.com>



On 3/28/2017 6:25 PM, Anton Litvinov wrote:
> Hello Prasanta,
>
> The correct "PageFormat" for each separate page is retrieved in the 
> native function "PrinterView.m::rectForPage:(NSInteger)" by invoking 
> the Java method "CPrinterJob.getPageformatPrintablePeekgraphics(int)" 
> with the first expression specified below and getting the value of 
> "PageFormat" from the returned array with the second expression 
> specified below.
>
> "jobjectArray objectArray = JNFCallObjectMethod(env, fPrinterJob, 
> jm_getPageformatPrintablePeekgraphics, jPageNumber); // AWT_THREADING 
> Safe (AWTRunLoopMode)"
> "jobject pageFormat = (*env)->GetObjectArrayElement(env, objectArray, 0);"
>
> But in that native method "PrinterView.m::rectForPage" only the page 
> orientation field "mOrientation" of the retrieved "PageFormat" for 
> each page is analyzed and is set to "NSPrintInfo" object through 
> "NSPrintOperation". Thus for some reason at that method analysis of 
> the paper size is ignored.
>
> So obviously not taking into account individual paper size of the 
> pages for the case, which you described, when the user's code 
> specifies different "PageFormat" instances for different pages of the 
> document, should take place in JDK, though I did not verify this 
> practically. But this issue existed before my fix and is not a result 
> of the fix.
>
> I do not see anything bad in the hard coded "0" page number used in my 
> fix, because we need to initialize "NSPrintInfo" with a valid page 
> size and the page size of the first page of the document is the only 
> correct or appropriate value for this moment, and because this 
> approach already exists in "RasterPrinterJob.java" as the next expression.
>
> "PageFormat pf = (PageFormat)pageable.getPageFormat(0).clone();"
>
> From my point of view, the issue about disrespect of different paper 
> sizes for different pages of the document is the issue which is 
> different from the issue described in this bug (JDK-8167102) and 
> should be fixed separately from my bug, because:
> - In my bug "java.awt.print.Printable" interface is involved, while in 
> this new issue "java.awt.print.Pageable" interface is the explicit 
> requirement;
> - In my bug calling "PrinterJob.print(PrintRequestAttributeSet)" with 
> a non-empty "PrintRequestAttributeSet" is the obligatory and the key 
> requirement, while in the new issue this condition is irrelevant.
> - For my bug one regression test is necessary, while for the new issue 
> the different regression test is necessary.
>
> Therefore I suggest to file a separate bug for the discovered issue 
> and to address it separately from this bug (JDK-8167102). Would you 
> agree with this suggestion? Would you approve the second version of 
> the fix for the bug JDK-8167102?
>
So long the other issue is addressed (even separately), I am ok with 
this fix.

Regards
Prasanta
> Thank you,
> Anton
>
> On 3/28/2017 12:46 PM, Prasanta Sadhukhan wrote:
>>
>> Hi Anton,
>>
>>
>> On 3/27/2017 10:05 PM, Anton Litvinov wrote:
>>> Hello Prasanta,
>>>
>>> Indeed it is Mac specific, as it was written in my previous e-mail, 
>>> I verified this fact on Windows OS and Linux OS by your request.
>>>
>>> Yes, I am fully sure that, when the bug occurs, the paper size of 
>>> the printed page is wrong, as it is stated in the bug, and I am 
>>> fully sure that with the applied any of 2 versions of the created 
>>> fix, the paper size of the printed page becomes correct and as 
>>> expected. Otherwise, I would not send the fix for review. The 
>>> instruction, by following which the bug can be reproduced, is 
>>> written in "STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :" section of 
>>> the description of the bug in JBS. This bug is raised by the user, 
>>> who owns a support contract and requests for resolution of this bug, 
>>> this can be seen in proper comments of the bug record.
>>>
>>> The automated regression test is not possible for this bug, since it 
>>> is necessary to verify visually that the document is physically 
>>> printed on the paper of the expected size. Otherwise, I would send 
>>> the 1st version of the fix with the automated test already, it is 
>>> not the first bug in JDK on which I have been working. By your 
>>> request the regression test, even though it is manual, was created 
>>> and added to the 2nd version of the fix.
>>>
>>> Yes, it is correct, the implemented by the test, and the test case 
>>> method "Printable.print(Graphics, PageFormat, int)" receives the 
>>> correct instance of "PageFormat" in runtime in scenario described in 
>>> this bug, because, as you already described, it is extracted using 
>>> the expression "pageable.getPageFormat(pageIndex)" in the Java 
>>> method 
>>> "sun.lwawt.macosx.CPrinterJob.getPageformatPrintablePeekgraphics(int)" 
>>> called from "PrinterView.m::rectForPage:(NSInteger)" and further 
>>> transferred in this method to the Java method 
>>> "sun.lwawt.macosx.CPrinterJob.printAndGetPageFormatArea".
>>>
>>> The wrong paper size which is returned from the method 
>>> "RasterPrinterJob.getPageFormatFromAttributes()" and which is set to 
>>> certain fields of the Objective-C  object "NSPrintInfo" in the 
>>> function "CPrinterJob.m::javaPaperToNSPrintInfo" through the next 
>>> call sequence
>>>
>>> CPrinterJob.m::printLoop() --> 
>>> CPrinterJob.m::javaPrinterJobToNSPrintInfo() --> 
>>> CPrinterJob.m::javaPageFormatToNSPrintInfo() --> 
>>> CPrinterJob.m::javaPaperToNSPrintInfo()
>>>
>>> further influences physical size of all pages printed by 1 printer job.
>>>
>>> Thus, I consider that firstly "PageFormat" returned from 
>>> "RasterPrinterJob.getPageFormatFromAttributes()" is wrong, and 
>>> secondly setting paper size from this wrong "PageFormat" to proper 
>>> fields of "NSPrintInfo" object is also incorrect and is a root cause 
>>> of this bug.
>> OK. So, pageformat values set to native NSPrintInfo is different 
>> (wrong) compared to what is being passed to user.
>>>
>>> Implementation of Java Print Server API surely contains many issues, 
>>> and only working on this bug I already encountered 2 additional 
>>> different issues, which are described in one of my comments in this 
>>> bug record in JBS. However, I prefer to resolve issues separately 
>>> and to resolve this particular bug also separately from other issues 
>>> which we can indefinitely find while looking at the code and 
>>> debugging it, also because it is necessary to deliver the fix for 
>>> this bug to "jdk8u-dev" repository finally, while JDK 9 is currently 
>>> in RDP 2 phase at which large fixes affecting more platforms or 
>>> large code scope would hardly be accepted by Group and Area leads or 
>>> the release team.
>>>
>>> I would like to bring also your attention again to the fact, which 
>>> was mentioned in my previous e-mail, that I already ran all manual 
>>> and automatic "jtreg" regression tests related to printing from open 
>>> and closed parts of JDK on JDK 9 without the fix and with the fix, 
>>> what is 198 tests.
>>>
>>> Do you find anything incorrect in the 2nd version of the fix? Will 
>>> you approve the 2nd version of the fix?
>>>
>> I think there might be a (probable) issue with this fix. PageFormat 
>> of 1st page only is used to get the information.
>> jobject page = JNFCallObjectMethod(env, srcPrinterJob, 
>> jm_getPageFormat, (jint)0);
>> What if user has set different pageformat to different page like this 
>> below? Will it not lose the 2nd page pageformat? I guess in 
>> windows/linux, we obtain pageformat for each pageindex
>>
>> PrinterJob job = PrinterJob.getPrinterJob();
>> // Create a landscape pageformat
>> PageFormat pfl = job.defaultPage();
>> pfl.setOrientation(PageFormat.LANDSCAPE);
>> //Setup a book
>> Book bk = new Book();
>> bk.append(new xPrintable(), pfl); // 1st page landscape , can be 
>> diff. pagesize too
>> bk.append(new xxPrintable(), job.defaultPage()); //2nd page portrait
>> job.setPageable(bk);
>>
>> Regards
>> Prasanta
>>> Thank you,
>>> Anton
>>>
>>> On 3/27/2017 9:52 AM, Prasanta Sadhukhan wrote:
>>>>
>>>> Hi Anton,
>>>>
>>>> Ok. So, it seems it mac specific. But, are you sure wrong page size 
>>>> is used in mac as is claimed in the bug?
>>>> I thought we could use automated regression test instead of manual 
>>>> by checking pageformat value in print() as compared to what user 
>>>> passes in setPrintable().
>>>>
>>>> Then, I see in print() method in testcase, the "PageFormat" 
>>>> argument passed has same values as it is passed in setPrintable() 
>>>> in main() even without your fix.
>>>>
>>>> If I reverse trace from print() method present in testcase, I see 
>>>> it is called from CPrinterJob.java#printAndGetPageFormatArea()
>>>> which is called from PrinterView.m#rectForPage. And before calling 
>>>> printAndGetPageFormatArea() it calls 
>>>> getPageformatPrintablePeekgraphics() which calls 
>>>> pageable.getPageFormat(pageIndex), so it should behave same as 
>>>> windows. Am I missing something?
>>>>
>>>> Regards
>>>> Prasanta
>>>> On 3/27/2017 3:32 AM, Anton Litvinov wrote:
>>>>> Hello Prasanta,
>>>>>
>>>>> I verified that the bug is not reproducible using JDK 9 compiled 
>>>>> from the latest version of "jdk9/client" forest neither on 
>>>>> Windows, nor on Linux platform, therefore, yes, this bug is only 
>>>>> Mac specific. Debugging showed that on Windows platform the 
>>>>> behavior is exactly like you described, on Windows 
>>>>> "RasterPrinterJob.print(PrintRequestAttributeSet)" method is 
>>>>> responsible for printing the documents and in this method 
>>>>> "RasterPrinterJob.printPage(Pageable, int)" is called for each 
>>>>> page separately, and in this "printPage" method "PageFormat" 
>>>>> instance used for printing of the page is extracted from the the 
>>>>> transferred as the method argument instance of "Pageable" by the 
>>>>> expression "origPage = document.getPageFormat(pageIndex);".
>>>>>
>>>>> The new version of the fix was created. Could you please review 
>>>>> the second version of the fix.
>>>>>
>>>>> Webrev (the 2nd version): 
>>>>> http://cr.openjdk.java.net/~alitvinov/8167102/jdk9/webrev.01
>>>>>
>>>>> In the second version of the fix:
>>>>> 1. Calling for "RasterPrinterJob.getPageFormatFromAttributes()" 
>>>>> was substituted for 
>>>>> "sun.lwawt.macosx.CPrinterJob.getPageFormat(int)" in the native 
>>>>> method "CPrinterJob.m#javaPrinterJobToNSPrintInfo".
>>>>> 2. The method "RasterPrinterJob.getPageFormatFromAttributes()" was 
>>>>> removed, since it is not called from any other code in "jdk" 
>>>>> repository.
>>>>> 3. The manual regression test was created.
>>>>>
>>>>> Also on OS X I executed all manual and automatic "jtreg" 
>>>>> regression tests related to printing from the listed below 
>>>>> directories and the corresponding directories in the closed 
>>>>> repositories using both JDK 9 compiled without and with the fix, 
>>>>> and I verified that no new test failed on JDK 9 with the fix.
>>>>>
>>>>> The directories with the regression tests from open repositories:
>>>>> - "jdk/test/java/awt/print"
>>>>> - "jdk/test/javax/print"
>>>>>
>>>>> Thank you,
>>>>> Anton
>>>>>
>>>>> On 3/22/2017 7:42 AM, Prasanta Sadhukhan wrote:
>>>>>>
>>>>>> Hi Anton,
>>>>>>
>>>>>> I thought about your point and have a question: does this issue 
>>>>>> not reproduce in non-mac platform?
>>>>>> I thought it probably would so suggested modifying 
>>>>>> setAttributes() . But, if it is only reproduced in mac, we need 
>>>>>> to find out why despite this setAttributes() flaw, how this is 
>>>>>> working in non-mac platform?
>>>>>>
>>>>>> It probably might work in windows/linux because in 
>>>>>> RasterPrinterJob.print(attr) method, after it calls 
>>>>>> setAttributes(), it calls printPage() where it gets the original 
>>>>>> PageFormat
>>>>>> by calling getPageFormat(pageIndex) and gets the orientation, 
>>>>>> imageablearea
>>>>>> and not by constructing pageFormat from attributes as it is done 
>>>>>> in mac.
>>>>>> So, probably, in mac also, we need to do away with 
>>>>>> getPageFormatFromAttributes() call  and call 
>>>>>> getPageFormat(pageIndex) from 
>>>>>> CPrinterJob.m#javaPrinterJobToNSPrintInfo().
>>>>>>
>>>>>> Regards
>>>>>> Prasanta
>>>>>> On 3/21/2017 8:15 PM, Anton Litvinov wrote:
>>>>>>> Hello Prasanta,
>>>>>>>
>>>>>>> Thank you for review of this fix. I have tried to apply the 
>>>>>>> approach which you suggested and it allowed to resolve the 
>>>>>>> issue. In this case I agree that it would be more correct to 
>>>>>>> resolve the issue in 
>>>>>>> "RasterPrinterJob.setAttributes(PrintRequestAttributeSet)" 
>>>>>>> method. In the first version of the fix I decided to change the 
>>>>>>> method "RasterPrinterJob.getPageFormatFromAttributes()", because 
>>>>>>> it is invoked only from 1 place in JDK code and this place is 
>>>>>>> located in OS X specific code 
>>>>>>> "jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m", 
>>>>>>> so that would automatically minimize the affected by the fix 
>>>>>>> platforms to OS X only.
>>>>>>>
>>>>>>> Starting to work on implementation of the second version of the 
>>>>>>> fix including the regression test.
>>>>>>>
>>>>>>> Thank you,
>>>>>>> Anton
>>>>>>>
>>>>>>> On 3/21/2017 12:52 PM, Prasanta Sadhukhan wrote:
>>>>>>>>
>>>>>>>> I think the real problem is not in 
>>>>>>>> RasterPrinterJob.getPageFormatFromAttributes().
>>>>>>>>
>>>>>>>> One can see that, when we call RasterPrinterJob.setPrintable(), 
>>>>>>>> we call updatePageAttributes() which in turn calls 
>>>>>>>> updateAttributesWithPageFormat() where orientation, media and 
>>>>>>>> mediaprintablearea "attributes" get populated/cached from the 
>>>>>>>> "pageformat" supplied by the user.
>>>>>>>>
>>>>>>>> But, when PrinterJob.print(PrintRequestAttributeSet) is called, 
>>>>>>>> it calls setAttributes(attributes) where "attributes" is what 
>>>>>>>> is populated by the user. It does not contain orientation,media 
>>>>>>>> and mediaprintablearea attributes for this bug, so 
>>>>>>>> setAttributes sets cached attribute with this user-set 
>>>>>>>> attribute instance
>>>>>>>> />>else {//
>>>>>>>> //>>            // for AWT where pageable is not an instance of 
>>>>>>>> OpenBook,//
>>>>>>>> //>>            // we need to save paper info//
>>>>>>>> // >>           this.attributes = attributes;//
>>>>>>>> // >>       }//
>>>>>>>> /
>>>>>>>>
>>>>>>>> //thereby losing the attributes it has cached earlier from user 
>>>>>>>> pageformat. I think we should check if this.attributes is not 
>>>>>>>> null, then retain those attributes unless explicitly set by the 
>>>>>>>> user in user-defined attributes.
>>>>>>>>
>>>>>>>> But, this code is used by windows,linux,mac so it needs to be 
>>>>>>>> tested against all those platforms to ensure we are not 
>>>>>>>> regressing anything.
>>>>>>>>
>>>>>>>> Also, I think user should call validatePage(PageFormat) in 
>>>>>>>> application to check if the settings passed is compatible with 
>>>>>>>> the printer or not, get compatible/adjusted pageformat and call 
>>>>>>>> setPrintable() with that "adjusted" pageformat. If user pass 
>>>>>>>> 0,0,fullpaperwidth,fullpaperheight as imageablearea, then he 
>>>>>>>> should not expect this setting to be used since printer will 
>>>>>>>> have its own hardware limitation (and use some offset printing)
>>>>>>>>
>>>>>>>> BTW, a regression testcase (even if it is manual) should be 
>>>>>>>> created with the fix.
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Prasanta
>>>>>>>> On 3/17/2017 10:59 PM, Anton Litvinov wrote:
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> Could you please review the following fix for the bug.
>>>>>>>>>
>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8167102
>>>>>>>>> Webrev: 
>>>>>>>>> http://cr.openjdk.java.net/~alitvinov/8167102/jdk9/webrev.00
>>>>>>>>>
>>>>>>>>> The bug consists in the fact that, if the user's application 
>>>>>>>>> specifies the required page size (media size) through 
>>>>>>>>> "java.awt.print.PrinterJob" API particularly via 
>>>>>>>>> "java.awt.print.PageFormat" instance supplied to the method 
>>>>>>>>> "PrinterJob.setPrintable(Printable, PageFormat)" and calls 
>>>>>>>>> "PrinterJob.print(PrintRequestAttributeSet)" with 
>>>>>>>>> "javax.print.attribute.PrintRequestAttributeSet" containing at 
>>>>>>>>> least 1 any "PrintRequestAttribute", then the page or pages 
>>>>>>>>> will be printed with "PageFormat" describing the default page 
>>>>>>>>> size of the printer which is different from the expected and 
>>>>>>>>> originally set by the user's application "PageFormat".
>>>>>>>>>
>>>>>>>>> Debugging showed that the new "PageFormat" with unexpected 
>>>>>>>>> media size is created in the method 
>>>>>>>>> "sun.print.RasterPrinterJob.getPageFormatFromAttributes()" 
>>>>>>>>> which is invoked from the native function 
>>>>>>>>> "jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m::javaPrinterJobToNSPrintInfo". 
>>>>>>>>> The method "RasterPrinterJob.getPageFormatFromAttributes()" 
>>>>>>>>> returns a new "PageFormat" always, if the provided by the user 
>>>>>>>>> "PrintRequestAttributeSet" is not empty, and the default 
>>>>>>>>> values are set to particular instance variables of this 
>>>>>>>>> "PageFormat", if "PrintRequestAttributeSet" does not contain 
>>>>>>>>> the searched "OrientationRequested", "MediaSizeName", 
>>>>>>>>> "MediaPrintableArea" attributes.
>>>>>>>>>
>>>>>>>>> THE SOLUTION:
>>>>>>>>> Although it is clearly stated in Java Platform SE 8 API 
>>>>>>>>> Specification (documentation of the method 
>>>>>>>>> "PrinterJob.print(PrintRequestAttributeSet)")
>>>>>>>>> Specification URL: 
>>>>>>>>> http://docs.oracle.com/javase/8/docs/api/java/awt/print/PrinterJob.html#print-javax.print.attribute.PrintRequestAttributeSet-
>>>>>>>>>
>>>>>>>>> that media size, orientation and imageable area attributes 
>>>>>>>>> specified in "PrintRequestAttributeSet" supplied to the method 
>>>>>>>>> "PrinterJob.print" will be used for construction of a new 
>>>>>>>>> "PageFormat", which will be passed to "Printable" object, 
>>>>>>>>> instead of the original "PageFormat" instance set through 
>>>>>>>>> "PrinterJob.setPrintable" method, the observed in this issue 
>>>>>>>>> behavior is a bug, because in the bug test case neither media 
>>>>>>>>> size, nor orientation, nor imageable area attributes are 
>>>>>>>>> specified in "PrintRequestAttributeSet".
>>>>>>>>>
>>>>>>>>> The fix alters the method 
>>>>>>>>> "sun.print.RasterPrinterJob.getPageFormatFromAttributes()" to 
>>>>>>>>> use corresponding values from "PageFormat" instance originally 
>>>>>>>>> set through "PrinterJob" API during construction of the new 
>>>>>>>>> "PageFormat", when it is found out that 
>>>>>>>>> "OrientationRequested", or "MediaSizeName", or 
>>>>>>>>> "MediaPrintableArea" attribute is not specified in 
>>>>>>>>> "PrintRequestAttributeSet" supplied to "PrinterJob.print" method.
>>>>>>>>>
>>>>>>>>> Thank you,
>>>>>>>>> Anton
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20170328/ac6df9f6/attachment.html>

From alexandr.scherbatiy at oracle.com  Wed Mar 29 10:40:58 2017
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 29 Mar 2017 14:40:58 +0400
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8177461 Wrong references
 are used in the javadoc in the java.desktop module
In-Reply-To: <553C207F-3FC6-4A78-8F82-3F30E5150B19@oracle.com>
References: <553C207F-3FC6-4A78-8F82-3F30E5150B19@oracle.com>
Message-ID: <dc7d5c20-0570-ff6f-859f-52baf47b1922@oracle.com>

The fix looks good to me.

Thanks,
Alexandr.

On 23/03/17 18:24, Sergey Bylokhov wrote:
> Hello,
> Please review the fix for jdk9.
>
> In java.desktop module in a various places we use incorrect links.
> Most of them are in the documentation in non-public classes/methods(But there are two places in public API - specdiff is provided)
>
> Common issues:
>   - The method is referenced without #
>   - The method which have some parameters is referenced as ?#method()? instead of ?#method? or ?#method(ParameterDescription)"
>   - The type which is referenced is not imported
>   - The reference to non-existed method/type.
>   - Copy pasted javadoc was removed.
>   - The type was renamed (like AppReOpenedListener to AppReopenedListener)
>
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8177461
> Webrev can be found at: http://cr.openjdk.java.net/~serb/8177461/webrev.00
> Specdiff: http://cr.openjdk.java.net/~serb/8177461/specdiff/overview-summary.html



From erik.joelsson at oracle.com  Wed Mar 29 13:00:40 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 29 Mar 2017 15:00:40 +0200
Subject: [OpenJDK 2D-Dev] RFR: JDK-8177135: OpenJDK 9 freetype needs
	msvcr100.dll
Message-ID: <27f1aaf9-4758-c279-39e0-459287ba9781@oracle.com>

Hello,

The build of freetype used internally at Oracle when building OpenJDK 
builds (for the reference implementation) is very old. It was also built 
using Visual Studio 2010, which makes it require msvcr100.dll, while the 
rest of OpenJDK is built with Visual Studio 2013 and subsequently 
require msvcr120.dll.

I have built new freetype binaries, using Visual Studio 2013, from the 
latest available freetype source, 2.7.1. We have verified that the 
OpenJDK builds using these binaries are behaving equally to those with 
the old binary, except for not requiring msvcr100.dll. This patch 
changes the jib-profiles configuration for JDK 9 to use the new freetype 
binaries.

Bug: https://bugs.openjdk.java.net/browse/JDK-8177135

Patch:

diff -r c38c6b270ccc common/conf/jib-profiles.js
--- a/common/conf/jib-profiles.js
+++ b/common/conf/jib-profiles.js
@@ -910,7 +910,7 @@
          freetype: {
              organization: common.organization,
              ext: "tar.gz",
-            revision: "2.3.4+1.0",
+            revision: "2.7.1-v120+1.0",
              module: "freetype-" + input.target_platform
          }
      };

/Erik



From magnus.ihse.bursie at oracle.com  Wed Mar 29 13:16:23 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 29 Mar 2017 15:16:23 +0200
Subject: [OpenJDK 2D-Dev] RFR: JDK-8177135: OpenJDK 9 freetype needs
	msvcr100.dll
In-Reply-To: <27f1aaf9-4758-c279-39e0-459287ba9781@oracle.com>
References: <27f1aaf9-4758-c279-39e0-459287ba9781@oracle.com>
Message-ID: <dbbb353c-a3a1-a98d-f969-42f84a93e663@oracle.com>

On 2017-03-29 15:00, Erik Joelsson wrote:
> Hello,
>
> The build of freetype used internally at Oracle when building OpenJDK 
> builds (for the reference implementation) is very old. It was also 
> built using Visual Studio 2010, which makes it require msvcr100.dll, 
> while the rest of OpenJDK is built with Visual Studio 2013 and 
> subsequently require msvcr120.dll.
>
> I have built new freetype binaries, using Visual Studio 2013, from the 
> latest available freetype source, 2.7.1. We have verified that the 
> OpenJDK builds using these binaries are behaving equally to those with 
> the old binary, except for not requiring msvcr100.dll. This patch 
> changes the jib-profiles configuration for JDK 9 to use the new 
> freetype binaries.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8177135
>
> Patch:
>
> diff -r c38c6b270ccc common/conf/jib-profiles.js
> --- a/common/conf/jib-profiles.js
> +++ b/common/conf/jib-profiles.js
> @@ -910,7 +910,7 @@
>          freetype: {
>              organization: common.organization,
>              ext: "tar.gz",
> -            revision: "2.3.4+1.0",
> +            revision: "2.7.1-v120+1.0",
>              module: "freetype-" + input.target_platform
>          }
>      };
>
> /Erik
>
Looks good to me.

/Magnus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20170329/5fdb58a7/attachment.html>

From philip.race at oracle.com  Wed Mar 29 13:33:10 2017
From: philip.race at oracle.com (Philip Race)
Date: Wed, 29 Mar 2017 06:33:10 -0700
Subject: [OpenJDK 2D-Dev] RFR: JDK-8177135: OpenJDK 9 freetype needs
	msvcr100.dll
In-Reply-To: <dbbb353c-a3a1-a98d-f969-42f84a93e663@oracle.com>
References: <27f1aaf9-4758-c279-39e0-459287ba9781@oracle.com>
 <dbbb353c-a3a1-a98d-f969-42f84a93e663@oracle.com>
Message-ID: <58DBB796.8060404@oracle.com>

+1

-phil.

On 3/29/17, 6:16 AM, Magnus Ihse Bursie wrote:
> On 2017-03-29 15:00, Erik Joelsson wrote:
>> Hello,
>>
>> The build of freetype used internally at Oracle when building OpenJDK 
>> builds (for the reference implementation) is very old. It was also 
>> built using Visual Studio 2010, which makes it require msvcr100.dll, 
>> while the rest of OpenJDK is built with Visual Studio 2013 and 
>> subsequently require msvcr120.dll.
>>
>> I have built new freetype binaries, using Visual Studio 2013, from 
>> the latest available freetype source, 2.7.1. We have verified that 
>> the OpenJDK builds using these binaries are behaving equally to those 
>> with the old binary, except for not requiring msvcr100.dll. This 
>> patch changes the jib-profiles configuration for JDK 9 to use the new 
>> freetype binaries.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8177135
>>
>> Patch:
>>
>> diff -r c38c6b270ccc common/conf/jib-profiles.js
>> --- a/common/conf/jib-profiles.js
>> +++ b/common/conf/jib-profiles.js
>> @@ -910,7 +910,7 @@
>>          freetype: {
>>              organization: common.organization,
>>              ext: "tar.gz",
>> -            revision: "2.3.4+1.0",
>> +            revision: "2.7.1-v120+1.0",
>>              module: "freetype-" + input.target_platform
>>          }
>>      };
>>
>> /Erik
>>
> Looks good to me.
>
> /Magnus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20170329/ce8cb2c4/attachment.html>

From philip.race at oracle.com  Wed Mar 29 17:34:22 2017
From: philip.race at oracle.com (Philip Race)
Date: Wed, 29 Mar 2017 10:34:22 -0700
Subject: [OpenJDK 2D-Dev] [9] Review request for 8167102: [macosx]
 PrintRequestAttributeSet breaks page size set using PageFormat
In-Reply-To: <b6a5a113-d958-fb6d-4156-d49b9da9b4f1@oracle.com>
References: <17a96ade-ea01-95bd-728a-ec3106d1fbfa@oracle.com>
 <ae716330-c0c4-9b2c-4f6b-c30855e659dc@oracle.com>
 <7d710d7a-386f-a6c3-7f6d-13e56a7309a6@oracle.com>
 <b5efdb91-dd13-045f-18bd-f95830ba61fe@oracle.com>
 <89b66f3b-d1f0-5c88-1b7c-6065ad6ce4da@oracle.com>
 <ce891f45-bc5e-ec00-8074-880e26b93f39@oracle.com>
 <43402a5f-4e4b-ce6f-262d-e6b21176fb99@oracle.com>
 <2fad447d-2219-e3a6-68c5-91fc4822eb29@oracle.com>
 <b6a5a113-d958-fb6d-4156-d49b9da9b4f1@oracle.com>
Message-ID: <58DBF01E.20907@oracle.com>

If the test is manual anyway, why does it not display a dialog so it is 
easier
to run. On mac you can always then save as PDF so the "virtual printer" 
isn't needed.
Note: this assumes you are using the native dialog not the Swing one.
Does this in some way change the test so that it passed anyway ?


I also think you should try to verify this with
(a) after displaying the cross-platform dialogs.
(b) after displaying the native dialogs.

There are an amazing number of code paths here ..

throw new RuntimeException(
                 "No 'MediaSize' was found for 'MediaSizeName.ISO_A5'.");
Why insist on A5 ? Any number of sizes should work ?
And making the test fail in such a case is plain wrong.

Why    @requires (os.family == "mac")
since the test can run everywhere ? And it should pass everywhere too.
This should be fixed.

The directory name in the test is gratuitous and unneeded and
the test name itself is ridiculously long.
Instead let's call it

Regarding the fix itself I am unclear what the impact is in
the case the app supplies an attribute set that *does* have one or
more attributes that affect PageFormat.  It might well be that
these are applied already but I'd like assurance that has been verified.
Some of the code references below seem to be a bit munged by mail
so I can't work out what is being said.

-phil.



On 3/28/17, 5:55 AM, Anton Litvinov wrote:
> Hello Prasanta,
>
> The correct "PageFormat" for each separate page is retrieved in the 
> native function "PrinterView.m::rectForPage:(NSInteger)" by invoking 
> the Java method "CPrinterJob.getPageformatPrintablePeekgraphics(int)" 
> with the first expression specified below and getting the value of 
> "PageFormat" from the returned array with the second expression 
> specified below.
>
> "jobjectArray objectArray = JNFCallObjectMethod(env, fPrinterJob, 
> jm_getPageformatPrintablePeekgraphics, jPageNumber); // AWT_THREADING 
> Safe (AWTRunLoopMode)"
> "jobject pageFormat = (*env)->GetObjectArrayElement(env, objectArray, 0);"
>
> But in that native method "PrinterView.m::rectForPage" only the page 
> orientation field "mOrientation" of the retrieved "PageFormat" for 
> each page is analyzed and is set to "NSPrintInfo" object through 
> "NSPrintOperation". Thus for some reason at that method analysis of 
> the paper size is ignored.
>
> So obviously not taking into account individual paper size of the 
> pages for the case, which you described, when the user's code 
> specifies different "PageFormat" instances for different pages of the 
> document, should take place in JDK, though I did not verify this 
> practically. But this issue existed before my fix and is not a result 
> of the fix.
>
> I do not see anything bad in the hard coded "0" page number used in my 
> fix, because we need to initialize "NSPrintInfo" with a valid page 
> size and the page size of the first page of the document is the only 
> correct or appropriate value for this moment, and because this 
> approach already exists in "RasterPrinterJob.java" as the next expression.
>
> "PageFormat pf = (PageFormat)pageable.getPageFormat(0).clone();"
>
> From my point of view, the issue about disrespect of different paper 
> sizes for different pages of the document is the issue which is 
> different from the issue described in this bug (JDK-8167102) and 
> should be fixed separately from my bug, because:
> - In my bug "java.awt.print.Printable" interface is involved, while in 
> this new issue "java.awt.print.Pageable" interface is the explicit 
> requirement;
> - In my bug calling "PrinterJob.print(PrintRequestAttributeSet)" with 
> a non-empty "PrintRequestAttributeSet" is the obligatory and the key 
> requirement, while in the new issue this condition is irrelevant.
> - For my bug one regression test is necessary, while for the new issue 
> the different regression test is necessary.
>
> Therefore I suggest to file a separate bug for the discovered issue 
> and to address it separately from this bug (JDK-8167102). Would you 
> agree with this suggestion? Would you approve the second version of 
> the fix for the bug JDK-8167102?
>
> Thank you,
> Anton
>
> On 3/28/2017 12:46 PM, Prasanta Sadhukhan wrote:
>>
>> Hi Anton,
>>
>>
>> On 3/27/2017 10:05 PM, Anton Litvinov wrote:
>>> Hello Prasanta,
>>>
>>> Indeed it is Mac specific, as it was written in my previous e-mail, 
>>> I verified this fact on Windows OS and Linux OS by your request.
>>>
>>> Yes, I am fully sure that, when the bug occurs, the paper size of 
>>> the printed page is wrong, as it is stated in the bug, and I am 
>>> fully sure that with the applied any of 2 versions of the created 
>>> fix, the paper size of the printed page becomes correct and as 
>>> expected. Otherwise, I would not send the fix for review. The 
>>> instruction, by following which the bug can be reproduced, is 
>>> written in "STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :" section of 
>>> the description of the bug in JBS. This bug is raised by the user, 
>>> who owns a support contract and requests for resolution of this bug, 
>>> this can be seen in proper comments of the bug record.
>>>
>>> The automated regression test is not possible for this bug, since it 
>>> is necessary to verify visually that the document is physically 
>>> printed on the paper of the expected size. Otherwise, I would send 
>>> the 1st version of the fix with the automated test already, it is 
>>> not the first bug in JDK on which I have been working. By your 
>>> request the regression test, even though it is manual, was created 
>>> and added to the 2nd version of the fix.
>>>
>>> Yes, it is correct, the implemented by the test, and the test case 
>>> method "Printable.print(Graphics, PageFormat, int)" receives the 
>>> correct instance of "PageFormat" in runtime in scenario described in 
>>> this bug, because, as you already described, it is extracted using 
>>> the expression "pageable.getPageFormat(pageIndex)" in the Java 
>>> method 
>>> "sun.lwawt.macosx.CPrinterJob.getPageformatPrintablePeekgraphics(int)" 
>>> called from "PrinterView.m::rectForPage:(NSInteger)" and further 
>>> transferred in this method to the Java method 
>>> "sun.lwawt.macosx.CPrinterJob.printAndGetPageFormatArea".
>>>
>>> The wrong paper size which is returned from the method 
>>> "RasterPrinterJob.getPageFormatFromAttributes()" and which is set to 
>>> certain fields of the Objective-C  object "NSPrintInfo" in the 
>>> function "CPrinterJob.m::javaPaperToNSPrintInfo" through the next 
>>> call sequence
>>>
>>> CPrinterJob.m::printLoop() --> 
>>> CPrinterJob.m::javaPrinterJobToNSPrintInfo() --> 
>>> CPrinterJob.m::javaPageFormatToNSPrintInfo() --> 
>>> CPrinterJob.m::javaPaperToNSPrintInfo()
>>>
>>> further influences physical size of all pages printed by 1 printer job.
>>>
>>> Thus, I consider that firstly "PageFormat" returned from 
>>> "RasterPrinterJob.getPageFormatFromAttributes()" is wrong, and 
>>> secondly setting paper size from this wrong "PageFormat" to proper 
>>> fields of "NSPrintInfo" object is also incorrect and is a root cause 
>>> of this bug.
>> OK. So, pageformat values set to native NSPrintInfo is different 
>> (wrong) compared to what is being passed to user.
>>>
>>> Implementation of Java Print Server API surely contains many issues, 
>>> and only working on this bug I already encountered 2 additional 
>>> different issues, which are described in one of my comments in this 
>>> bug record in JBS. However, I prefer to resolve issues separately 
>>> and to resolve this particular bug also separately from other issues 
>>> which we can indefinitely find while looking at the code and 
>>> debugging it, also because it is necessary to deliver the fix for 
>>> this bug to "jdk8u-dev" repository finally, while JDK 9 is currently 
>>> in RDP 2 phase at which large fixes affecting more platforms or 
>>> large code scope would hardly be accepted by Group and Area leads or 
>>> the release team.
>>>
>>> I would like to bring also your attention again to the fact, which 
>>> was mentioned in my previous e-mail, that I already ran all manual 
>>> and automatic "jtreg" regression tests related to printing from open 
>>> and closed parts of JDK on JDK 9 without the fix and with the fix, 
>>> what is 198 tests.
>>>
>>> Do you find anything incorrect in the 2nd version of the fix? Will 
>>> you approve the 2nd version of the fix?
>>>
>> I think there might be a (probable) issue with this fix.  PageFormat 
>> of 1st page only is used to get the information.
>> jobject page = JNFCallObjectMethod(env, srcPrinterJob, jm_getPageFormat, (jint)0);
>> What if user has set different pageformat to different page like this 
>> below? Will it not lose the 2nd page pageformat? I guess in 
>> windows/linux, we obtain pageformat for each pageindex
>>
>> PrinterJob job = PrinterJob.getPrinterJob();
>> // Create a landscape pageformat
>> PageFormat pfl = job.defaultPage();
>> pfl.setOrientation(PageFormat.LANDSCAPE);
>> //Setup a book
>> Book bk = new Book();
>> bk.append(new xPrintable(), pfl); // 1st page landscape , can be 
>> diff. pagesize too
>> bk.append(new xxPrintable(), job.defaultPage()); //2nd page portrait
>> job.setPageable(bk);
>>
>> Regards
>> Prasanta
>>> Thank you,
>>> Anton
>>>
>>> On 3/27/2017 9:52 AM, Prasanta Sadhukhan wrote:
>>>>
>>>> Hi Anton,
>>>>
>>>> Ok. So, it seems it mac specific. But, are you sure wrong page size 
>>>> is used in mac as is claimed in the bug?
>>>> I thought we could use automated regression test instead of manual 
>>>> by checking pageformat value in print() as compared to what user 
>>>> passes in setPrintable().
>>>>
>>>> Then, I see in print() method in testcase, the "PageFormat" 
>>>> argument passed has same values as it is passed in setPrintable() 
>>>> in main() even without your fix.
>>>>
>>>> If I reverse trace from print() method present in testcase, I see 
>>>> it is called from CPrinterJob.java#printAndGetPageFormatArea()
>>>> which is called from PrinterView.m#rectForPage. And before calling 
>>>> printAndGetPageFormatArea() it calls 
>>>> getPageformatPrintablePeekgraphics() which calls 
>>>> pageable.getPageFormat(pageIndex), so it should behave same as 
>>>> windows. Am I missing something?
>>>>
>>>> Regards
>>>> Prasanta
>>>> On 3/27/2017 3:32 AM, Anton Litvinov wrote:
>>>>> Hello Prasanta,
>>>>>
>>>>> I verified that the bug is not reproducible using JDK 9 compiled 
>>>>> from the latest version of "jdk9/client" forest neither on 
>>>>> Windows, nor on Linux platform, therefore, yes, this bug is only 
>>>>> Mac specific. Debugging showed that on Windows platform the 
>>>>> behavior is exactly like you described, on Windows 
>>>>> "RasterPrinterJob.print(PrintRequestAttributeSet)" method is 
>>>>> responsible for printing the documents and in this method 
>>>>> "RasterPrinterJob.printPage(Pageable, int)" is called for each 
>>>>> page separately, and in this "printPage" method "PageFormat" 
>>>>> instance used for printing of the page is extracted from the the 
>>>>> transferred as the method argument instance of "Pageable" by the 
>>>>> expression "origPage = document.getPageFormat(pageIndex);".
>>>>>
>>>>> The new version of the fix was created. Could you please review 
>>>>> the second version of the fix.
>>>>>
>>>>> Webrev (the 2nd version): 
>>>>> http://cr.openjdk.java.net/~alitvinov/8167102/jdk9/webrev.01
>>>>>
>>>>> In the second version of the fix:
>>>>> 1. Calling for "RasterPrinterJob.getPageFormatFromAttributes()" 
>>>>> was substituted for 
>>>>> "sun.lwawt.macosx.CPrinterJob.getPageFormat(int)" in the native 
>>>>> method "CPrinterJob.m#javaPrinterJobToNSPrintInfo".
>>>>> 2. The method "RasterPrinterJob.getPageFormatFromAttributes()" was 
>>>>> removed, since it is not called from any other code in "jdk" 
>>>>> repository.
>>>>> 3. The manual regression test was created.
>>>>>
>>>>> Also on OS X I executed all manual and automatic "jtreg" 
>>>>> regression tests related to printing from the listed below 
>>>>> directories and the corresponding directories in the closed 
>>>>> repositories using both JDK 9 compiled without and with the fix, 
>>>>> and I verified that no new test failed on JDK 9 with the fix.
>>>>>
>>>>> The directories with the regression tests from open repositories:
>>>>> - "jdk/test/java/awt/print"
>>>>> - "jdk/test/javax/print"
>>>>>
>>>>> Thank you,
>>>>> Anton
>>>>>
>>>>> On 3/22/2017 7:42 AM, Prasanta Sadhukhan wrote:
>>>>>>
>>>>>> Hi Anton,
>>>>>>
>>>>>> I thought about your point and have a question: does this issue 
>>>>>> not reproduce in non-mac platform?
>>>>>> I thought it probably would so suggested modifying 
>>>>>> setAttributes() . But, if it is only reproduced in mac, we need 
>>>>>> to find out why despite this setAttributes() flaw, how this is 
>>>>>> working in non-mac platform?
>>>>>>
>>>>>> It probably might work in windows/linux because in 
>>>>>> RasterPrinterJob.print(attr) method, after it calls 
>>>>>> setAttributes(), it calls printPage() where it gets the original 
>>>>>> PageFormat
>>>>>> by calling getPageFormat(pageIndex) and gets the orientation, 
>>>>>> imageablearea
>>>>>> and not by constructing pageFormat from attributes as it is done 
>>>>>> in mac.
>>>>>> So, probably, in mac also, we need to do away with 
>>>>>> getPageFormatFromAttributes() call  and call 
>>>>>> getPageFormat(pageIndex) from 
>>>>>> CPrinterJob.m#javaPrinterJobToNSPrintInfo().
>>>>>>
>>>>>> Regards
>>>>>> Prasanta
>>>>>> On 3/21/2017 8:15 PM, Anton Litvinov wrote:
>>>>>>> Hello Prasanta,
>>>>>>>
>>>>>>> Thank you for review of this fix. I have tried to apply the 
>>>>>>> approach which you suggested and it allowed to resolve the 
>>>>>>> issue. In this case I agree that it would be more correct to 
>>>>>>> resolve the issue in 
>>>>>>> "RasterPrinterJob.setAttributes(PrintRequestAttributeSet)" 
>>>>>>> method. In the first version of the fix I decided to change the 
>>>>>>> method "RasterPrinterJob.getPageFormatFromAttributes()", because 
>>>>>>> it is invoked only from 1 place in JDK code and this place is 
>>>>>>> located in OS X specific code 
>>>>>>> "jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m", 
>>>>>>> so that would automatically minimize the affected by the fix 
>>>>>>> platforms to OS X only.
>>>>>>>
>>>>>>> Starting to work on implementation of the second version of the 
>>>>>>> fix including the regression test.
>>>>>>>
>>>>>>> Thank you,
>>>>>>> Anton
>>>>>>>
>>>>>>> On 3/21/2017 12:52 PM, Prasanta Sadhukhan wrote:
>>>>>>>>
>>>>>>>> I think the real problem is not in 
>>>>>>>> RasterPrinterJob.getPageFormatFromAttributes().
>>>>>>>>
>>>>>>>> One can see that, when we call RasterPrinterJob.setPrintable(), 
>>>>>>>> we call updatePageAttributes() which in turn calls 
>>>>>>>> updateAttributesWithPageFormat() where orientation, media and 
>>>>>>>> mediaprintablearea "attributes" get populated/cached from the 
>>>>>>>> "pageformat" supplied by the user.
>>>>>>>>
>>>>>>>> But, when PrinterJob.print(PrintRequestAttributeSet) is called, 
>>>>>>>> it calls setAttributes(attributes) where "attributes" is what 
>>>>>>>> is populated by the user. It does not contain orientation,media 
>>>>>>>> and mediaprintablearea attributes for this bug, so 
>>>>>>>> setAttributes sets cached attribute with this user-set 
>>>>>>>> attribute instance
>>>>>>>> />>else {//
>>>>>>>> //>>            // for AWT where pageable is not an instance of 
>>>>>>>> OpenBook,//
>>>>>>>> //>>            // we need to save paper info//
>>>>>>>> //>>           this.attributes = attributes;//
>>>>>>>> //>>       }//
>>>>>>>> /
>>>>>>>>
>>>>>>>> //thereby losing the attributes it has cached earlier from user 
>>>>>>>> pageformat. I think we should check if this.attributes is not 
>>>>>>>> null, then retain those attributes unless explicitly set by the 
>>>>>>>> user in user-defined attributes.
>>>>>>>>
>>>>>>>> But, this code is used by windows,linux,mac so it needs to be 
>>>>>>>> tested against all those platforms to ensure we are not 
>>>>>>>> regressing anything.
>>>>>>>>
>>>>>>>> Also, I think user should call validatePage(PageFormat) in 
>>>>>>>> application to check if the settings passed is compatible with 
>>>>>>>> the printer or not, get compatible/adjusted pageformat and call 
>>>>>>>> setPrintable() with that "adjusted" pageformat. If user pass 
>>>>>>>> 0,0,fullpaperwidth,fullpaperheight as imageablearea, then he 
>>>>>>>> should not expect this setting to be used since printer will 
>>>>>>>> have its own hardware limitation (and use some offset printing)
>>>>>>>>
>>>>>>>> BTW, a regression testcase (even if it is manual) should be 
>>>>>>>> created with the fix.
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Prasanta
>>>>>>>> On 3/17/2017 10:59 PM, Anton Litvinov wrote:
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> Could you please review the following fix for the bug.
>>>>>>>>>
>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8167102
>>>>>>>>> Webrev: 
>>>>>>>>> http://cr.openjdk.java.net/~alitvinov/8167102/jdk9/webrev.00
>>>>>>>>>
>>>>>>>>> The bug consists in the fact that, if the user's application 
>>>>>>>>> specifies the required page size (media size) through 
>>>>>>>>> "java.awt.print.PrinterJob" API particularly via 
>>>>>>>>> "java.awt.print.PageFormat" instance supplied to the method 
>>>>>>>>> "PrinterJob.setPrintable(Printable, PageFormat)" and calls 
>>>>>>>>> "PrinterJob.print(PrintRequestAttributeSet)" with 
>>>>>>>>> "javax.print.attribute.PrintRequestAttributeSet" containing at 
>>>>>>>>> least 1 any "PrintRequestAttribute", then the page or pages 
>>>>>>>>> will be printed with "PageFormat" describing the default page 
>>>>>>>>> size of the printer which is different from the expected and 
>>>>>>>>> originally set by the user's application "PageFormat".
>>>>>>>>>
>>>>>>>>> Debugging showed that the new "PageFormat" with unexpected 
>>>>>>>>> media size is created in the method 
>>>>>>>>> "sun.print.RasterPrinterJob.getPageFormatFromAttributes()" 
>>>>>>>>> which is invoked from the native function 
>>>>>>>>> "jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m::javaPrinterJobToNSPrintInfo". 
>>>>>>>>> The method "RasterPrinterJob.getPageFormatFromAttributes()" 
>>>>>>>>> returns a new "PageFormat" always, if the provided by the user 
>>>>>>>>> "PrintRequestAttributeSet" is not empty, and the default 
>>>>>>>>> values are set to particular instance variables of this 
>>>>>>>>> "PageFormat", if "PrintRequestAttributeSet" does not contain 
>>>>>>>>> the searched "OrientationRequested", "MediaSizeName", 
>>>>>>>>> "MediaPrintableArea" attributes.
>>>>>>>>>
>>>>>>>>> THE SOLUTION:
>>>>>>>>> Although it is clearly stated in Java Platform SE 8 API 
>>>>>>>>> Specification (documentation of the method 
>>>>>>>>> "PrinterJob.print(PrintRequestAttributeSet)")
>>>>>>>>> Specification URL: 
>>>>>>>>> http://docs.oracle.com/javase/8/docs/api/java/awt/print/PrinterJob.html#print-javax.print.attribute.PrintRequestAttributeSet-
>>>>>>>>>
>>>>>>>>> that media size, orientation and imageable area attributes 
>>>>>>>>> specified in "PrintRequestAttributeSet" supplied to the method 
>>>>>>>>> "PrinterJob.print" will be used for construction of a new 
>>>>>>>>> "PageFormat", which will be passed to "Printable" object, 
>>>>>>>>> instead of the original "PageFormat" instance set through 
>>>>>>>>> "PrinterJob.setPrintable" method, the observed in this issue 
>>>>>>>>> behavior is a bug, because in the bug test case neither media 
>>>>>>>>> size, nor orientation, nor imageable area attributes are 
>>>>>>>>> specified in "PrintRequestAttributeSet".
>>>>>>>>>
>>>>>>>>> The fix alters the method 
>>>>>>>>> "sun.print.RasterPrinterJob.getPageFormatFromAttributes()" to 
>>>>>>>>> use corresponding values from "PageFormat" instance originally 
>>>>>>>>> set through "PrinterJob" API during construction of the new 
>>>>>>>>> "PageFormat", when it is found out that 
>>>>>>>>> "OrientationRequested", or "MediaSizeName", or 
>>>>>>>>> "MediaPrintableArea" attribute is not specified in 
>>>>>>>>> "PrintRequestAttributeSet" supplied to "PrinterJob.print" method.
>>>>>>>>>
>>>>>>>>> Thank you,
>>>>>>>>> Anton
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20170329/b9fd797e/attachment.html>

From anton.litvinov at oracle.com  Wed Mar 29 17:53:20 2017
From: anton.litvinov at oracle.com (Anton Litvinov)
Date: Wed, 29 Mar 2017 20:53:20 +0300
Subject: [OpenJDK 2D-Dev] [9] Review request for 8167102: [macosx]
 PrintRequestAttributeSet breaks page size set using PageFormat
In-Reply-To: <e79eadcb-1467-828b-023e-6c20951ac762@oracle.com>
References: <17a96ade-ea01-95bd-728a-ec3106d1fbfa@oracle.com>
 <ae716330-c0c4-9b2c-4f6b-c30855e659dc@oracle.com>
 <7d710d7a-386f-a6c3-7f6d-13e56a7309a6@oracle.com>
 <b5efdb91-dd13-045f-18bd-f95830ba61fe@oracle.com>
 <89b66f3b-d1f0-5c88-1b7c-6065ad6ce4da@oracle.com>
 <ce891f45-bc5e-ec00-8074-880e26b93f39@oracle.com>
 <43402a5f-4e4b-ce6f-262d-e6b21176fb99@oracle.com>
 <2fad447d-2219-e3a6-68c5-91fc4822eb29@oracle.com>
 <b6a5a113-d958-fb6d-4156-d49b9da9b4f1@oracle.com>
 <e79eadcb-1467-828b-023e-6c20951ac762@oracle.com>
Message-ID: <e0c50d8b-a077-5d77-d4c9-0034ccaf75b7@oracle.com>

Hello Prasanta,

Thank you for approval of the second version of the fix. As it was 
agreed, I have filed a new bug with a corresponding test case for the 
separate issue which we discussed. The filed bug is 
(https://bugs.openjdk.java.net/browse/JDK-8177781).

Thank you,
Anton

On 3/28/2017 5:23 PM, Prasanta Sadhukhan wrote:
>
>
>
> On 3/28/2017 6:25 PM, Anton Litvinov wrote:
>> Hello Prasanta,
>>
>> The correct "PageFormat" for each separate page is retrieved in the 
>> native function "PrinterView.m::rectForPage:(NSInteger)" by invoking 
>> the Java method "CPrinterJob.getPageformatPrintablePeekgraphics(int)" 
>> with the first expression specified below and getting the value of 
>> "PageFormat" from the returned array with the second expression 
>> specified below.
>>
>> "jobjectArray objectArray = JNFCallObjectMethod(env, fPrinterJob, 
>> jm_getPageformatPrintablePeekgraphics, jPageNumber); // AWT_THREADING 
>> Safe (AWTRunLoopMode)"
>> "jobject pageFormat = (*env)->GetObjectArrayElement(env, objectArray, 
>> 0);"
>>
>> But in that native method "PrinterView.m::rectForPage" only the page 
>> orientation field "mOrientation" of the retrieved "PageFormat" for 
>> each page is analyzed and is set to "NSPrintInfo" object through 
>> "NSPrintOperation". Thus for some reason at that method analysis of 
>> the paper size is ignored.
>>
>> So obviously not taking into account individual paper size of the 
>> pages for the case, which you described, when the user's code 
>> specifies different "PageFormat" instances for different pages of the 
>> document, should take place in JDK, though I did not verify this 
>> practically. But this issue existed before my fix and is not a result 
>> of the fix.
>>
>> I do not see anything bad in the hard coded "0" page number used in 
>> my fix, because we need to initialize "NSPrintInfo" with a valid page 
>> size and the page size of the first page of the document is the only 
>> correct or appropriate value for this moment, and because this 
>> approach already exists in "RasterPrinterJob.java" as the next 
>> expression.
>>
>> "PageFormat pf = (PageFormat)pageable.getPageFormat(0).clone();"
>>
>> From my point of view, the issue about disrespect of different paper 
>> sizes for different pages of the document is the issue which is 
>> different from the issue described in this bug (JDK-8167102) and 
>> should be fixed separately from my bug, because:
>> - In my bug "java.awt.print.Printable" interface is involved, while 
>> in this new issue "java.awt.print.Pageable" interface is the explicit 
>> requirement;
>> - In my bug calling "PrinterJob.print(PrintRequestAttributeSet)" with 
>> a non-empty "PrintRequestAttributeSet" is the obligatory and the key 
>> requirement, while in the new issue this condition is irrelevant.
>> - For my bug one regression test is necessary, while for the new 
>> issue the different regression test is necessary.
>>
>> Therefore I suggest to file a separate bug for the discovered issue 
>> and to address it separately from this bug (JDK-8167102). Would you 
>> agree with this suggestion? Would you approve the second version of 
>> the fix for the bug JDK-8167102?
>>
> So long the other issue is addressed (even separately), I am ok with 
> this fix.
>
> Regards
> Prasanta
>> Thank you,
>> Anton
>>
>> On 3/28/2017 12:46 PM, Prasanta Sadhukhan wrote:
>>>
>>> Hi Anton,
>>>
>>>
>>> On 3/27/2017 10:05 PM, Anton Litvinov wrote:
>>>> Hello Prasanta,
>>>>
>>>> Indeed it is Mac specific, as it was written in my previous e-mail, 
>>>> I verified this fact on Windows OS and Linux OS by your request.
>>>>
>>>> Yes, I am fully sure that, when the bug occurs, the paper size of 
>>>> the printed page is wrong, as it is stated in the bug, and I am 
>>>> fully sure that with the applied any of 2 versions of the created 
>>>> fix, the paper size of the printed page becomes correct and as 
>>>> expected. Otherwise, I would not send the fix for review. The 
>>>> instruction, by following which the bug can be reproduced, is 
>>>> written in "STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :" section of 
>>>> the description of the bug in JBS. This bug is raised by the user, 
>>>> who owns a support contract and requests for resolution of this 
>>>> bug, this can be seen in proper comments of the bug record.
>>>>
>>>> The automated regression test is not possible for this bug, since 
>>>> it is necessary to verify visually that the document is physically 
>>>> printed on the paper of the expected size. Otherwise, I would send 
>>>> the 1st version of the fix with the automated test already, it is 
>>>> not the first bug in JDK on which I have been working. By your 
>>>> request the regression test, even though it is manual, was created 
>>>> and added to the 2nd version of the fix.
>>>>
>>>> Yes, it is correct, the implemented by the test, and the test case 
>>>> method "Printable.print(Graphics, PageFormat, int)" receives the 
>>>> correct instance of "PageFormat" in runtime in scenario described 
>>>> in this bug, because, as you already described, it is extracted 
>>>> using the expression "pageable.getPageFormat(pageIndex)" in the 
>>>> Java method 
>>>> "sun.lwawt.macosx.CPrinterJob.getPageformatPrintablePeekgraphics(int)" 
>>>> called from "PrinterView.m::rectForPage:(NSInteger)" and further 
>>>> transferred in this method to the Java method 
>>>> "sun.lwawt.macosx.CPrinterJob.printAndGetPageFormatArea".
>>>>
>>>> The wrong paper size which is returned from the method 
>>>> "RasterPrinterJob.getPageFormatFromAttributes()" and which is set 
>>>> to certain fields of the Objective-C  object "NSPrintInfo" in the 
>>>> function "CPrinterJob.m::javaPaperToNSPrintInfo" through the next 
>>>> call sequence
>>>>
>>>> CPrinterJob.m::printLoop() --> 
>>>> CPrinterJob.m::javaPrinterJobToNSPrintInfo() --> 
>>>> CPrinterJob.m::javaPageFormatToNSPrintInfo() --> 
>>>> CPrinterJob.m::javaPaperToNSPrintInfo()
>>>>
>>>> further influences physical size of all pages printed by 1 printer job.
>>>>
>>>> Thus, I consider that firstly "PageFormat" returned from 
>>>> "RasterPrinterJob.getPageFormatFromAttributes()" is wrong, and 
>>>> secondly setting paper size from this wrong "PageFormat" to proper 
>>>> fields of "NSPrintInfo" object is also incorrect and is a root 
>>>> cause of this bug.
>>> OK. So, pageformat values set to native NSPrintInfo is different 
>>> (wrong) compared to what is being passed to user.
>>>>
>>>> Implementation of Java Print Server API surely contains many 
>>>> issues, and only working on this bug I already encountered 2 
>>>> additional different issues, which are described in one of my 
>>>> comments in this bug record in JBS. However, I prefer to resolve 
>>>> issues separately and to resolve this particular bug also 
>>>> separately from other issues which we can indefinitely find while 
>>>> looking at the code and debugging it, also because it is necessary 
>>>> to deliver the fix for this bug to "jdk8u-dev" repository finally, 
>>>> while JDK 9 is currently in RDP 2 phase at which large fixes 
>>>> affecting more platforms or large code scope would hardly be 
>>>> accepted by Group and Area leads or the release team.
>>>>
>>>> I would like to bring also your attention again to the fact, which 
>>>> was mentioned in my previous e-mail, that I already ran all manual 
>>>> and automatic "jtreg" regression tests related to printing from 
>>>> open and closed parts of JDK on JDK 9 without the fix and with the 
>>>> fix, what is 198 tests.
>>>>
>>>> Do you find anything incorrect in the 2nd version of the fix? Will 
>>>> you approve the 2nd version of the fix?
>>>>
>>> I think there might be a (probable) issue with this fix. PageFormat 
>>> of 1st page only is used to get the information.
>>> jobject page = JNFCallObjectMethod(env, srcPrinterJob, 
>>> jm_getPageFormat, (jint)0);
>>> What if user has set different pageformat to different page like 
>>> this below? Will it not lose the 2nd page pageformat? I guess in 
>>> windows/linux, we obtain pageformat for each pageindex
>>>
>>> PrinterJob job = PrinterJob.getPrinterJob();
>>> // Create a landscape pageformat
>>> PageFormat pfl = job.defaultPage();
>>> pfl.setOrientation(PageFormat.LANDSCAPE);
>>> //Setup a book
>>> Book bk = new Book();
>>> bk.append(new xPrintable(), pfl); // 1st page landscape , can be 
>>> diff. pagesize too
>>> bk.append(new xxPrintable(), job.defaultPage()); //2nd page portrait
>>> job.setPageable(bk);
>>>
>>> Regards
>>> Prasanta
>>>> Thank you,
>>>> Anton
>>>>
>>>> On 3/27/2017 9:52 AM, Prasanta Sadhukhan wrote:
>>>>>
>>>>> Hi Anton,
>>>>>
>>>>> Ok. So, it seems it mac specific. But, are you sure wrong page 
>>>>> size is used in mac as is claimed in the bug?
>>>>> I thought we could use automated regression test instead of manual 
>>>>> by checking pageformat value in print() as compared to what user 
>>>>> passes in setPrintable().
>>>>>
>>>>> Then, I see in print() method in testcase, the "PageFormat" 
>>>>> argument passed has same values as it is passed in setPrintable() 
>>>>> in main() even without your fix.
>>>>>
>>>>> If I reverse trace from print() method present in testcase, I see 
>>>>> it is called from CPrinterJob.java#printAndGetPageFormatArea()
>>>>> which is called from PrinterView.m#rectForPage. And before calling 
>>>>> printAndGetPageFormatArea() it calls 
>>>>> getPageformatPrintablePeekgraphics() which calls 
>>>>> pageable.getPageFormat(pageIndex), so it should behave same as 
>>>>> windows. Am I missing something?
>>>>>
>>>>> Regards
>>>>> Prasanta
>>>>> On 3/27/2017 3:32 AM, Anton Litvinov wrote:
>>>>>> Hello Prasanta,
>>>>>>
>>>>>> I verified that the bug is not reproducible using JDK 9 compiled 
>>>>>> from the latest version of "jdk9/client" forest neither on 
>>>>>> Windows, nor on Linux platform, therefore, yes, this bug is only 
>>>>>> Mac specific. Debugging showed that on Windows platform the 
>>>>>> behavior is exactly like you described, on Windows 
>>>>>> "RasterPrinterJob.print(PrintRequestAttributeSet)" method is 
>>>>>> responsible for printing the documents and in this method 
>>>>>> "RasterPrinterJob.printPage(Pageable, int)" is called for each 
>>>>>> page separately, and in this "printPage" method "PageFormat" 
>>>>>> instance used for printing of the page is extracted from the the 
>>>>>> transferred as the method argument instance of "Pageable" by the 
>>>>>> expression "origPage = document.getPageFormat(pageIndex);".
>>>>>>
>>>>>> The new version of the fix was created. Could you please review 
>>>>>> the second version of the fix.
>>>>>>
>>>>>> Webrev (the 2nd version): 
>>>>>> http://cr.openjdk.java.net/~alitvinov/8167102/jdk9/webrev.01
>>>>>>
>>>>>> In the second version of the fix:
>>>>>> 1. Calling for "RasterPrinterJob.getPageFormatFromAttributes()" 
>>>>>> was substituted for 
>>>>>> "sun.lwawt.macosx.CPrinterJob.getPageFormat(int)" in the native 
>>>>>> method "CPrinterJob.m#javaPrinterJobToNSPrintInfo".
>>>>>> 2. The method "RasterPrinterJob.getPageFormatFromAttributes()" 
>>>>>> was removed, since it is not called from any other code in "jdk" 
>>>>>> repository.
>>>>>> 3. The manual regression test was created.
>>>>>>
>>>>>> Also on OS X I executed all manual and automatic "jtreg" 
>>>>>> regression tests related to printing from the listed below 
>>>>>> directories and the corresponding directories in the closed 
>>>>>> repositories using both JDK 9 compiled without and with the fix, 
>>>>>> and I verified that no new test failed on JDK 9 with the fix.
>>>>>>
>>>>>> The directories with the regression tests from open repositories:
>>>>>> - "jdk/test/java/awt/print"
>>>>>> - "jdk/test/javax/print"
>>>>>>
>>>>>> Thank you,
>>>>>> Anton
>>>>>>
>>>>>> On 3/22/2017 7:42 AM, Prasanta Sadhukhan wrote:
>>>>>>>
>>>>>>> Hi Anton,
>>>>>>>
>>>>>>> I thought about your point and have a question: does this issue 
>>>>>>> not reproduce in non-mac platform?
>>>>>>> I thought it probably would so suggested modifying 
>>>>>>> setAttributes() . But, if it is only reproduced in mac, we need 
>>>>>>> to find out why despite this setAttributes() flaw, how this is 
>>>>>>> working in non-mac platform?
>>>>>>>
>>>>>>> It probably might work in windows/linux because in 
>>>>>>> RasterPrinterJob.print(attr) method, after it calls 
>>>>>>> setAttributes(), it calls printPage() where it gets the original 
>>>>>>> PageFormat
>>>>>>> by calling getPageFormat(pageIndex) and gets the orientation, 
>>>>>>> imageablearea
>>>>>>> and not by constructing pageFormat from attributes as it is done 
>>>>>>> in mac.
>>>>>>> So, probably, in mac also, we need to do away with 
>>>>>>> getPageFormatFromAttributes() call  and call 
>>>>>>> getPageFormat(pageIndex) from 
>>>>>>> CPrinterJob.m#javaPrinterJobToNSPrintInfo().
>>>>>>>
>>>>>>> Regards
>>>>>>> Prasanta
>>>>>>> On 3/21/2017 8:15 PM, Anton Litvinov wrote:
>>>>>>>> Hello Prasanta,
>>>>>>>>
>>>>>>>> Thank you for review of this fix. I have tried to apply the 
>>>>>>>> approach which you suggested and it allowed to resolve the 
>>>>>>>> issue. In this case I agree that it would be more correct to 
>>>>>>>> resolve the issue in 
>>>>>>>> "RasterPrinterJob.setAttributes(PrintRequestAttributeSet)" 
>>>>>>>> method. In the first version of the fix I decided to change the 
>>>>>>>> method "RasterPrinterJob.getPageFormatFromAttributes()", 
>>>>>>>> because it is invoked only from 1 place in JDK code and this 
>>>>>>>> place is located in OS X specific code 
>>>>>>>> "jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m", 
>>>>>>>> so that would automatically minimize the affected by the fix 
>>>>>>>> platforms to OS X only.
>>>>>>>>
>>>>>>>> Starting to work on implementation of the second version of the 
>>>>>>>> fix including the regression test.
>>>>>>>>
>>>>>>>> Thank you,
>>>>>>>> Anton
>>>>>>>>
>>>>>>>> On 3/21/2017 12:52 PM, Prasanta Sadhukhan wrote:
>>>>>>>>>
>>>>>>>>> I think the real problem is not in 
>>>>>>>>> RasterPrinterJob.getPageFormatFromAttributes().
>>>>>>>>>
>>>>>>>>> One can see that, when we call 
>>>>>>>>> RasterPrinterJob.setPrintable(), we call 
>>>>>>>>> updatePageAttributes() which in turn calls 
>>>>>>>>> updateAttributesWithPageFormat() where orientation, media and 
>>>>>>>>> mediaprintablearea "attributes" get populated/cached from the 
>>>>>>>>> "pageformat" supplied by the user.
>>>>>>>>>
>>>>>>>>> But, when PrinterJob.print(PrintRequestAttributeSet) is 
>>>>>>>>> called, it calls setAttributes(attributes) where "attributes" 
>>>>>>>>> is what is populated by the user. It does not contain 
>>>>>>>>> orientation,media and mediaprintablearea attributes for this 
>>>>>>>>> bug, so setAttributes sets cached attribute with this user-set 
>>>>>>>>> attribute instance
>>>>>>>>> />>else {//
>>>>>>>>> //>>            // for AWT where pageable is not an instance 
>>>>>>>>> of OpenBook,//
>>>>>>>>> //>>            // we need to save paper info//
>>>>>>>>> // >>           this.attributes = attributes;//
>>>>>>>>> // >>       }//
>>>>>>>>> /
>>>>>>>>>
>>>>>>>>> //thereby losing the attributes it has cached earlier from 
>>>>>>>>> user pageformat. I think we should check if this.attributes is 
>>>>>>>>> not null, then retain those attributes unless explicitly set 
>>>>>>>>> by the user in user-defined attributes.
>>>>>>>>>
>>>>>>>>> But, this code is used by windows,linux,mac so it needs to be 
>>>>>>>>> tested against all those platforms to ensure we are not 
>>>>>>>>> regressing anything.
>>>>>>>>>
>>>>>>>>> Also, I think user should call validatePage(PageFormat) in 
>>>>>>>>> application to check if the settings passed is compatible with 
>>>>>>>>> the printer or not, get compatible/adjusted pageformat and 
>>>>>>>>> call setPrintable() with that "adjusted" pageformat. If user 
>>>>>>>>> pass 0,0,fullpaperwidth,fullpaperheight as imageablearea, then 
>>>>>>>>> he should not expect this setting to be used since printer 
>>>>>>>>> will have its own hardware limitation (and use some offset 
>>>>>>>>> printing)
>>>>>>>>>
>>>>>>>>> BTW, a regression testcase (even if it is manual) should be 
>>>>>>>>> created with the fix.
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> Prasanta
>>>>>>>>> On 3/17/2017 10:59 PM, Anton Litvinov wrote:
>>>>>>>>>> Hello,
>>>>>>>>>>
>>>>>>>>>> Could you please review the following fix for the bug.
>>>>>>>>>>
>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8167102
>>>>>>>>>> Webrev: 
>>>>>>>>>> http://cr.openjdk.java.net/~alitvinov/8167102/jdk9/webrev.00
>>>>>>>>>>
>>>>>>>>>> The bug consists in the fact that, if the user's application 
>>>>>>>>>> specifies the required page size (media size) through 
>>>>>>>>>> "java.awt.print.PrinterJob" API particularly via 
>>>>>>>>>> "java.awt.print.PageFormat" instance supplied to the method 
>>>>>>>>>> "PrinterJob.setPrintable(Printable, PageFormat)" and calls 
>>>>>>>>>> "PrinterJob.print(PrintRequestAttributeSet)" with 
>>>>>>>>>> "javax.print.attribute.PrintRequestAttributeSet" containing 
>>>>>>>>>> at least 1 any "PrintRequestAttribute", then the page or 
>>>>>>>>>> pages will be printed with "PageFormat" describing the 
>>>>>>>>>> default page size of the printer which is different from the 
>>>>>>>>>> expected and originally set by the user's application 
>>>>>>>>>> "PageFormat".
>>>>>>>>>>
>>>>>>>>>> Debugging showed that the new "PageFormat" with unexpected 
>>>>>>>>>> media size is created in the method 
>>>>>>>>>> "sun.print.RasterPrinterJob.getPageFormatFromAttributes()" 
>>>>>>>>>> which is invoked from the native function 
>>>>>>>>>> "jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m::javaPrinterJobToNSPrintInfo". 
>>>>>>>>>> The method "RasterPrinterJob.getPageFormatFromAttributes()" 
>>>>>>>>>> returns a new "PageFormat" always, if the provided by the 
>>>>>>>>>> user "PrintRequestAttributeSet" is not empty, and the default 
>>>>>>>>>> values are set to particular instance variables of this 
>>>>>>>>>> "PageFormat", if "PrintRequestAttributeSet" does not contain 
>>>>>>>>>> the searched "OrientationRequested", "MediaSizeName", 
>>>>>>>>>> "MediaPrintableArea" attributes.
>>>>>>>>>>
>>>>>>>>>> THE SOLUTION:
>>>>>>>>>> Although it is clearly stated in Java Platform SE 8 API 
>>>>>>>>>> Specification (documentation of the method 
>>>>>>>>>> "PrinterJob.print(PrintRequestAttributeSet)")
>>>>>>>>>> Specification URL: 
>>>>>>>>>> http://docs.oracle.com/javase/8/docs/api/java/awt/print/PrinterJob.html#print-javax.print.attribute.PrintRequestAttributeSet-
>>>>>>>>>>
>>>>>>>>>> that media size, orientation and imageable area attributes 
>>>>>>>>>> specified in "PrintRequestAttributeSet" supplied to the 
>>>>>>>>>> method "PrinterJob.print" will be used for construction of a 
>>>>>>>>>> new "PageFormat", which will be passed to "Printable" object, 
>>>>>>>>>> instead of the original "PageFormat" instance set through 
>>>>>>>>>> "PrinterJob.setPrintable" method, the observed in this issue 
>>>>>>>>>> behavior is a bug, because in the bug test case neither media 
>>>>>>>>>> size, nor orientation, nor imageable area attributes are 
>>>>>>>>>> specified in "PrintRequestAttributeSet".
>>>>>>>>>>
>>>>>>>>>> The fix alters the method 
>>>>>>>>>> "sun.print.RasterPrinterJob.getPageFormatFromAttributes()" to 
>>>>>>>>>> use corresponding values from "PageFormat" instance 
>>>>>>>>>> originally set through "PrinterJob" API during construction 
>>>>>>>>>> of the new "PageFormat", when it is found out that 
>>>>>>>>>> "OrientationRequested", or "MediaSizeName", or 
>>>>>>>>>> "MediaPrintableArea" attribute is not specified in 
>>>>>>>>>> "PrintRequestAttributeSet" supplied to "PrinterJob.print" 
>>>>>>>>>> method.
>>>>>>>>>>
>>>>>>>>>> Thank you,
>>>>>>>>>> Anton
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20170329/169df177/attachment.html>

From sergey.bylokhov at oracle.com  Wed Mar 29 20:22:11 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 29 Mar 2017 23:22:11 +0300
Subject: [OpenJDK 2D-Dev] Review request for 8029339 Custom
 MultiResolution image support on HiDPI displays
In-Reply-To: <55A44B62.7070703@oracle.com>
References: <54C10E06.6090407@oracle.com> <54DE956C.9040105@oracle.com>
 <5502E763.7080008@oracle.com> <55147EBE.3010002@oracle.com>
 <551BF6AC.8000705@oracle.com> <5523AB20.30704@oracle.com>
 <552E7006.70101@oracle.com> <55A44B62.7070703@oracle.com>
Message-ID: <F19C7C5F-04CA-4721-9BD5-E98DD775F615@oracle.com>

Hi, Jim, Phil.
I have started to use MRI and a new Robot in some of the tests and wonder why the MultiResolutionImage does not use generics for getResolutionVariants()?

So for example if we have an API like:
http://download.java.net/java/jdk9/docs/api/java/awt/Robot.html#createMultiResolutionScreenCapture-java.awt.Rectangle- <http://download.java.net/java/jdk9/docs/api/java/awt/Robot.html#createMultiResolutionScreenCapture-java.awt.Rectangle->
We cannot specify that the MRI contains BufferedImage(not just an image). So the users will need to check it via instance of and cast. 
So in the worse case the user will get something like this:

=====
Test.java
            MultiResolutionImage image =
                    robot.createMultiResolutionScreenCapture(rect);
            List<Image> resolutionVariants = image.getResolutionVariants();

            if (resolutionVariants.size() > 1) {
                Image tmp = resolutionVariants.get(1);
                if (tmp instanceof BufferedImage) {
                    capture = (BufferedImage) tmp;
                }
            } else {
                Image tmp = resolutionVariants.get(0);
                if (tmp instanceof BufferedImage) {
                    capture = (BufferedImage) tmp;
                }
            }
=====

I am not sure but for writing the tests, I feel something like this will be simpler:
=====
Robot.java
    public synchronized MultiResolutionImage<BufferedImage>
            createMultiResolutionScreenCapture(Rectangle screenRect) {
// 
Test.java
            MultiResolutionImage image =
                    robot.createMultiResolutionScreenCapture(rect);
            List<BufferedImage> resolutionVariants = image.getResolutionVariants();

            if (resolutionVariants.size() > 1) {
                    capture = resolutionVariants.get(1);
            } else {
                    capture = resolutionVariants.get(0);
            }
=====
Or even this:
capture = robot.createCompatibleScreenCapture(rect);



> 
> Hi Alexandr,
> 
> Sorry that this fell into the cracks.  Here are some fairly minor updates:
> 
> AbstractMRI - getGraphics() should include "getGraphics() not supported on Multi-Resolution Images" as the exception description text.
> 
> AbstractMRI - getBaseImage() should have doc comments:
> /**
> * Return the base image representing the best version of the image
> * for rendering at the default width and height.
> * @return the base image of the set of multi-resolution images
> */
> (Does it need an @since given that the entire interface is @since 1.9?)
> 
> BaseMRI - the doc comments (both the class comment and the constructor comments) don't start with "/**" so they aren't really doc comments, but they look good so make them so.
> 
> BaseMRI - class comment - "The implementation will return the first ... satisfy the rendering request."  Add another sentence right there "The last image in the array will be returned if no suitable image is found that is larger than the rendering request."
> 
> BaseMRI - move "For best effect ..." should be moved to a new paragraph and mention that no exception will be thrown if the images are not sorted as suggested.
> 
> RenderingHints - comments:
> DEFAULT, SIZE_FIT, DPI_FIT - "an image resolution variant is chosen ..." (add "an")
> DEFAULT - "... which may depend on the policies of the platform"
> SIZE_FIT, DPI_FIT "... on the DPI of ..." (add "the")
> 
> SunHints - descriptor texts:
> SIZE_FIT, DPI_FIT "based on the DPI" (add "the")
> 
> MRCachedImage - remind me what this is used for?
> MRCachedImage.getResolutionVariant - use ceil or round instead of (int) cast?  ceil() would match the actions of MRToolkitImage better.  Also note following comment about precision with SG2D.
> 
> SG2D/MRI - the interface declares the values as float, the usage in SG2D computes values in double and then truncates them to int to pass to the interface - should we upgrade the interface to double for completeness?  If not, then the usage in SG2D should at least pass in float precision.
> 
> SG2D.getResolutionVariant - using destRegionWH to calculate destImageWH can involve a lot of "do some math and then later have additional code undo it".  Would it be faster to just compute destImageWH directly, as in:
> 
> float destImageWidth, destImageHeight;
> 
> if (BASE) {
>    destImageWH = srcWH;
> } else if (DPI) {
>    destImageWH = (float) abs(srcWH * devScale);
> } else {
>    double destRegionWidth, destRegionHeight;
>    if (type) {
>    ...
>    }
>    destImageWH = (float) abs(srcWH * destRegionWH / swh);
> }
> Image rv = img.getRV(destImageWH);
> 
> On the other hand, the last "else" is probably the most common case so this doesn't save anything in the common case, but it avoids a bunch of math that could introduce rounding error for the BASE/DPI cases (even though it is done in doubles).
> 
> Is there intent to have the default case be mapped to DPI_FIT for Windows?
> 
> MultiResolutionRenderinHints.java - should have "Test" appended to the name
> 
> MRRHTest - why not render to a BufferedImage and avoid Robot?  Could it tap into internal APIs to create a BImg/compatibleImage with a given devScale?
> 
> MRRHTest - why allow up to delta=50 on the comparison?
> 
> MRRHTest - since the scale factor comes from a dialog, we depend on running this on a HiDPI display to fully test the hints?  Could using "scaled compatible images" allow testing this more definitively?
> 
> MRRHTest - remove println before pushing?
> 
> MRRHTest - probably shouldn't have a "right answer" for DEFAULT - it should probably just pass if the operation doesn't throw an exception?
> 
> 			...jim
> 
> 
> On 4/15/15 7:04 AM, Alexander Scherbatiy wrote:
>> 
>>   Hello,
>> 
>>  Could you review the updated fix:
>>    http://cr.openjdk.java.net/~alexsch/8029339/webrev.08/
>> 
>>  - SunGraphics2D is updated to calculate the resolution variant size
>> according to the _BASE, _DPI_FIT, and _SIZE_FIT resolution rendering hint
>>  - MultiResolutionRenderingHints test is added
>> 
>>  Thanks,
>>  Alexandr.
>> 
>> 
>> On 4/7/2015 1:02 PM, Jim Graham wrote:
>>> This is an interesting suggestion that would let us keep the
>>> implementation of the various hints centralized and simplify the
>>> interface to the part of the mechanism that is most tied in to the
>>> implementation specifics of the database of media variants - which is
>>> housed in the MRI-implementing object.
>>> 
>>> I'm not sure we ever identified any need to customize the logic of
>>> "what size is needed for this render operation" beyond what we
>>> expressed in the hints, and given that the platform defaults may not
>>> be easy to express to an arbitrary implementation, it is probably
>>> better to put that part of the logic in SG2D, controlled by the easy
>>> to express hints and keep the current API both simple to implement and
>>> flexible to use.  Even if there was a need to customize that part of
>>> the operation (the "what size is relevant to this rendering operation"
>>> decision) beyond what the hints suggest, it would be inappropriate to
>>> tie that in to the "find me media" aspect of the MRI interface
>>> anyway.  So, best to keep them separate and have the hints affect what
>>> SG2D does and have the MRI focused on just storing (possibly creating)
>>> and managing/finding the variants.
>>> 
>>>            ...jim
>>> 
>>> On 4/1/15 6:46 AM, Alexander Scherbatiy wrote:
>>>> On 3/27/2015 12:48 AM, Jim Graham wrote:
>>>>> Hi Alexander,
>>>> 
>>>>   http://cr.openjdk.java.net/~alexsch/8029339/webrev.07/
>>>>   I have updated the fix according to the comments except
>>>> RenderingHints.
>>>> 
>>>>   RenderingHints are supposed to be set on Graphics2D and they have
>>>> keys/values which are not relevant to the getResolutionVariant() method.
>>>>   Graphics objects chooses an alternative according to the set
>>>> rendering hints.
>>>>   May be what SG2D should do just calculate dest image size for the
>>>> given resolution variant hint (_BASE - base image size, _SIZE_FIT -
>>>> including scale factor and graphics transform (Mac algorithm),
>>>> _DPI_FIT - scaled according to the system DPI) and then pass them to
>>>> the getResolutionVariant() method?
>>>> 
>>>>  Thanks,
>>>>  Alexandr.
>>>> 
>>>>> 
>>>>> MRI.java:
>>>>> 
>>>>> Who is the intended audience for the recommendation in the interface
>>>>> to cache image variants?  Are we asking the developers who call the
>>>>> methods on the interface to cache the answers? That would be unwise
>>>>> because the list of variants may change over time for some MRIs. Are
>>>>> we speaking to the implementer? If so, then I think that it is
>>>>> unnecessary to remind implementers of basic implementation
>>>>> strategies like "cache complicated objects".
>>>>> 
>>>>> How about this wording for the getRV() method? - "Gets a specific
>>>>> image that is the best variant to represent this logical image at
>>>>> the indicated size and screen resolution."
>>>>> 
>>>>> Perhaps we should clarify in the doc comments for the dimension
>>>>> arguments in getRV() that the dimensions are measured in pixels?
>>>>> 
>>>>> line 56 - delete blank line between doc comment and method declaration
>>>>> 
>>>>> Also, it is probably overkill to document that the interface
>>>>> getVariants() method returns an unmodifiable list. Responsible
>>>>> implementations would probably use an unmodifiable list, but I don't
>>>>> think it should be required by the interface.  We do need to specify
>>>>> that it isn't required to be modifiable so that a caller doesn't
>>>>> expect to be able to modify it, but that is a looser spec.  How
>>>>> about "Gets a readable list of all resolution variants.  Note that
>>>>> many implementations might return an unmodifiable list."?
>>>>> 
>>>>> AbstractMIR.java:
>>>>> 
>>>>> "provides a default implementation for the MRI" or "provides default
>>>>> implementations of several methods in the <MRI> interface and the
>>>>> <Image> class"?  Actually, I'll note that it provides none of the
>>>>> implementations of the MRI methods so maybe it should be "provides
>>>>> default implementations of several <Image> methods for classes that
>>>>> want to implement the <MRI> interface"?
>>>>> 
>>>>> In the doc example - wrap the list to make it unmodifiable
>>>>> 
>>>>> The doc example could be made 2 or 3 lines shorter by simply
>>>>> assuming the base image is in index 0 (it's just an example so I'm
>>>>> not sure the flexibility needs to be a part of the example).
>>>>> 
>>>>> getGraphics is allowed by the Image interface to return null.
>>>>> Actually, the exact wording is that it can only be called for
>>>>> "offscreen images" and a MRI is technically not "an offscreen
>>>>> image".  Perhaps we should return null here since modifying the base
>>>>> image is unlikely to modify the variants and arguably it would be
>>>>> required by the wording in the method docs (even if the base image
>>>>> was an offscreen, the MRI produced from it stops being an offscreen)?
>>>>> 
>>>>> Are all of the empty "@Inherit" comments needed?  I thought
>>>>> inheritance was the default?
>>>>> 
>>>>> BaseMRI.java:
>>>>> 
>>>>> "This class is [an] array-based implementation of the {AMRI} class"
>>>>> (missing "an" and "the")
>>>>> 
>>>>> We should probably include the comment about the sorting of the
>>>>> images in the class comments as well as document that the algorithm
>>>>> is a simple scan from the beginning for the first image large enough
>>>>> (and default == last image).  The algorithm also might not work very
>>>>> well if the images are not monotonically both wider and taller.  How
>>>>> about adding this to the class comments:
>>>>> 
>>>>> "The implementation will return the first image variant in the array
>>>>> that is large enough to satisfy the rendering request. For best
>>>>> effect the array of images should be sorted with each image being
>>>>> both wider and taller than the previous image. The base image need
>>>>> not be the first image in the array."
>>>>> 
>>>>> getVariants() - you need to return an unmodifiable list. asList()
>>>>> returns a list that "writes back" to the array.  You need to use
>>>>> Collections.unmodifiableList(Arrays.asList(array)).
>>>>> 
>>>>> RenderingHints.java:
>>>>> 
>>>>> Where do we process this hint?  Don't we need to pass it to the
>>>>> getVariant() method?
>>>>> 
>>>>> I don't understand the hint values other than the one that always
>>>>> uses the base image.  Default I guess gives us the ability to use
>>>>> the Mac algorithm of "next larger size" on Mac and "based on Screen
>>>>> DPI" on Windows, but the 3rd value "ON" is so vague as to not have
>>>>> any meaning.  Perhaps we should just delete it, but then do we just
>>>>> always do the Mac method? Or do we vaguely have our internal images
>>>>> have a platform-specific method and the Abstract/Base classes just
>>>>> do what they want with no control from the user?  In FX we are also
>>>>> still struggling with this issue and we may likely just do what the
>>>>> Mac does in all cases, but perhaps AWT needs to "behave like the
>>>>> platform" more?  If we are going to have actual values, then we need
>>>>> to have them do something, which means:
>>>>> 
>>>>> - SG2D needs to track the hint just like we do the other hints that
>>>>> affect our processing
>>>>> - MRI.getVariant() needs to have the hint as an argument
>>>>> - BaseMRI should probably do something with that hint
>>>>> - hint values should include:
>>>>>    - ..._DEFAULT - implementation gets to decide
>>>>>    - ..._BASE - always use the base image
>>>>>    - ..._SIZE_FIT - Mac algorithm of smallest image that is big enough
>>>>>    - ..._DPI_FIT - choose based on DPI of the screen, ignoring
>>>>> transform
>>>>> 
>>>>> line 978 - missing blank line between fields
>>>>> 
>>>>> SG2D.java:
>>>>> 
>>>>> - The interface says that you will be passing in the "logical DPI"
>>>>> of the display, but here you are actually passing in the screen's
>>>>> scale factor.
>>>>> 
>>>>> BaseMRITest.java:
>>>>> 
>>>>> - testBaseMRI also passes in a scale rather than a DPI to the MRI
>>>>> method.
>>>>> 
>>>>> - How does the modification test pass when the implementation
>>>>> doesn't use unmodifiable lists?
>>>>> 
>>>>> MRITest.java:
>>>>> 
>>>>> - also uses scale rather than DPI in several places
>>>>> 
>>>>>        ...jim
>>>>> 
>>>>> On 3/13/15 6:34 AM, Alexander Scherbatiy wrote:
>>>>>> 
>>>>>>   Hello,
>>>>>> 
>>>>>>   Could you review the proposed API based on MultiresolutionImage
>>>>>> interface:
>>>>>>     http://cr.openjdk.java.net/~alexsch/8029339/webrev.06/
>>>>>> 
>>>>>>  - return unmodifiable list comment is added to the
>>>>>> getResolutionVariants() method javadoc in MultiresolutionImage
>>>>>> interface
>>>>>>  - base image size arguments are removed form the
>>>>>> getResolutionVariant(...) method in MultiresolutionImage interface
>>>>>>  - BaseMultiResolutionImage class that allows to create a
>>>>>> multi-resolution image based on resolution variant array is added
>>>>>>  - the test for the BaseMultiResolutionImage is added
>>>>>> 
>>>>>>  Thanks,
>>>>>>  Alexandr.
>>>>>> 
>>>>>> On 2/14/2015 3:23 AM, Jim Graham wrote:
>>>>>>> The second solution looks good.  I'd make it standard practice
>>>>>>> (perhaps even mentioned in the documentation) to return unmodifiable
>>>>>>> lists from the getVariants() method.  The Collections class provides
>>>>>>> easy methods to create these lists, and it sends a clear message to
>>>>>>> the caller that the list was provided for them to read, but not write
>>>>>>> to.  Otherwise they may add a new image to the list you provided them
>>>>>>> and wonder why it wasn't showing up.  Also, an unmodifiable list can
>>>>>>> be cached and reused for subsequent calls without having to create a
>>>>>>> new list every time.
>>>>>>> 
>>>>>>> In getResolutionVariant() was there a reason why the base dimensions
>>>>>>> were provided as float?  The destination dimensions make sense as
>>>>>>> float since they could be the result of a scale, but the source
>>>>>>> dimensions are typically getWidth/getHeight() on the base image.  A
>>>>>>> related question would be if they are needed at all, since the
>>>>>>> implementation should probably already be aware of what the base
>>>>>>> image
>>>>>>> is and what its dimensions are.  I'm guessing they are provided
>>>>>>> because the implementation in SG2D already knows them and it makes it
>>>>>>> easier to forward the implementation on to a shared (static?) method?
>>>>>>> 
>>>>>>> With respect to default implementations, I take it that the
>>>>>>> BaseMRI is
>>>>>>> along the pattern that we see in Swing for Base classes. Would it be
>>>>>>> helpful to provide an implementation (in addition or instead) that
>>>>>>> allows a developer to take a bunch of images and quickly make an MRI
>>>>>>> without having to override anything?  The implementations of
>>>>>>> getBaseImage() and getResolutionVariants() are pretty straightforward
>>>>>>> and a fairly reasonable default algorithm can be provided for
>>>>>>> getRV(dimensions).  This question is more of an idle question for my
>>>>>>> own curiosity than a stumbling block...
>>>>>>> 
>>>>>>>            ...jim
>>>>>>> 
>>>>>>> On 1/22/2015 6:49 AM, Alexander Scherbatiy wrote:
>>>>>>>> 
>>>>>>>>   Hi Phil,
>>>>>>>> 
>>>>>>>>   I have prepared two versions of the proposed API:
>>>>>>>> 
>>>>>>>>   I) Resolution variants are added directly to the Image:
>>>>>>>> http://cr.openjdk.java.net/~alexsch/8029339/list/webrev.00
>>>>>>>> 
>>>>>>>>   II)  MultiResolutionImage interface is used:
>>>>>>>> http://cr.openjdk.java.net/~alexsch/8029339/webrev.05
>>>>>>>> 
>>>>>>>>   It could help to decide which way should be chosen for the the
>>>>>>>> multi-resolution image support.
>>>>>>>> 
>>>>>>>>   Below are some comments:
>>>>>>>> 
>>>>>>>>   1. High level goal:
>>>>>>>>      Introduce an API that allows to create and handle an image
>>>>>>>> with
>>>>>>>> resolution variants.
>>>>>>>> 
>>>>>>>>   2. What is not subject of the provided API
>>>>>>>>     - Scale naming convention for high-resolution images
>>>>>>>>     - Providing pixel scale factor for the screen/window
>>>>>>>> 
>>>>>>>>   3. Use cases
>>>>>>>>    3.1 Loading and drawing high-resolution icons in IntelliJ IDEA
>>>>>>>>      A high-resolution image is loaded from resources and stored in
>>>>>>>> JBHiDPIScaledImage class  which is a subclass of the buffered image.
>>>>>>>>      The high-resolution image is used to create a disabled icon
>>>>>>>> in the
>>>>>>>> IconLoader.getDisabledIcon(icon) method.
>>>>>>>> https://github.com/JetBrains/intellij-community/blob/master/platform/util/src/com/intellij/openapi/util/IconLoader.java
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>>    3.2 Loading and drawing high-resolution icons in NetBeans
>>>>>>>>      NetBeans does not have support for the high-resolution icons
>>>>>>>> loading.
>>>>>>>>      It loads an icon from the file system using
>>>>>>>> Toolkit.getDefaultToolkit().getImage(url) method or from resources
>>>>>>>>      by  ImageReader  and store it in ToolTipImage class which is
>>>>>>>> subclass of the buffered image.
>>>>>>>>      ImageUtilities.createDisabledIcon(icon) method creates a
>>>>>>>> disabled
>>>>>>>> icon by applying  RGBImageFilter to the icon.
>>>>>>>> http://hg.netbeans.org/main/file/97dcf49eb4a7/openide.util/src/org/openide/util/ImageUtilities.java
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>>    3.3 Loading system icons in JDK 1.8
>>>>>>>>      JDK requests icons from the native system for system L&Fs and
>>>>>>>> applies filters for them.
>>>>>>>>      See for example AquaUtils.generateLightenedImage() method:
>>>>>>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/e6f48c4fad38/src/java.desktop/macosx/classes/com/apple/laf/AquaUtils.java
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>>   4. HiDPI support for Images on different OSes
>>>>>>>> 
>>>>>>>>     4.1 Mac OS X
>>>>>>>>       Cocoa API contains NSImage that allows to work with image
>>>>>>>> representations: add/remove/get all representations.
>>>>>>>>       It picks up an image with necessary resolution based on the
>>>>>>>> screen backing store pixel scale factor and applied transforms.
>>>>>>>> https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSImage_Class/Reference/Reference.html
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>>     4.2 Linux
>>>>>>>>       GTK+ 3 API has gtkcssimagescaled lib (it seems that it is not
>>>>>>>> public/stable)
>>>>>>>>       that parses the -gtk-scaled css property and draws a
>>>>>>>> GtkCssImage
>>>>>>>> according to the given scale factor.
>>>>>>>> 
>>>>>>>>       I have not found information about the HiDPI support in Xlib.
>>>>>>>> 
>>>>>>>>     4.3 Windows
>>>>>>>>       I have only found the tutorial that suggests to select and
>>>>>>>> draw a
>>>>>>>> bitmap using the queried DPI
>>>>>>>>       and scale the coordinates for drawing a rectangular frame
>>>>>>>> http://msdn.microsoft.com/en-us/library/dd464659%28v=vs.85%29.aspx
>>>>>>>> 
>>>>>>>>       Windows also provides the horizontal and vertical DPI of the
>>>>>>>> desktop
>>>>>>>> http://msdn.microsoft.com/en-us/library/windows/apps/dd371316
>>>>>>>> 
>>>>>>>>   5. Pseudo API
>>>>>>>>      Below are some ways which illustrates how multi-resolution
>>>>>>>> images
>>>>>>>> can be created and used.
>>>>>>>> 
>>>>>>>>     5.1 Resolution variants are stored directly in Image class.
>>>>>>>>     To query a resolution variant it needs to compare the
>>>>>>>> resolution
>>>>>>>> variant width/height
>>>>>>>>     with the requested high-resolution size.
>>>>>>>>     ------------
>>>>>>>>     public abstract class Image {
>>>>>>>> 
>>>>>>>>         public void addResolutionVariant(Image image) {...}
>>>>>>>>         public List<Image> getResolutionVariants() {...}
>>>>>>>>     }
>>>>>>>>     ------------
>>>>>>>>     // create a disabled image with resolution variants
>>>>>>>> 
>>>>>>>>     Image disabledImage = getDisabledImage(image);
>>>>>>>> 
>>>>>>>>     for (Image rv : image.getResolutionVariants()) {
>>>>>>>> disabledImage.addResolutionVariant(getDisabledImage(rv));
>>>>>>>>     }
>>>>>>>>     ------------
>>>>>>>>     This approach requires that all resolution variants have been
>>>>>>>> created even not of them are really used.
>>>>>>>> 
>>>>>>>>     5.2  Resolution variants are stored in a separate object that
>>>>>>>> allows to create them by demand.
>>>>>>>>     To query a resolution variant it needs to compare the
>>>>>>>> resolution
>>>>>>>> variant scale factor
>>>>>>>>     with the requested scale (that can include both screen DPI
>>>>>>>> scale
>>>>>>>> and applied transforms).
>>>>>>>>     ------------
>>>>>>>>     public abstract class Image {
>>>>>>>> 
>>>>>>>>         public static interface ResolutionVariant {
>>>>>>>>             Image getImage();
>>>>>>>>             float getScaleFactor();
>>>>>>>>         }
>>>>>>>> 
>>>>>>>>         public void addResolutionVariant(ResolutionVariant
>>>>>>>> resolutionVariant) {...}
>>>>>>>>         public List<ResolutionVariant> getResolutionVariants()
>>>>>>>> {...}
>>>>>>>>     }
>>>>>>>>     ------------
>>>>>>>>     // create a disabled image with resolution variants
>>>>>>>>     Image disabledImage = getDisabledImage(image);
>>>>>>>> 
>>>>>>>>     for (Image.ResolutionVariant rv :
>>>>>>>> image.getResolutionVariants()) {
>>>>>>>>         disabledImage.addResolutionVariant(new
>>>>>>>> Image.ResolutionVariant() {
>>>>>>>> 
>>>>>>>>             public Image getImage() {
>>>>>>>>                 return getDisabledImage(rv.getImage());
>>>>>>>>             }
>>>>>>>> 
>>>>>>>>             public float getScaleFactor() {
>>>>>>>>                 return rv.getScaleFactor();
>>>>>>>>             }
>>>>>>>>         });
>>>>>>>>     }
>>>>>>>>     ------------
>>>>>>>> 
>>>>>>>>     It does not have problem if a predefined set of images is
>>>>>>>> provided
>>>>>>>> (like image.png and image at 2x.png on the file system).
>>>>>>>>     This does not cover cases where a resolution variant can be
>>>>>>>> created
>>>>>>>> using the exact requested size (like loading icons from the native
>>>>>>>> system).
>>>>>>>>     A resolution variant can be queried based on a scale factor and
>>>>>>>> applied transforms.
>>>>>>>> 
>>>>>>>>     5.3 The provided example allows to create a resolution variant
>>>>>>>> using the requested high-resolution image size.
>>>>>>>>     ------------
>>>>>>>>     public interface MultiResolutionImage {
>>>>>>>>         Image getResolutionVariant(float width, float height);
>>>>>>>>     }
>>>>>>>>     ------------
>>>>>>>>     // create a multi-resolution image
>>>>>>>>     Image mrImage = new AbstractMultiResolutionImage() {
>>>>>>>> 
>>>>>>>>             public Image getResolutionVariant(float width, float
>>>>>>>> height) {
>>>>>>>>                 // create and return a resolution variant with
>>>>>>>> exact
>>>>>>>> requested width/height size
>>>>>>>>             }
>>>>>>>> 
>>>>>>>>             protected Image getBaseImage() {
>>>>>>>>                 return baseImage;
>>>>>>>>             }
>>>>>>>>         };
>>>>>>>>     ------------
>>>>>>>>     // create a disabled image with resolution variants
>>>>>>>>     Image disabledImage = null;
>>>>>>>>     if (image instanceof MultiResolutionImage) {
>>>>>>>>         final MultiResolutionImage mrImage = (MultiResolutionImage)
>>>>>>>> image;
>>>>>>>>         disabledImage = new AbstractMultiResolutionImage(){
>>>>>>>> 
>>>>>>>>             public Image getResolutionVariant(float width, float
>>>>>>>> height) {
>>>>>>>>                 return
>>>>>>>> getDisabledImage(mrImage.getResolutionVariant(width, height));
>>>>>>>>             }
>>>>>>>> 
>>>>>>>>             protected Image getBaseImage() {
>>>>>>>>                 return getDisabledImage(mrImage);
>>>>>>>>             }
>>>>>>>>         };
>>>>>>>>     } else {
>>>>>>>>         disabledImage = getDisabledImage(image);
>>>>>>>>     }
>>>>>>>>     ------------
>>>>>>>> 
>>>>>>>>   Thanks,
>>>>>>>>   Alexandr.
>>>>>> 
>>>> 
>>> 
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20170329/92c63218/attachment.html>

From philip.race at oracle.com  Wed Mar 29 20:52:37 2017
From: philip.race at oracle.com (Philip Race)
Date: Wed, 29 Mar 2017 13:52:37 -0700
Subject: [OpenJDK 2D-Dev] Review request for 8029339 Custom
 MultiResolution image support on HiDPI displays
In-Reply-To: <F19C7C5F-04CA-4721-9BD5-E98DD775F615@oracle.com>
References: <54C10E06.6090407@oracle.com> <54DE956C.9040105@oracle.com>
 <5502E763.7080008@oracle.com> <55147EBE.3010002@oracle.com>
 <551BF6AC.8000705@oracle.com> <5523AB20.30704@oracle.com>
 <552E7006.70101@oracle.com> <55A44B62.7070703@oracle.com>
 <F19C7C5F-04CA-4721-9BD5-E98DD775F615@oracle.com>
Message-ID: <58DC1E95.5060506@oracle.com>

This would be a reasonable thing to try to fix before 9 GA I think.
Can't affect many tests since the code is new ..

-phil.


On 3/29/17, 1:22 PM, Sergey Bylokhov wrote:
> Hi, Jim, Phil.
> I have started to use MRI and a new Robot in some of the tests and 
> wonder why the MultiResolutionImage does not use generics 
> for getResolutionVariants()?
>
> So for example if we have an API like:
> http://download.java.net/java/jdk9/docs/api/java/awt/Robot.html#createMultiResolutionScreenCapture-java.awt.Rectangle-
> We cannot specify that the MRI contains BufferedImage(not just an 
> image). So the users will need to check it via instance of and cast.
> So in the worse case the user will get something like this:
>
> =====
> Test.java
>             MultiResolutionImage image =
>                     robot.createMultiResolutionScreenCapture(rect);
>             List<Image> resolutionVariants = 
> image.getResolutionVariants();
>
>             if (resolutionVariants.size() > 1) {
>                 Image tmp = resolutionVariants.get(1);
>                 if (tmp instanceof BufferedImage) {
>                     capture = (BufferedImage) tmp;
>                 }
>             } else {
>                 Image tmp = resolutionVariants.get(0);
>                 if (tmp instanceof BufferedImage) {
>                     capture = (BufferedImage) tmp;
>                 }
>             }
> =====
>
> I am not sure but for writing the tests, I feel something like this 
> will be simpler:
> =====
> Robot.java
>     public synchronized MultiResolutionImage<BufferedImage>
>             createMultiResolutionScreenCapture(Rectangle screenRect) {
> //
> Test.java
>             MultiResolutionImage image =
>                     robot.createMultiResolutionScreenCapture(rect);
>             List<BufferedImage> resolutionVariants = 
> image.getResolutionVariants();
>
>             if (resolutionVariants.size() > 1) {
>                     capture = resolutionVariants.get(1);
>             } else {
>                     capture = resolutionVariants.get(0);
>             }
> =====
> Or even this:
> capture = robot.createCompatibleScreenCapture(rect);
>
>
>
>>
>> Hi Alexandr,
>>
>> Sorry that this fell into the cracks.  Here are some fairly minor 
>> updates:
>>
>> AbstractMRI - getGraphics() should include "getGraphics() not 
>> supported on Multi-Resolution Images" as the exception description text.
>>
>> AbstractMRI - getBaseImage() should have doc comments:
>> /**
>> * Return the base image representing the best version of the image
>> * for rendering at the default width and height.
>> * @return the base image of the set of multi-resolution images
>> */
>> (Does it need an @since given that the entire interface is @since 1.9?)
>>
>> BaseMRI - the doc comments (both the class comment and the 
>> constructor comments) don't start with "/**" so they aren't really 
>> doc comments, but they look good so make them so.
>>
>> BaseMRI - class comment - "The implementation will return the first 
>> ... satisfy the rendering request."  Add another sentence right there 
>> "The last image in the array will be returned if no suitable image is 
>> found that is larger than the rendering request."
>>
>> BaseMRI - move "For best effect ..." should be moved to a new 
>> paragraph and mention that no exception will be thrown if the images 
>> are not sorted as suggested.
>>
>> RenderingHints - comments:
>> DEFAULT, SIZE_FIT, DPI_FIT - "an image resolution variant is chosen 
>> ..." (add "an")
>> DEFAULT - "... which may depend on the policies of the platform"
>> SIZE_FIT, DPI_FIT "... on the DPI of ..." (add "the")
>>
>> SunHints - descriptor texts:
>> SIZE_FIT, DPI_FIT "based on the DPI" (add "the")
>>
>> MRCachedImage - remind me what this is used for?
>> MRCachedImage.getResolutionVariant - use ceil or round instead of 
>> (int) cast?  ceil() would match the actions of MRToolkitImage better. 
>>  Also note following comment about precision with SG2D.
>>
>> SG2D/MRI - the interface declares the values as float, the usage in 
>> SG2D computes values in double and then truncates them to int to pass 
>> to the interface - should we upgrade the interface to double for 
>> completeness?  If not, then the usage in SG2D should at least pass in 
>> float precision.
>>
>> SG2D.getResolutionVariant - using destRegionWH to calculate 
>> destImageWH can involve a lot of "do some math and then later have 
>> additional code undo it".  Would it be faster to just compute 
>> destImageWH directly, as in:
>>
>> float destImageWidth, destImageHeight;
>>
>> if (BASE) {
>>    destImageWH = srcWH;
>> } else if (DPI) {
>>    destImageWH = (float) abs(srcWH * devScale);
>> } else {
>>    double destRegionWidth, destRegionHeight;
>>    if (type) {
>>    ...
>>    }
>>    destImageWH = (float) abs(srcWH * destRegionWH / swh);
>> }
>> Image rv = img.getRV(destImageWH);
>>
>> On the other hand, the last "else" is probably the most common case 
>> so this doesn't save anything in the common case, but it avoids a 
>> bunch of math that could introduce rounding error for the BASE/DPI 
>> cases (even though it is done in doubles).
>>
>> Is there intent to have the default case be mapped to DPI_FIT for 
>> Windows?
>>
>> MultiResolutionRenderinHints.java - should have "Test" appended to 
>> the name
>>
>> MRRHTest - why not render to a BufferedImage and avoid Robot?  Could 
>> it tap into internal APIs to create a BImg/compatibleImage with a 
>> given devScale?
>>
>> MRRHTest - why allow up to delta=50 on the comparison?
>>
>> MRRHTest - since the scale factor comes from a dialog, we depend on 
>> running this on a HiDPI display to fully test the hints?  Could using 
>> "scaled compatible images" allow testing this more definitively?
>>
>> MRRHTest - remove println before pushing?
>>
>> MRRHTest - probably shouldn't have a "right answer" for DEFAULT - it 
>> should probably just pass if the operation doesn't throw an exception?
>>
>> ...jim
>>
>>
>> On 4/15/15 7:04 AM, Alexander Scherbatiy wrote:
>>>
>>>   Hello,
>>>
>>>  Could you review the updated fix:
>>> http://cr.openjdk.java.net/~alexsch/8029339/webrev.08/ 
>>> <http://cr.openjdk.java.net/%7Ealexsch/8029339/webrev.08/>
>>>
>>>  - SunGraphics2D is updated to calculate the resolution variant size
>>> according to the _BASE, _DPI_FIT, and _SIZE_FIT resolution rendering 
>>> hint
>>>  - MultiResolutionRenderingHints test is added
>>>
>>>  Thanks,
>>>  Alexandr.
>>>
>>>
>>> On 4/7/2015 1:02 PM, Jim Graham wrote:
>>>> This is an interesting suggestion that would let us keep the
>>>> implementation of the various hints centralized and simplify the
>>>> interface to the part of the mechanism that is most tied in to the
>>>> implementation specifics of the database of media variants - which is
>>>> housed in the MRI-implementing object.
>>>>
>>>> I'm not sure we ever identified any need to customize the logic of
>>>> "what size is needed for this render operation" beyond what we
>>>> expressed in the hints, and given that the platform defaults may not
>>>> be easy to express to an arbitrary implementation, it is probably
>>>> better to put that part of the logic in SG2D, controlled by the easy
>>>> to express hints and keep the current API both simple to implement and
>>>> flexible to use.  Even if there was a need to customize that part of
>>>> the operation (the "what size is relevant to this rendering operation"
>>>> decision) beyond what the hints suggest, it would be inappropriate to
>>>> tie that in to the "find me media" aspect of the MRI interface
>>>> anyway.  So, best to keep them separate and have the hints affect what
>>>> SG2D does and have the MRI focused on just storing (possibly creating)
>>>> and managing/finding the variants.
>>>>
>>>>            ...jim
>>>>
>>>> On 4/1/15 6:46 AM, Alexander Scherbatiy wrote:
>>>>> On 3/27/2015 12:48 AM, Jim Graham wrote:
>>>>>> Hi Alexander,
>>>>>
>>>>> http://cr.openjdk.java.net/~alexsch/8029339/webrev.07/ 
>>>>> <http://cr.openjdk.java.net/%7Ealexsch/8029339/webrev.07/>
>>>>>   I have updated the fix according to the comments except
>>>>> RenderingHints.
>>>>>
>>>>>   RenderingHints are supposed to be set on Graphics2D and they have
>>>>> keys/values which are not relevant to the getResolutionVariant() 
>>>>> method.
>>>>>   Graphics objects chooses an alternative according to the set
>>>>> rendering hints.
>>>>>   May be what SG2D should do just calculate dest image size for the
>>>>> given resolution variant hint (_BASE - base image size, _SIZE_FIT -
>>>>> including scale factor and graphics transform (Mac algorithm),
>>>>> _DPI_FIT - scaled according to the system DPI) and then pass them to
>>>>> the getResolutionVariant() method?
>>>>>
>>>>>  Thanks,
>>>>>  Alexandr.
>>>>>
>>>>>>
>>>>>> MRI.java:
>>>>>>
>>>>>> Who is the intended audience for the recommendation in the interface
>>>>>> to cache image variants?  Are we asking the developers who call the
>>>>>> methods on the interface to cache the answers? That would be unwise
>>>>>> because the list of variants may change over time for some MRIs. Are
>>>>>> we speaking to the implementer? If so, then I think that it is
>>>>>> unnecessary to remind implementers of basic implementation
>>>>>> strategies like "cache complicated objects".
>>>>>>
>>>>>> How about this wording for the getRV() method? - "Gets a specific
>>>>>> image that is the best variant to represent this logical image at
>>>>>> the indicated size and screen resolution."
>>>>>>
>>>>>> Perhaps we should clarify in the doc comments for the dimension
>>>>>> arguments in getRV() that the dimensions are measured in pixels?
>>>>>>
>>>>>> line 56 - delete blank line between doc comment and method 
>>>>>> declaration
>>>>>>
>>>>>> Also, it is probably overkill to document that the interface
>>>>>> getVariants() method returns an unmodifiable list. Responsible
>>>>>> implementations would probably use an unmodifiable list, but I don't
>>>>>> think it should be required by the interface.  We do need to specify
>>>>>> that it isn't required to be modifiable so that a caller doesn't
>>>>>> expect to be able to modify it, but that is a looser spec.  How
>>>>>> about "Gets a readable list of all resolution variants.  Note that
>>>>>> many implementations might return an unmodifiable list."?
>>>>>>
>>>>>> AbstractMIR.java:
>>>>>>
>>>>>> "provides a default implementation for the MRI" or "provides default
>>>>>> implementations of several methods in the <MRI> interface and the
>>>>>> <Image> class"?  Actually, I'll note that it provides none of the
>>>>>> implementations of the MRI methods so maybe it should be "provides
>>>>>> default implementations of several <Image> methods for classes that
>>>>>> want to implement the <MRI> interface"?
>>>>>>
>>>>>> In the doc example - wrap the list to make it unmodifiable
>>>>>>
>>>>>> The doc example could be made 2 or 3 lines shorter by simply
>>>>>> assuming the base image is in index 0 (it's just an example so I'm
>>>>>> not sure the flexibility needs to be a part of the example).
>>>>>>
>>>>>> getGraphics is allowed by the Image interface to return null.
>>>>>> Actually, the exact wording is that it can only be called for
>>>>>> "offscreen images" and a MRI is technically not "an offscreen
>>>>>> image".  Perhaps we should return null here since modifying the base
>>>>>> image is unlikely to modify the variants and arguably it would be
>>>>>> required by the wording in the method docs (even if the base image
>>>>>> was an offscreen, the MRI produced from it stops being an offscreen)?
>>>>>>
>>>>>> Are all of the empty "@Inherit" comments needed?  I thought
>>>>>> inheritance was the default?
>>>>>>
>>>>>> BaseMRI.java:
>>>>>>
>>>>>> "This class is [an] array-based implementation of the {AMRI} class"
>>>>>> (missing "an" and "the")
>>>>>>
>>>>>> We should probably include the comment about the sorting of the
>>>>>> images in the class comments as well as document that the algorithm
>>>>>> is a simple scan from the beginning for the first image large enough
>>>>>> (and default == last image).  The algorithm also might not work very
>>>>>> well if the images are not monotonically both wider and taller.  How
>>>>>> about adding this to the class comments:
>>>>>>
>>>>>> "The implementation will return the first image variant in the array
>>>>>> that is large enough to satisfy the rendering request. For best
>>>>>> effect the array of images should be sorted with each image being
>>>>>> both wider and taller than the previous image. The base image need
>>>>>> not be the first image in the array."
>>>>>>
>>>>>> getVariants() - you need to return an unmodifiable list. asList()
>>>>>> returns a list that "writes back" to the array.  You need to use
>>>>>> Collections.unmodifiableList(Arrays.asList(array)).
>>>>>>
>>>>>> RenderingHints.java:
>>>>>>
>>>>>> Where do we process this hint?  Don't we need to pass it to the
>>>>>> getVariant() method?
>>>>>>
>>>>>> I don't understand the hint values other than the one that always
>>>>>> uses the base image.  Default I guess gives us the ability to use
>>>>>> the Mac algorithm of "next larger size" on Mac and "based on Screen
>>>>>> DPI" on Windows, but the 3rd value "ON" is so vague as to not have
>>>>>> any meaning.  Perhaps we should just delete it, but then do we just
>>>>>> always do the Mac method? Or do we vaguely have our internal images
>>>>>> have a platform-specific method and the Abstract/Base classes just
>>>>>> do what they want with no control from the user?  In FX we are also
>>>>>> still struggling with this issue and we may likely just do what the
>>>>>> Mac does in all cases, but perhaps AWT needs to "behave like the
>>>>>> platform" more?  If we are going to have actual values, then we need
>>>>>> to have them do something, which means:
>>>>>>
>>>>>> - SG2D needs to track the hint just like we do the other hints that
>>>>>> affect our processing
>>>>>> - MRI.getVariant() needs to have the hint as an argument
>>>>>> - BaseMRI should probably do something with that hint
>>>>>> - hint values should include:
>>>>>>    - ..._DEFAULT - implementation gets to decide
>>>>>>    - ..._BASE - always use the base image
>>>>>>    - ..._SIZE_FIT - Mac algorithm of smallest image that is big 
>>>>>> enough
>>>>>>    - ..._DPI_FIT - choose based on DPI of the screen, ignoring
>>>>>> transform
>>>>>>
>>>>>> line 978 - missing blank line between fields
>>>>>>
>>>>>> SG2D.java:
>>>>>>
>>>>>> - The interface says that you will be passing in the "logical DPI"
>>>>>> of the display, but here you are actually passing in the screen's
>>>>>> scale factor.
>>>>>>
>>>>>> BaseMRITest.java:
>>>>>>
>>>>>> - testBaseMRI also passes in a scale rather than a DPI to the MRI
>>>>>> method.
>>>>>>
>>>>>> - How does the modification test pass when the implementation
>>>>>> doesn't use unmodifiable lists?
>>>>>>
>>>>>> MRITest.java:
>>>>>>
>>>>>> - also uses scale rather than DPI in several places
>>>>>>
>>>>>>        ...jim
>>>>>>
>>>>>> On 3/13/15 6:34 AM, Alexander Scherbatiy wrote:
>>>>>>>
>>>>>>>   Hello,
>>>>>>>
>>>>>>>   Could you review the proposed API based on MultiresolutionImage
>>>>>>> interface:
>>>>>>> http://cr.openjdk.java.net/~alexsch/8029339/webrev.06/ 
>>>>>>> <http://cr.openjdk.java.net/%7Ealexsch/8029339/webrev.06/>
>>>>>>>
>>>>>>>  - return unmodifiable list comment is added to the
>>>>>>> getResolutionVariants() method javadoc in MultiresolutionImage
>>>>>>> interface
>>>>>>>  - base image size arguments are removed form the
>>>>>>> getResolutionVariant(...) method in MultiresolutionImage interface
>>>>>>>  - BaseMultiResolutionImage class that allows to create a
>>>>>>> multi-resolution image based on resolution variant array is added
>>>>>>>  - the test for the BaseMultiResolutionImage is added
>>>>>>>
>>>>>>>  Thanks,
>>>>>>>  Alexandr.
>>>>>>>
>>>>>>> On 2/14/2015 3:23 AM, Jim Graham wrote:
>>>>>>>> The second solution looks good.  I'd make it standard practice
>>>>>>>> (perhaps even mentioned in the documentation) to return 
>>>>>>>> unmodifiable
>>>>>>>> lists from the getVariants() method.  The Collections class 
>>>>>>>> provides
>>>>>>>> easy methods to create these lists, and it sends a clear message to
>>>>>>>> the caller that the list was provided for them to read, but not 
>>>>>>>> write
>>>>>>>> to.  Otherwise they may add a new image to the list you 
>>>>>>>> provided them
>>>>>>>> and wonder why it wasn't showing up.  Also, an unmodifiable 
>>>>>>>> list can
>>>>>>>> be cached and reused for subsequent calls without having to 
>>>>>>>> create a
>>>>>>>> new list every time.
>>>>>>>>
>>>>>>>> In getResolutionVariant() was there a reason why the base 
>>>>>>>> dimensions
>>>>>>>> were provided as float?  The destination dimensions make sense as
>>>>>>>> float since they could be the result of a scale, but the source
>>>>>>>> dimensions are typically getWidth/getHeight() on the base image.  A
>>>>>>>> related question would be if they are needed at all, since the
>>>>>>>> implementation should probably already be aware of what the base
>>>>>>>> image
>>>>>>>> is and what its dimensions are.  I'm guessing they are provided
>>>>>>>> because the implementation in SG2D already knows them and it 
>>>>>>>> makes it
>>>>>>>> easier to forward the implementation on to a shared (static?) 
>>>>>>>> method?
>>>>>>>>
>>>>>>>> With respect to default implementations, I take it that the
>>>>>>>> BaseMRI is
>>>>>>>> along the pattern that we see in Swing for Base classes. Would 
>>>>>>>> it be
>>>>>>>> helpful to provide an implementation (in addition or instead) that
>>>>>>>> allows a developer to take a bunch of images and quickly make 
>>>>>>>> an MRI
>>>>>>>> without having to override anything?  The implementations of
>>>>>>>> getBaseImage() and getResolutionVariants() are pretty 
>>>>>>>> straightforward
>>>>>>>> and a fairly reasonable default algorithm can be provided for
>>>>>>>> getRV(dimensions).  This question is more of an idle question 
>>>>>>>> for my
>>>>>>>> own curiosity than a stumbling block...
>>>>>>>>
>>>>>>>>            ...jim
>>>>>>>>
>>>>>>>> On 1/22/2015 6:49 AM, Alexander Scherbatiy wrote:
>>>>>>>>>
>>>>>>>>>   Hi Phil,
>>>>>>>>>
>>>>>>>>>   I have prepared two versions of the proposed API:
>>>>>>>>>
>>>>>>>>>   I) Resolution variants are added directly to the Image:
>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8029339/list/webrev.00 
>>>>>>>>> <http://cr.openjdk.java.net/%7Ealexsch/8029339/list/webrev.00>
>>>>>>>>>
>>>>>>>>>   II)  MultiResolutionImage interface is used:
>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8029339/webrev.05
>>>>>>>>>
>>>>>>>>>   It could help to decide which way should be chosen for the the
>>>>>>>>> multi-resolution image support.
>>>>>>>>>
>>>>>>>>>   Below are some comments:
>>>>>>>>>
>>>>>>>>>   1. High level goal:
>>>>>>>>>      Introduce an API that allows to create and handle an image
>>>>>>>>> with
>>>>>>>>> resolution variants.
>>>>>>>>>
>>>>>>>>>   2. What is not subject of the provided API
>>>>>>>>>     - Scale naming convention for high-resolution images
>>>>>>>>>     - Providing pixel scale factor for the screen/window
>>>>>>>>>
>>>>>>>>>   3. Use cases
>>>>>>>>>    3.1 Loading and drawing high-resolution icons in IntelliJ IDEA
>>>>>>>>>      A high-resolution image is loaded from resources and 
>>>>>>>>> stored in
>>>>>>>>> JBHiDPIScaledImage class  which is a subclass of the buffered 
>>>>>>>>> image.
>>>>>>>>>      The high-resolution image is used to create a disabled icon
>>>>>>>>> in the
>>>>>>>>> IconLoader.getDisabledIcon(icon) method.
>>>>>>>>> https://github.com/JetBrains/intellij-community/blob/master/platform/util/src/com/intellij/openapi/util/IconLoader.java
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>    3.2 Loading and drawing high-resolution icons in NetBeans
>>>>>>>>>      NetBeans does not have support for the high-resolution icons
>>>>>>>>> loading.
>>>>>>>>>      It loads an icon from the file system using
>>>>>>>>> Toolkit.getDefaultToolkit().getImage(url) method or from resources
>>>>>>>>>      by  ImageReader  and store it in ToolTipImage class which is
>>>>>>>>> subclass of the buffered image.
>>>>>>>>>      ImageUtilities.createDisabledIcon(icon) method creates a
>>>>>>>>> disabled
>>>>>>>>> icon by applying  RGBImageFilter to the icon.
>>>>>>>>> http://hg.netbeans.org/main/file/97dcf49eb4a7/openide.util/src/org/openide/util/ImageUtilities.java
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>    3.3 Loading system icons in JDK 1.8
>>>>>>>>>      JDK requests icons from the native system for system L&Fs and
>>>>>>>>> applies filters for them.
>>>>>>>>>      See for example AquaUtils.generateLightenedImage() method:
>>>>>>>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/e6f48c4fad38/src/java.desktop/macosx/classes/com/apple/laf/AquaUtils.java
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>   4. HiDPI support for Images on different OSes
>>>>>>>>>
>>>>>>>>>     4.1 Mac OS X
>>>>>>>>>       Cocoa API contains NSImage that allows to work with image
>>>>>>>>> representations: add/remove/get all representations.
>>>>>>>>>       It picks up an image with necessary resolution based on the
>>>>>>>>> screen backing store pixel scale factor and applied transforms.
>>>>>>>>> https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSImage_Class/Reference/Reference.html
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>     4.2 Linux
>>>>>>>>>       GTK+ 3 API has gtkcssimagescaled lib (it seems that it 
>>>>>>>>> is not
>>>>>>>>> public/stable)
>>>>>>>>>       that parses the -gtk-scaled css property and draws a
>>>>>>>>> GtkCssImage
>>>>>>>>> according to the given scale factor.
>>>>>>>>>
>>>>>>>>>       I have not found information about the HiDPI support in 
>>>>>>>>> Xlib.
>>>>>>>>>
>>>>>>>>>     4.3 Windows
>>>>>>>>>       I have only found the tutorial that suggests to select and
>>>>>>>>> draw a
>>>>>>>>> bitmap using the queried DPI
>>>>>>>>>       and scale the coordinates for drawing a rectangular frame
>>>>>>>>> http://msdn.microsoft.com/en-us/library/dd464659%28v=vs.85%29.aspx
>>>>>>>>>
>>>>>>>>>       Windows also provides the horizontal and vertical DPI of the
>>>>>>>>> desktop
>>>>>>>>> http://msdn.microsoft.com/en-us/library/windows/apps/dd371316
>>>>>>>>>
>>>>>>>>>   5. Pseudo API
>>>>>>>>>      Below are some ways which illustrates how multi-resolution
>>>>>>>>> images
>>>>>>>>> can be created and used.
>>>>>>>>>
>>>>>>>>>     5.1 Resolution variants are stored directly in Image class.
>>>>>>>>>     To query a resolution variant it needs to compare the
>>>>>>>>> resolution
>>>>>>>>> variant width/height
>>>>>>>>>     with the requested high-resolution size.
>>>>>>>>>     ------------
>>>>>>>>>     public abstract class Image {
>>>>>>>>>
>>>>>>>>>         public void addResolutionVariant(Image image) {...}
>>>>>>>>>         public List<Image> getResolutionVariants() {...}
>>>>>>>>>     }
>>>>>>>>>     ------------
>>>>>>>>>     // create a disabled image with resolution variants
>>>>>>>>>
>>>>>>>>>     Image disabledImage = getDisabledImage(image);
>>>>>>>>>
>>>>>>>>>     for (Image rv : image.getResolutionVariants()) {
>>>>>>>>> disabledImage.addResolutionVariant(getDisabledImage(rv));
>>>>>>>>>     }
>>>>>>>>>     ------------
>>>>>>>>>     This approach requires that all resolution variants have been
>>>>>>>>> created even not of them are really used.
>>>>>>>>>
>>>>>>>>>     5.2  Resolution variants are stored in a separate object that
>>>>>>>>> allows to create them by demand.
>>>>>>>>>     To query a resolution variant it needs to compare the
>>>>>>>>> resolution
>>>>>>>>> variant scale factor
>>>>>>>>>     with the requested scale (that can include both screen DPI
>>>>>>>>> scale
>>>>>>>>> and applied transforms).
>>>>>>>>>     ------------
>>>>>>>>>     public abstract class Image {
>>>>>>>>>
>>>>>>>>>         public static interface ResolutionVariant {
>>>>>>>>>             Image getImage();
>>>>>>>>>             float getScaleFactor();
>>>>>>>>>         }
>>>>>>>>>
>>>>>>>>>         public void addResolutionVariant(ResolutionVariant
>>>>>>>>> resolutionVariant) {...}
>>>>>>>>>         public List<ResolutionVariant> getResolutionVariants()
>>>>>>>>> {...}
>>>>>>>>>     }
>>>>>>>>>     ------------
>>>>>>>>>     // create a disabled image with resolution variants
>>>>>>>>>     Image disabledImage = getDisabledImage(image);
>>>>>>>>>
>>>>>>>>>     for (Image.ResolutionVariant rv :
>>>>>>>>> image.getResolutionVariants()) {
>>>>>>>>>         disabledImage.addResolutionVariant(new
>>>>>>>>> Image.ResolutionVariant() {
>>>>>>>>>
>>>>>>>>>             public Image getImage() {
>>>>>>>>>                 return getDisabledImage(rv.getImage());
>>>>>>>>>             }
>>>>>>>>>
>>>>>>>>>             public float getScaleFactor() {
>>>>>>>>>                 return rv.getScaleFactor();
>>>>>>>>>             }
>>>>>>>>>         });
>>>>>>>>>     }
>>>>>>>>>     ------------
>>>>>>>>>
>>>>>>>>>     It does not have problem if a predefined set of images is
>>>>>>>>> provided
>>>>>>>>> (like image.png and image at 2x.png on the file system).
>>>>>>>>>     This does not cover cases where a resolution variant can be
>>>>>>>>> created
>>>>>>>>> using the exact requested size (like loading icons from the native
>>>>>>>>> system).
>>>>>>>>>     A resolution variant can be queried based on a scale 
>>>>>>>>> factor and
>>>>>>>>> applied transforms.
>>>>>>>>>
>>>>>>>>>     5.3 The provided example allows to create a resolution variant
>>>>>>>>> using the requested high-resolution image size.
>>>>>>>>>     ------------
>>>>>>>>>     public interface MultiResolutionImage {
>>>>>>>>>         Image getResolutionVariant(float width, float height);
>>>>>>>>>     }
>>>>>>>>>     ------------
>>>>>>>>>     // create a multi-resolution image
>>>>>>>>>     Image mrImage = new AbstractMultiResolutionImage() {
>>>>>>>>>
>>>>>>>>>             public Image getResolutionVariant(float width, float
>>>>>>>>> height) {
>>>>>>>>>                 // create and return a resolution variant with
>>>>>>>>> exact
>>>>>>>>> requested width/height size
>>>>>>>>>             }
>>>>>>>>>
>>>>>>>>>             protected Image getBaseImage() {
>>>>>>>>>                 return baseImage;
>>>>>>>>>             }
>>>>>>>>>         };
>>>>>>>>>     ------------
>>>>>>>>>     // create a disabled image with resolution variants
>>>>>>>>>     Image disabledImage = null;
>>>>>>>>>     if (image instanceof MultiResolutionImage) {
>>>>>>>>>         final MultiResolutionImage mrImage = 
>>>>>>>>> (MultiResolutionImage)
>>>>>>>>> image;
>>>>>>>>>         disabledImage = new AbstractMultiResolutionImage(){
>>>>>>>>>
>>>>>>>>>             public Image getResolutionVariant(float width, float
>>>>>>>>> height) {
>>>>>>>>>                 return
>>>>>>>>> getDisabledImage(mrImage.getResolutionVariant(width, height));
>>>>>>>>>             }
>>>>>>>>>
>>>>>>>>>             protected Image getBaseImage() {
>>>>>>>>>                 return getDisabledImage(mrImage);
>>>>>>>>>             }
>>>>>>>>>         };
>>>>>>>>>     } else {
>>>>>>>>>         disabledImage = getDisabledImage(image);
>>>>>>>>>     }
>>>>>>>>>     ------------
>>>>>>>>>
>>>>>>>>>   Thanks,
>>>>>>>>>   Alexandr.
>>>>>>>
>>>>>
>>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20170329/00ec8559/attachment.html>

From anton.litvinov at oracle.com  Thu Mar 30 18:32:16 2017
From: anton.litvinov at oracle.com (Anton Litvinov)
Date: Thu, 30 Mar 2017 21:32:16 +0300
Subject: [OpenJDK 2D-Dev] [9] Review request for 8167102: [macosx]
 PrintRequestAttributeSet breaks page size set using PageFormat
In-Reply-To: <58DBF01E.20907@oracle.com>
References: <17a96ade-ea01-95bd-728a-ec3106d1fbfa@oracle.com>
 <ae716330-c0c4-9b2c-4f6b-c30855e659dc@oracle.com>
 <7d710d7a-386f-a6c3-7f6d-13e56a7309a6@oracle.com>
 <b5efdb91-dd13-045f-18bd-f95830ba61fe@oracle.com>
 <89b66f3b-d1f0-5c88-1b7c-6065ad6ce4da@oracle.com>
 <ce891f45-bc5e-ec00-8074-880e26b93f39@oracle.com>
 <43402a5f-4e4b-ce6f-262d-e6b21176fb99@oracle.com>
 <2fad447d-2219-e3a6-68c5-91fc4822eb29@oracle.com>
 <b6a5a113-d958-fb6d-4156-d49b9da9b4f1@oracle.com> <58DBF01E.20907@oracle.com>
Message-ID: <68b40594-ff76-2c7b-2f0b-185038402637@oracle.com>

Hello Phil,

Thank you very much for review of this fix. The new or the 3rd version 
of the fix, in which I tried to address your remarks, is created and is 
available at the next URL. The changes introduced into the fix are 
summarized in the end of the e-mail. Could you please review the new 
version of the fix.

Webrev (the 3rd version): 
http://cr.openjdk.java.net/~alitvinov/8167102/jdk9/webrev.02

In the second version of the fix I decided not to show the print dialog 
just to reduce the number of manual actions. Today I have practically 
verified that usage of either native or cross-platform dialogs does not 
influence the test behavior anyhow,  the document is printed with a 
wrong paper size without the fix, and with the expected paper size with 
the fix applied.

The user who reported the bug used "4 x 6 in" paper size, but in the 
regression test I decided to use A5 paper size, because it is standard 
and most importantly it is small, what lets to easily distinguish it 
from, for example, A4 or "Letter" paper sizes usually used as default on 
printers. But, yes, sure, the bug is not specific to A5, and to observe 
it is necessary just to have a printer's default paper size be different 
from a paper size in "PageFormat" set through 
"PrinterJob.setPrintable(Printable, PageFormat)".

I decided to mark the test, as requiring only Mac platform, because the 
issue occurs only on OS X platform and to reduce the number of manual 
tests for other platforms.

Yes, sure, I verified practically and can confirm that with the applied 
fix, if all or some of the attributes "OrientationRequested", 
"MediaSizeName", "MediaPrintableArea" are specified in 
"PrintRequestAttributeSet" transferred to 
"PrinterJob.print(PrintRequestAttributeSet)" method, then the new 
"PageFormat" based on values of these attributes is still created and 
successfully applied to the printed page. This functionality is not 
changed because, the new page format is created in the method 
"RasterPrinterJob.setAttributes(PrintRequestAttributeSet)" in the "if" 
block specified below

"if ((orientReq != null || media != null || mpa != null) &&
             getPageable() instanceof OpenBook) {"

and saved in the PrinterJob in the end of this "if" block by the 
expression "setPrintable(printable, pf);". The sequence of calls is 
following:

CPrinterJob.print(PrintRequestAttributeSet) --> 
CPrinterJob.setAttributes(PrintRequestAttributeSet) --> 
RasterPrinterJob.setAttributes(PrintRequestAttributeSet)

CHANGES IN THE 3RD VERSION OF THE FIX:
In this version of the fix only the regression test was changed.

1) The jtreg argument "27    @requires (os.family == "mac")" was removed 
and I verified that the test works and does not fail on Windows OS and 
Linux OS.
2) Showing of the native print dialog is added to the test. "102         
if (job.printDialog()) {"
3) The next "if" block is completely removed, because the condition will 
never be fulfilled.

     94         if (isoA5Size == null) {
     95             throw new RuntimeException(
     96                 "No 'MediaSize' was found for 
'MediaSizeName.ISO_A5'.");
     97         }

4) The test timeout "60     private static final int testTimeout = 
300000;" is increased from previous 3 minutes to 5 minutes.
5) The hard coded instruction for execution of the test was changed to 
better reflect the test.

Thank you,
Anton

On 3/29/2017 8:34 PM, Philip Race wrote:
> If the test is manual anyway, why does it not display a dialog so it 
> is easier
> to run. On mac you can always then save as PDF so the "virtual 
> printer" isn't needed.
> Note: this assumes you are using the native dialog not the Swing one.
> Does this in some way change the test so that it passed anyway ?
>
>
> I also think you should try to verify this with
> (a) after displaying the cross-platform dialogs.
> (b) after displaying the native dialogs.
>
> There are an amazing number of code paths here ..
>
> throw new RuntimeException(
>                 "No 'MediaSize' was found for 'MediaSizeName.ISO_A5'.");
> Why insist on A5 ? Any number of sizes should work ?
> And making the test fail in such a case is plain wrong.
>
> Why    @requires (os.family == "mac")
> since the test can run everywhere ? And it should pass everywhere too.
> This should be fixed.
>
> The directory name in the test is gratuitous and unneeded and
> the test name itself is ridiculously long.
> Instead let's call it
>
> Regarding the fix itself I am unclear what the impact is in
> the case the app supplies an attribute set that *does* have one or
> more attributes that affect PageFormat.  It might well be that
> these are applied already but I'd like assurance that has been verified.
> Some of the code references below seem to be a bit munged by mail
> so I can't work out what is being said.
>
> -phil.
>
>
>
> On 3/28/17, 5:55 AM, Anton Litvinov wrote:
>> Hello Prasanta,
>>
>> The correct "PageFormat" for each separate page is retrieved in the 
>> native function "PrinterView.m::rectForPage:(NSInteger)" by invoking 
>> the Java method "CPrinterJob.getPageformatPrintablePeekgraphics(int)" 
>> with the first expression specified below and getting the value of 
>> "PageFormat" from the returned array with the second expression 
>> specified below.
>>
>> "jobjectArray objectArray = JNFCallObjectMethod(env, fPrinterJob, 
>> jm_getPageformatPrintablePeekgraphics, jPageNumber); // AWT_THREADING 
>> Safe (AWTRunLoopMode)"
>> "jobject pageFormat = (*env)->GetObjectArrayElement(env, objectArray, 
>> 0);"
>>
>> But in that native method "PrinterView.m::rectForPage" only the page 
>> orientation field "mOrientation" of the retrieved "PageFormat" for 
>> each page is analyzed and is set to "NSPrintInfo" object through 
>> "NSPrintOperation". Thus for some reason at that method analysis of 
>> the paper size is ignored.
>>
>> So obviously not taking into account individual paper size of the 
>> pages for the case, which you described, when the user's code 
>> specifies different "PageFormat" instances for different pages of the 
>> document, should take place in JDK, though I did not verify this 
>> practically. But this issue existed before my fix and is not a result 
>> of the fix.
>>
>> I do not see anything bad in the hard coded "0" page number used in 
>> my fix, because we need to initialize "NSPrintInfo" with a valid page 
>> size and the page size of the first page of the document is the only 
>> correct or appropriate value for this moment, and because this 
>> approach already exists in "RasterPrinterJob.java" as the next 
>> expression.
>>
>> "PageFormat pf = (PageFormat)pageable.getPageFormat(0).clone();"
>>
>> From my point of view, the issue about disrespect of different paper 
>> sizes for different pages of the document is the issue which is 
>> different from the issue described in this bug (JDK-8167102) and 
>> should be fixed separately from my bug, because:
>> - In my bug "java.awt.print.Printable" interface is involved, while 
>> in this new issue "java.awt.print.Pageable" interface is the explicit 
>> requirement;
>> - In my bug calling "PrinterJob.print(PrintRequestAttributeSet)" with 
>> a non-empty "PrintRequestAttributeSet" is the obligatory and the key 
>> requirement, while in the new issue this condition is irrelevant.
>> - For my bug one regression test is necessary, while for the new 
>> issue the different regression test is necessary.
>>
>> Therefore I suggest to file a separate bug for the discovered issue 
>> and to address it separately from this bug (JDK-8167102). Would you 
>> agree with this suggestion? Would you approve the second version of 
>> the fix for the bug JDK-8167102?
>>
>> Thank you,
>> Anton
>>
>> On 3/28/2017 12:46 PM, Prasanta Sadhukhan wrote:
>>>
>>> Hi Anton,
>>>
>>>
>>> On 3/27/2017 10:05 PM, Anton Litvinov wrote:
>>>> Hello Prasanta,
>>>>
>>>> Indeed it is Mac specific, as it was written in my previous e-mail, 
>>>> I verified this fact on Windows OS and Linux OS by your request.
>>>>
>>>> Yes, I am fully sure that, when the bug occurs, the paper size of 
>>>> the printed page is wrong, as it is stated in the bug, and I am 
>>>> fully sure that with the applied any of 2 versions of the created 
>>>> fix, the paper size of the printed page becomes correct and as 
>>>> expected. Otherwise, I would not send the fix for review. The 
>>>> instruction, by following which the bug can be reproduced, is 
>>>> written in "STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :" section of 
>>>> the description of the bug in JBS. This bug is raised by the user, 
>>>> who owns a support contract and requests for resolution of this 
>>>> bug, this can be seen in proper comments of the bug record.
>>>>
>>>> The automated regression test is not possible for this bug, since 
>>>> it is necessary to verify visually that the document is physically 
>>>> printed on the paper of the expected size. Otherwise, I would send 
>>>> the 1st version of the fix with the automated test already, it is 
>>>> not the first bug in JDK on which I have been working. By your 
>>>> request the regression test, even though it is manual, was created 
>>>> and added to the 2nd version of the fix.
>>>>
>>>> Yes, it is correct, the implemented by the test, and the test case 
>>>> method "Printable.print(Graphics, PageFormat, int)" receives the 
>>>> correct instance of "PageFormat" in runtime in scenario described 
>>>> in this bug, because, as you already described, it is extracted 
>>>> using the expression "pageable.getPageFormat(pageIndex)" in the 
>>>> Java method 
>>>> "sun.lwawt.macosx.CPrinterJob.getPageformatPrintablePeekgraphics(int)" 
>>>> called from "PrinterView.m::rectForPage:(NSInteger)" and further 
>>>> transferred in this method to the Java method 
>>>> "sun.lwawt.macosx.CPrinterJob.printAndGetPageFormatArea".
>>>>
>>>> The wrong paper size which is returned from the method 
>>>> "RasterPrinterJob.getPageFormatFromAttributes()" and which is set 
>>>> to certain fields of the Objective-C  object "NSPrintInfo" in the 
>>>> function "CPrinterJob.m::javaPaperToNSPrintInfo" through the next 
>>>> call sequence
>>>>
>>>> CPrinterJob.m::printLoop() --> 
>>>> CPrinterJob.m::javaPrinterJobToNSPrintInfo() --> 
>>>> CPrinterJob.m::javaPageFormatToNSPrintInfo() --> 
>>>> CPrinterJob.m::javaPaperToNSPrintInfo()
>>>>
>>>> further influences physical size of all pages printed by 1 printer job.
>>>>
>>>> Thus, I consider that firstly "PageFormat" returned from 
>>>> "RasterPrinterJob.getPageFormatFromAttributes()" is wrong, and 
>>>> secondly setting paper size from this wrong "PageFormat" to proper 
>>>> fields of "NSPrintInfo" object is also incorrect and is a root 
>>>> cause of this bug.
>>> OK. So, pageformat values set to native NSPrintInfo is different 
>>> (wrong) compared to what is being passed to user.
>>>>
>>>> Implementation of Java Print Server API surely contains many 
>>>> issues, and only working on this bug I already encountered 2 
>>>> additional different issues, which are described in one of my 
>>>> comments in this bug record in JBS. However, I prefer to resolve 
>>>> issues separately and to resolve this particular bug also 
>>>> separately from other issues which we can indefinitely find while 
>>>> looking at the code and debugging it, also because it is necessary 
>>>> to deliver the fix for this bug to "jdk8u-dev" repository finally, 
>>>> while JDK 9 is currently in RDP 2 phase at which large fixes 
>>>> affecting more platforms or large code scope would hardly be 
>>>> accepted by Group and Area leads or the release team.
>>>>
>>>> I would like to bring also your attention again to the fact, which 
>>>> was mentioned in my previous e-mail, that I already ran all manual 
>>>> and automatic "jtreg" regression tests related to printing from 
>>>> open and closed parts of JDK on JDK 9 without the fix and with the 
>>>> fix, what is 198 tests.
>>>>
>>>> Do you find anything incorrect in the 2nd version of the fix? Will 
>>>> you approve the 2nd version of the fix?
>>>>
>>> I think there might be a (probable) issue with this fix. PageFormat 
>>> of 1st page only is used to get the information.
>>> jobject page = JNFCallObjectMethod(env, srcPrinterJob, 
>>> jm_getPageFormat, (jint)0);
>>> What if user has set different pageformat to different page like 
>>> this below? Will it not lose the 2nd page pageformat? I guess in 
>>> windows/linux, we obtain pageformat for each pageindex
>>>
>>> PrinterJob job = PrinterJob.getPrinterJob();
>>> // Create a landscape pageformat
>>> PageFormat pfl = job.defaultPage();
>>> pfl.setOrientation(PageFormat.LANDSCAPE);
>>> //Setup a book
>>> Book bk = new Book();
>>> bk.append(new xPrintable(), pfl); // 1st page landscape , can be 
>>> diff. pagesize too
>>> bk.append(new xxPrintable(), job.defaultPage()); //2nd page portrait
>>> job.setPageable(bk);
>>>
>>> Regards
>>> Prasanta
>>>> Thank you,
>>>> Anton
>>>>
>>>> On 3/27/2017 9:52 AM, Prasanta Sadhukhan wrote:
>>>>>
>>>>> Hi Anton,
>>>>>
>>>>> Ok. So, it seems it mac specific. But, are you sure wrong page 
>>>>> size is used in mac as is claimed in the bug?
>>>>> I thought we could use automated regression test instead of manual 
>>>>> by checking pageformat value in print() as compared to what user 
>>>>> passes in setPrintable().
>>>>>
>>>>> Then, I see in print() method in testcase, the "PageFormat" 
>>>>> argument passed has same values as it is passed in setPrintable() 
>>>>> in main() even without your fix.
>>>>>
>>>>> If I reverse trace from print() method present in testcase, I see 
>>>>> it is called from CPrinterJob.java#printAndGetPageFormatArea()
>>>>> which is called from PrinterView.m#rectForPage. And before calling 
>>>>> printAndGetPageFormatArea() it calls 
>>>>> getPageformatPrintablePeekgraphics() which calls 
>>>>> pageable.getPageFormat(pageIndex), so it should behave same as 
>>>>> windows. Am I missing something?
>>>>>
>>>>> Regards
>>>>> Prasanta
>>>>> On 3/27/2017 3:32 AM, Anton Litvinov wrote:
>>>>>> Hello Prasanta,
>>>>>>
>>>>>> I verified that the bug is not reproducible using JDK 9 compiled 
>>>>>> from the latest version of "jdk9/client" forest neither on 
>>>>>> Windows, nor on Linux platform, therefore, yes, this bug is only 
>>>>>> Mac specific. Debugging showed that on Windows platform the 
>>>>>> behavior is exactly like you described, on Windows 
>>>>>> "RasterPrinterJob.print(PrintRequestAttributeSet)" method is 
>>>>>> responsible for printing the documents and in this method 
>>>>>> "RasterPrinterJob.printPage(Pageable, int)" is called for each 
>>>>>> page separately, and in this "printPage" method "PageFormat" 
>>>>>> instance used for printing of the page is extracted from the the 
>>>>>> transferred as the method argument instance of "Pageable" by the 
>>>>>> expression "origPage = document.getPageFormat(pageIndex);".
>>>>>>
>>>>>> The new version of the fix was created. Could you please review 
>>>>>> the second version of the fix.
>>>>>>
>>>>>> Webrev (the 2nd version): 
>>>>>> http://cr.openjdk.java.net/~alitvinov/8167102/jdk9/webrev.01
>>>>>>
>>>>>> In the second version of the fix:
>>>>>> 1. Calling for "RasterPrinterJob.getPageFormatFromAttributes()" 
>>>>>> was substituted for 
>>>>>> "sun.lwawt.macosx.CPrinterJob.getPageFormat(int)" in the native 
>>>>>> method "CPrinterJob.m#javaPrinterJobToNSPrintInfo".
>>>>>> 2. The method "RasterPrinterJob.getPageFormatFromAttributes()" 
>>>>>> was removed, since it is not called from any other code in "jdk" 
>>>>>> repository.
>>>>>> 3. The manual regression test was created.
>>>>>>
>>>>>> Also on OS X I executed all manual and automatic "jtreg" 
>>>>>> regression tests related to printing from the listed below 
>>>>>> directories and the corresponding directories in the closed 
>>>>>> repositories using both JDK 9 compiled without and with the fix, 
>>>>>> and I verified that no new test failed on JDK 9 with the fix.
>>>>>>
>>>>>> The directories with the regression tests from open repositories:
>>>>>> - "jdk/test/java/awt/print"
>>>>>> - "jdk/test/javax/print"
>>>>>>
>>>>>> Thank you,
>>>>>> Anton
>>>>>>
>>>>>> On 3/22/2017 7:42 AM, Prasanta Sadhukhan wrote:
>>>>>>>
>>>>>>> Hi Anton,
>>>>>>>
>>>>>>> I thought about your point and have a question: does this issue 
>>>>>>> not reproduce in non-mac platform?
>>>>>>> I thought it probably would so suggested modifying 
>>>>>>> setAttributes() . But, if it is only reproduced in mac, we need 
>>>>>>> to find out why despite this setAttributes() flaw, how this is 
>>>>>>> working in non-mac platform?
>>>>>>>
>>>>>>> It probably might work in windows/linux because in 
>>>>>>> RasterPrinterJob.print(attr) method, after it calls 
>>>>>>> setAttributes(), it calls printPage() where it gets the original 
>>>>>>> PageFormat
>>>>>>> by calling getPageFormat(pageIndex) and gets the orientation, 
>>>>>>> imageablearea
>>>>>>> and not by constructing pageFormat from attributes as it is done 
>>>>>>> in mac.
>>>>>>> So, probably, in mac also, we need to do away with 
>>>>>>> getPageFormatFromAttributes() call  and call 
>>>>>>> getPageFormat(pageIndex) from 
>>>>>>> CPrinterJob.m#javaPrinterJobToNSPrintInfo().
>>>>>>>
>>>>>>> Regards
>>>>>>> Prasanta
>>>>>>> On 3/21/2017 8:15 PM, Anton Litvinov wrote:
>>>>>>>> Hello Prasanta,
>>>>>>>>
>>>>>>>> Thank you for review of this fix. I have tried to apply the 
>>>>>>>> approach which you suggested and it allowed to resolve the 
>>>>>>>> issue. In this case I agree that it would be more correct to 
>>>>>>>> resolve the issue in 
>>>>>>>> "RasterPrinterJob.setAttributes(PrintRequestAttributeSet)" 
>>>>>>>> method. In the first version of the fix I decided to change the 
>>>>>>>> method "RasterPrinterJob.getPageFormatFromAttributes()", 
>>>>>>>> because it is invoked only from 1 place in JDK code and this 
>>>>>>>> place is located in OS X specific code 
>>>>>>>> "jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m", 
>>>>>>>> so that would automatically minimize the affected by the fix 
>>>>>>>> platforms to OS X only.
>>>>>>>>
>>>>>>>> Starting to work on implementation of the second version of the 
>>>>>>>> fix including the regression test.
>>>>>>>>
>>>>>>>> Thank you,
>>>>>>>> Anton
>>>>>>>>
>>>>>>>> On 3/21/2017 12:52 PM, Prasanta Sadhukhan wrote:
>>>>>>>>>
>>>>>>>>> I think the real problem is not in 
>>>>>>>>> RasterPrinterJob.getPageFormatFromAttributes().
>>>>>>>>>
>>>>>>>>> One can see that, when we call 
>>>>>>>>> RasterPrinterJob.setPrintable(), we call 
>>>>>>>>> updatePageAttributes() which in turn calls 
>>>>>>>>> updateAttributesWithPageFormat() where orientation, media and 
>>>>>>>>> mediaprintablearea "attributes" get populated/cached from the 
>>>>>>>>> "pageformat" supplied by the user.
>>>>>>>>>
>>>>>>>>> But, when PrinterJob.print(PrintRequestAttributeSet) is 
>>>>>>>>> called, it calls setAttributes(attributes) where "attributes" 
>>>>>>>>> is what is populated by the user. It does not contain 
>>>>>>>>> orientation,media and mediaprintablearea attributes for this 
>>>>>>>>> bug, so setAttributes sets cached attribute with this user-set 
>>>>>>>>> attribute instance
>>>>>>>>> />>else {//
>>>>>>>>> //>>            // for AWT where pageable is not an instance 
>>>>>>>>> of OpenBook,//
>>>>>>>>> //>>            // we need to save paper info//
>>>>>>>>> // >>           this.attributes = attributes;//
>>>>>>>>> // >>       }//
>>>>>>>>> /
>>>>>>>>>
>>>>>>>>> //thereby losing the attributes it has cached earlier from 
>>>>>>>>> user pageformat. I think we should check if this.attributes is 
>>>>>>>>> not null, then retain those attributes unless explicitly set 
>>>>>>>>> by the user in user-defined attributes.
>>>>>>>>>
>>>>>>>>> But, this code is used by windows,linux,mac so it needs to be 
>>>>>>>>> tested against all those platforms to ensure we are not 
>>>>>>>>> regressing anything.
>>>>>>>>>
>>>>>>>>> Also, I think user should call validatePage(PageFormat) in 
>>>>>>>>> application to check if the settings passed is compatible with 
>>>>>>>>> the printer or not, get compatible/adjusted pageformat and 
>>>>>>>>> call setPrintable() with that "adjusted" pageformat. If user 
>>>>>>>>> pass 0,0,fullpaperwidth,fullpaperheight as imageablearea, then 
>>>>>>>>> he should not expect this setting to be used since printer 
>>>>>>>>> will have its own hardware limitation (and use some offset 
>>>>>>>>> printing)
>>>>>>>>>
>>>>>>>>> BTW, a regression testcase (even if it is manual) should be 
>>>>>>>>> created with the fix.
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> Prasanta
>>>>>>>>> On 3/17/2017 10:59 PM, Anton Litvinov wrote:
>>>>>>>>>> Hello,
>>>>>>>>>>
>>>>>>>>>> Could you please review the following fix for the bug.
>>>>>>>>>>
>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8167102
>>>>>>>>>> Webrev: 
>>>>>>>>>> http://cr.openjdk.java.net/~alitvinov/8167102/jdk9/webrev.00
>>>>>>>>>>
>>>>>>>>>> The bug consists in the fact that, if the user's application 
>>>>>>>>>> specifies the required page size (media size) through 
>>>>>>>>>> "java.awt.print.PrinterJob" API particularly via 
>>>>>>>>>> "java.awt.print.PageFormat" instance supplied to the method 
>>>>>>>>>> "PrinterJob.setPrintable(Printable, PageFormat)" and calls 
>>>>>>>>>> "PrinterJob.print(PrintRequestAttributeSet)" with 
>>>>>>>>>> "javax.print.attribute.PrintRequestAttributeSet" containing 
>>>>>>>>>> at least 1 any "PrintRequestAttribute", then the page or 
>>>>>>>>>> pages will be printed with "PageFormat" describing the 
>>>>>>>>>> default page size of the printer which is different from the 
>>>>>>>>>> expected and originally set by the user's application 
>>>>>>>>>> "PageFormat".
>>>>>>>>>>
>>>>>>>>>> Debugging showed that the new "PageFormat" with unexpected 
>>>>>>>>>> media size is created in the method 
>>>>>>>>>> "sun.print.RasterPrinterJob.getPageFormatFromAttributes()" 
>>>>>>>>>> which is invoked from the native function 
>>>>>>>>>> "jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m::javaPrinterJobToNSPrintInfo". 
>>>>>>>>>> The method "RasterPrinterJob.getPageFormatFromAttributes()" 
>>>>>>>>>> returns a new "PageFormat" always, if the provided by the 
>>>>>>>>>> user "PrintRequestAttributeSet" is not empty, and the default 
>>>>>>>>>> values are set to particular instance variables of this 
>>>>>>>>>> "PageFormat", if "PrintRequestAttributeSet" does not contain 
>>>>>>>>>> the searched "OrientationRequested", "MediaSizeName", 
>>>>>>>>>> "MediaPrintableArea" attributes.
>>>>>>>>>>
>>>>>>>>>> THE SOLUTION:
>>>>>>>>>> Although it is clearly stated in Java Platform SE 8 API 
>>>>>>>>>> Specification (documentation of the method 
>>>>>>>>>> "PrinterJob.print(PrintRequestAttributeSet)")
>>>>>>>>>> Specification URL: 
>>>>>>>>>> http://docs.oracle.com/javase/8/docs/api/java/awt/print/PrinterJob.html#print-javax.print.attribute.PrintRequestAttributeSet-
>>>>>>>>>>
>>>>>>>>>> that media size, orientation and imageable area attributes 
>>>>>>>>>> specified in "PrintRequestAttributeSet" supplied to the 
>>>>>>>>>> method "PrinterJob.print" will be used for construction of a 
>>>>>>>>>> new "PageFormat", which will be passed to "Printable" object, 
>>>>>>>>>> instead of the original "PageFormat" instance set through 
>>>>>>>>>> "PrinterJob.setPrintable" method, the observed in this issue 
>>>>>>>>>> behavior is a bug, because in the bug test case neither media 
>>>>>>>>>> size, nor orientation, nor imageable area attributes are 
>>>>>>>>>> specified in "PrintRequestAttributeSet".
>>>>>>>>>>
>>>>>>>>>> The fix alters the method 
>>>>>>>>>> "sun.print.RasterPrinterJob.getPageFormatFromAttributes()" to 
>>>>>>>>>> use corresponding values from "PageFormat" instance 
>>>>>>>>>> originally set through "PrinterJob" API during construction 
>>>>>>>>>> of the new "PageFormat", when it is found out that 
>>>>>>>>>> "OrientationRequested", or "MediaSizeName", or 
>>>>>>>>>> "MediaPrintableArea" attribute is not specified in 
>>>>>>>>>> "PrintRequestAttributeSet" supplied to "PrinterJob.print" 
>>>>>>>>>> method.
>>>>>>>>>>
>>>>>>>>>> Thank you,
>>>>>>>>>> Anton
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20170330/6bb5cf75/attachment.html>

From philip.race at oracle.com  Thu Mar 30 18:42:02 2017
From: philip.race at oracle.com (Phil Race)
Date: Thu, 30 Mar 2017 11:42:02 -0700
Subject: [OpenJDK 2D-Dev] [9] Review request for 8167102: [macosx]
 PrintRequestAttributeSet breaks page size set using PageFormat
In-Reply-To: <68b40594-ff76-2c7b-2f0b-185038402637@oracle.com>
References: <17a96ade-ea01-95bd-728a-ec3106d1fbfa@oracle.com>
 <ae716330-c0c4-9b2c-4f6b-c30855e659dc@oracle.com>
 <7d710d7a-386f-a6c3-7f6d-13e56a7309a6@oracle.com>
 <b5efdb91-dd13-045f-18bd-f95830ba61fe@oracle.com>
 <89b66f3b-d1f0-5c88-1b7c-6065ad6ce4da@oracle.com>
 <ce891f45-bc5e-ec00-8074-880e26b93f39@oracle.com>
 <43402a5f-4e4b-ce6f-262d-e6b21176fb99@oracle.com>
 <2fad447d-2219-e3a6-68c5-91fc4822eb29@oracle.com>
 <b6a5a113-d958-fb6d-4156-d49b9da9b4f1@oracle.com> <58DBF01E.20907@oracle.com>
 <68b40594-ff76-2c7b-2f0b-185038402637@oracle.com>
Message-ID: <f409ab7b-7f1f-e6c2-14c9-0cf303335860@oracle.com>

Hi,

OK I accept your assurances regarding testing and the observed 
behaviours, so "+1" to the fix.
If you plan to push this to jdk 9 please follow the RDP2 process and add 
the required "Fix comment" and jdk9-fix-request label.

-phil.

On 03/30/2017 11:32 AM, Anton Litvinov wrote:
> Hello Phil,
>
> Thank you very much for review of this fix. The new or the 3rd version 
> of the fix, in which I tried to address your remarks, is created and 
> is available at the next URL. The changes introduced into the fix are 
> summarized in the end of the e-mail. Could you please review the new 
> version of the fix.
>
> Webrev (the 3rd version): 
> http://cr.openjdk.java.net/~alitvinov/8167102/jdk9/webrev.02
>
> In the second version of the fix I decided not to show the print 
> dialog just to reduce the number of manual actions. Today I have 
> practically verified that usage of either native or cross-platform 
> dialogs does not influence the test behavior anyhow,  the document is 
> printed with a wrong paper size without the fix, and with the expected 
> paper size with the fix applied.
>
> The user who reported the bug used "4 x 6 in" paper size, but in the 
> regression test I decided to use A5 paper size, because it is standard 
> and most importantly it is small, what lets to easily distinguish it 
> from, for example, A4 or "Letter" paper sizes usually used as default 
> on printers. But, yes, sure, the bug is not specific to A5, and to 
> observe it is necessary just to have a printer's default paper size be 
> different from a paper size in "PageFormat" set through 
> "PrinterJob.setPrintable(Printable, PageFormat)".
>
> I decided to mark the test, as requiring only Mac platform, because 
> the issue occurs only on OS X platform and to reduce the number of 
> manual tests for other platforms.
>
> Yes, sure, I verified practically and can confirm that with the 
> applied fix, if all or some of the attributes "OrientationRequested", 
> "MediaSizeName", "MediaPrintableArea" are specified in 
> "PrintRequestAttributeSet" transferred to 
> "PrinterJob.print(PrintRequestAttributeSet)" method, then the new 
> "PageFormat" based on values of these attributes is still created and 
> successfully applied to the printed page. This functionality is not 
> changed because, the new page format is created in the method 
> "RasterPrinterJob.setAttributes(PrintRequestAttributeSet)" in the "if" 
> block specified below
>
> "if ((orientReq != null || media != null || mpa != null) &&
>             getPageable() instanceof OpenBook) {"
>
> and saved in the PrinterJob in the end of this "if" block by the 
> expression "setPrintable(printable, pf);". The sequence of calls is 
> following:
>
> CPrinterJob.print(PrintRequestAttributeSet) --> 
> CPrinterJob.setAttributes(PrintRequestAttributeSet) --> 
> RasterPrinterJob.setAttributes(PrintRequestAttributeSet)
>
> CHANGES IN THE 3RD VERSION OF THE FIX:
> In this version of the fix only the regression test was changed.
>
> 1) The jtreg argument "27    @requires (os.family == "mac")" was 
> removed and I verified that the test works and does not fail on 
> Windows OS and Linux OS.
> 2) Showing of the native print dialog is added to the test. 
> "102         if (job.printDialog()) {"
> 3) The next "if" block is completely removed, because the condition 
> will never be fulfilled.
>
>     94         if (isoA5Size == null) {
>     95             throw new RuntimeException(
>     96                 "No 'MediaSize' was found for 
> 'MediaSizeName.ISO_A5'.");
>     97         }
>
> 4) The test timeout "60     private static final int testTimeout = 
> 300000;" is increased from previous 3 minutes to 5 minutes.
> 5) The hard coded instruction for execution of the test was changed to 
> better reflect the test.
>
> Thank you,
> Anton
>
> On 3/29/2017 8:34 PM, Philip Race wrote:
>> If the test is manual anyway, why does it not display a dialog so it 
>> is easier
>> to run. On mac you can always then save as PDF so the "virtual 
>> printer" isn't needed.
>> Note: this assumes you are using the native dialog not the Swing one.
>> Does this in some way change the test so that it passed anyway ?
>>
>>
>> I also think you should try to verify this with
>> (a) after displaying the cross-platform dialogs.
>> (b) after displaying the native dialogs.
>>
>> There are an amazing number of code paths here ..
>>
>> throw new RuntimeException(
>>                 "No 'MediaSize' was found for 'MediaSizeName.ISO_A5'.");
>> Why insist on A5 ? Any number of sizes should work ?
>> And making the test fail in such a case is plain wrong.
>>
>> Why    @requires (os.family == "mac")
>> since the test can run everywhere ? And it should pass everywhere too.
>> This should be fixed.
>>
>> The directory name in the test is gratuitous and unneeded and
>> the test name itself is ridiculously long.
>> Instead let's call it
>>
>> Regarding the fix itself I am unclear what the impact is in
>> the case the app supplies an attribute set that *does* have one or
>> more attributes that affect PageFormat.  It might well be that
>> these are applied already but I'd like assurance that has been verified.
>> Some of the code references below seem to be a bit munged by mail
>> so I can't work out what is being said.
>>
>> -phil.
>>
>>
>>
>> On 3/28/17, 5:55 AM, Anton Litvinov wrote:
>>> Hello Prasanta,
>>>
>>> The correct "PageFormat" for each separate page is retrieved in the 
>>> native function "PrinterView.m::rectForPage:(NSInteger)" by invoking 
>>> the Java method 
>>> "CPrinterJob.getPageformatPrintablePeekgraphics(int)" with the first 
>>> expression specified below and getting the value of "PageFormat" 
>>> from the returned array with the second expression specified below.
>>>
>>> "jobjectArray objectArray = JNFCallObjectMethod(env, fPrinterJob, 
>>> jm_getPageformatPrintablePeekgraphics, jPageNumber); // 
>>> AWT_THREADING Safe (AWTRunLoopMode)"
>>> "jobject pageFormat = (*env)->GetObjectArrayElement(env, 
>>> objectArray, 0);"
>>>
>>> But in that native method "PrinterView.m::rectForPage" only the page 
>>> orientation field "mOrientation" of the retrieved "PageFormat" for 
>>> each page is analyzed and is set to "NSPrintInfo" object through 
>>> "NSPrintOperation". Thus for some reason at that method analysis of 
>>> the paper size is ignored.
>>>
>>> So obviously not taking into account individual paper size of the 
>>> pages for the case, which you described, when the user's code 
>>> specifies different "PageFormat" instances for different pages of 
>>> the document, should take place in JDK, though I did not verify this 
>>> practically. But this issue existed before my fix and is not a 
>>> result of the fix.
>>>
>>> I do not see anything bad in the hard coded "0" page number used in 
>>> my fix, because we need to initialize "NSPrintInfo" with a valid 
>>> page size and the page size of the first page of the document is the 
>>> only correct or appropriate value for this moment, and because this 
>>> approach already exists in "RasterPrinterJob.java" as the next 
>>> expression.
>>>
>>> "PageFormat pf = (PageFormat)pageable.getPageFormat(0).clone();"
>>>
>>> From my point of view, the issue about disrespect of different paper 
>>> sizes for different pages of the document is the issue which is 
>>> different from the issue described in this bug (JDK-8167102) and 
>>> should be fixed separately from my bug, because:
>>> - In my bug "java.awt.print.Printable" interface is involved, while 
>>> in this new issue "java.awt.print.Pageable" interface is the 
>>> explicit requirement;
>>> - In my bug calling "PrinterJob.print(PrintRequestAttributeSet)" 
>>> with a non-empty "PrintRequestAttributeSet" is the obligatory and 
>>> the key requirement, while in the new issue this condition is 
>>> irrelevant.
>>> - For my bug one regression test is necessary, while for the new 
>>> issue the different regression test is necessary.
>>>
>>> Therefore I suggest to file a separate bug for the discovered issue 
>>> and to address it separately from this bug (JDK-8167102). Would you 
>>> agree with this suggestion? Would you approve the second version of 
>>> the fix for the bug JDK-8167102?
>>>
>>> Thank you,
>>> Anton
>>>
>>> On 3/28/2017 12:46 PM, Prasanta Sadhukhan wrote:
>>>>
>>>> Hi Anton,
>>>>
>>>>
>>>> On 3/27/2017 10:05 PM, Anton Litvinov wrote:
>>>>> Hello Prasanta,
>>>>>
>>>>> Indeed it is Mac specific, as it was written in my previous 
>>>>> e-mail, I verified this fact on Windows OS and Linux OS by your 
>>>>> request.
>>>>>
>>>>> Yes, I am fully sure that, when the bug occurs, the paper size of 
>>>>> the printed page is wrong, as it is stated in the bug, and I am 
>>>>> fully sure that with the applied any of 2 versions of the created 
>>>>> fix, the paper size of the printed page becomes correct and as 
>>>>> expected. Otherwise, I would not send the fix for review. The 
>>>>> instruction, by following which the bug can be reproduced, is 
>>>>> written in "STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :" section of 
>>>>> the description of the bug in JBS. This bug is raised by the user, 
>>>>> who owns a support contract and requests for resolution of this 
>>>>> bug, this can be seen in proper comments of the bug record.
>>>>>
>>>>> The automated regression test is not possible for this bug, since 
>>>>> it is necessary to verify visually that the document is physically 
>>>>> printed on the paper of the expected size. Otherwise, I would send 
>>>>> the 1st version of the fix with the automated test already, it is 
>>>>> not the first bug in JDK on which I have been working. By your 
>>>>> request the regression test, even though it is manual, was created 
>>>>> and added to the 2nd version of the fix.
>>>>>
>>>>> Yes, it is correct, the implemented by the test, and the test case 
>>>>> method "Printable.print(Graphics, PageFormat, int)" receives the 
>>>>> correct instance of "PageFormat" in runtime in scenario described 
>>>>> in this bug, because, as you already described, it is extracted 
>>>>> using the expression "pageable.getPageFormat(pageIndex)" in the 
>>>>> Java method 
>>>>> "sun.lwawt.macosx.CPrinterJob.getPageformatPrintablePeekgraphics(int)" 
>>>>> called from "PrinterView.m::rectForPage:(NSInteger)" and further 
>>>>> transferred in this method to the Java method 
>>>>> "sun.lwawt.macosx.CPrinterJob.printAndGetPageFormatArea".
>>>>>
>>>>> The wrong paper size which is returned from the method 
>>>>> "RasterPrinterJob.getPageFormatFromAttributes()" and which is set 
>>>>> to certain fields of the Objective-C  object "NSPrintInfo" in the 
>>>>> function "CPrinterJob.m::javaPaperToNSPrintInfo" through the next 
>>>>> call sequence
>>>>>
>>>>> CPrinterJob.m::printLoop() --> 
>>>>> CPrinterJob.m::javaPrinterJobToNSPrintInfo() --> 
>>>>> CPrinterJob.m::javaPageFormatToNSPrintInfo() --> 
>>>>> CPrinterJob.m::javaPaperToNSPrintInfo()
>>>>>
>>>>> further influences physical size of all pages printed by 1 printer 
>>>>> job.
>>>>>
>>>>> Thus, I consider that firstly "PageFormat" returned from 
>>>>> "RasterPrinterJob.getPageFormatFromAttributes()" is wrong, and 
>>>>> secondly setting paper size from this wrong "PageFormat" to proper 
>>>>> fields of "NSPrintInfo" object is also incorrect and is a root 
>>>>> cause of this bug.
>>>> OK. So, pageformat values set to native NSPrintInfo is different 
>>>> (wrong) compared to what is being passed to user.
>>>>>
>>>>> Implementation of Java Print Server API surely contains many 
>>>>> issues, and only working on this bug I already encountered 2 
>>>>> additional different issues, which are described in one of my 
>>>>> comments in this bug record in JBS. However, I prefer to resolve 
>>>>> issues separately and to resolve this particular bug also 
>>>>> separately from other issues which we can indefinitely find while 
>>>>> looking at the code and debugging it, also because it is necessary 
>>>>> to deliver the fix for this bug to "jdk8u-dev" repository finally, 
>>>>> while JDK 9 is currently in RDP 2 phase at which large fixes 
>>>>> affecting more platforms or large code scope would hardly be 
>>>>> accepted by Group and Area leads or the release team.
>>>>>
>>>>> I would like to bring also your attention again to the fact, which 
>>>>> was mentioned in my previous e-mail, that I already ran all manual 
>>>>> and automatic "jtreg" regression tests related to printing from 
>>>>> open and closed parts of JDK on JDK 9 without the fix and with the 
>>>>> fix, what is 198 tests.
>>>>>
>>>>> Do you find anything incorrect in the 2nd version of the fix? Will 
>>>>> you approve the 2nd version of the fix?
>>>>>
>>>> I think there might be a (probable) issue with this fix. PageFormat 
>>>> of 1st page only is used to get the information.
>>>> jobject page = JNFCallObjectMethod(env, srcPrinterJob, 
>>>> jm_getPageFormat, (jint)0);
>>>> What if user has set different pageformat to different page like 
>>>> this below? Will it not lose the 2nd page pageformat? I guess in 
>>>> windows/linux, we obtain pageformat for each pageindex
>>>>
>>>> PrinterJob job = PrinterJob.getPrinterJob();
>>>> // Create a landscape pageformat
>>>> PageFormat pfl = job.defaultPage();
>>>> pfl.setOrientation(PageFormat.LANDSCAPE);
>>>> //Setup a book
>>>> Book bk = new Book();
>>>> bk.append(new xPrintable(), pfl); // 1st page landscape , can be 
>>>> diff. pagesize too
>>>> bk.append(new xxPrintable(), job.defaultPage()); //2nd page portrait
>>>> job.setPageable(bk);
>>>>
>>>> Regards
>>>> Prasanta
>>>>> Thank you,
>>>>> Anton
>>>>>
>>>>> On 3/27/2017 9:52 AM, Prasanta Sadhukhan wrote:
>>>>>>
>>>>>> Hi Anton,
>>>>>>
>>>>>> Ok. So, it seems it mac specific. But, are you sure wrong page 
>>>>>> size is used in mac as is claimed in the bug?
>>>>>> I thought we could use automated regression test instead of 
>>>>>> manual by checking pageformat value in print() as compared to 
>>>>>> what user passes in setPrintable().
>>>>>>
>>>>>> Then, I see in print() method in testcase, the "PageFormat" 
>>>>>> argument passed has same values as it is passed in setPrintable() 
>>>>>> in main() even without your fix.
>>>>>>
>>>>>> If I reverse trace from print() method present in testcase, I see 
>>>>>> it is called from CPrinterJob.java#printAndGetPageFormatArea()
>>>>>> which is called from PrinterView.m#rectForPage. And before 
>>>>>> calling printAndGetPageFormatArea() it calls 
>>>>>> getPageformatPrintablePeekgraphics() which calls 
>>>>>> pageable.getPageFormat(pageIndex), so it should behave same as 
>>>>>> windows. Am I missing something?
>>>>>>
>>>>>> Regards
>>>>>> Prasanta
>>>>>> On 3/27/2017 3:32 AM, Anton Litvinov wrote:
>>>>>>> Hello Prasanta,
>>>>>>>
>>>>>>> I verified that the bug is not reproducible using JDK 9 compiled 
>>>>>>> from the latest version of "jdk9/client" forest neither on 
>>>>>>> Windows, nor on Linux platform, therefore, yes, this bug is only 
>>>>>>> Mac specific. Debugging showed that on Windows platform the 
>>>>>>> behavior is exactly like you described, on Windows 
>>>>>>> "RasterPrinterJob.print(PrintRequestAttributeSet)" method is 
>>>>>>> responsible for printing the documents and in this method 
>>>>>>> "RasterPrinterJob.printPage(Pageable, int)" is called for each 
>>>>>>> page separately, and in this "printPage" method "PageFormat" 
>>>>>>> instance used for printing of the page is extracted from the the 
>>>>>>> transferred as the method argument instance of "Pageable" by the 
>>>>>>> expression "origPage = document.getPageFormat(pageIndex);".
>>>>>>>
>>>>>>> The new version of the fix was created. Could you please review 
>>>>>>> the second version of the fix.
>>>>>>>
>>>>>>> Webrev (the 2nd version): 
>>>>>>> http://cr.openjdk.java.net/~alitvinov/8167102/jdk9/webrev.01
>>>>>>>
>>>>>>> In the second version of the fix:
>>>>>>> 1. Calling for "RasterPrinterJob.getPageFormatFromAttributes()" 
>>>>>>> was substituted for 
>>>>>>> "sun.lwawt.macosx.CPrinterJob.getPageFormat(int)" in the native 
>>>>>>> method "CPrinterJob.m#javaPrinterJobToNSPrintInfo".
>>>>>>> 2. The method "RasterPrinterJob.getPageFormatFromAttributes()" 
>>>>>>> was removed, since it is not called from any other code in "jdk" 
>>>>>>> repository.
>>>>>>> 3. The manual regression test was created.
>>>>>>>
>>>>>>> Also on OS X I executed all manual and automatic "jtreg" 
>>>>>>> regression tests related to printing from the listed below 
>>>>>>> directories and the corresponding directories in the closed 
>>>>>>> repositories using both JDK 9 compiled without and with the fix, 
>>>>>>> and I verified that no new test failed on JDK 9 with the fix.
>>>>>>>
>>>>>>> The directories with the regression tests from open repositories:
>>>>>>> - "jdk/test/java/awt/print"
>>>>>>> - "jdk/test/javax/print"
>>>>>>>
>>>>>>> Thank you,
>>>>>>> Anton
>>>>>>>
>>>>>>> On 3/22/2017 7:42 AM, Prasanta Sadhukhan wrote:
>>>>>>>>
>>>>>>>> Hi Anton,
>>>>>>>>
>>>>>>>> I thought about your point and have a question: does this issue 
>>>>>>>> not reproduce in non-mac platform?
>>>>>>>> I thought it probably would so suggested modifying 
>>>>>>>> setAttributes() . But, if it is only reproduced in mac, we need 
>>>>>>>> to find out why despite this setAttributes() flaw, how this is 
>>>>>>>> working in non-mac platform?
>>>>>>>>
>>>>>>>> It probably might work in windows/linux because in 
>>>>>>>> RasterPrinterJob.print(attr) method, after it calls 
>>>>>>>> setAttributes(), it calls printPage() where it gets the 
>>>>>>>> original PageFormat
>>>>>>>> by calling getPageFormat(pageIndex) and gets the orientation, 
>>>>>>>> imageablearea
>>>>>>>> and not by constructing pageFormat from attributes as it is 
>>>>>>>> done in mac.
>>>>>>>> So, probably, in mac also, we need to do away with 
>>>>>>>> getPageFormatFromAttributes() call  and call 
>>>>>>>> getPageFormat(pageIndex) from 
>>>>>>>> CPrinterJob.m#javaPrinterJobToNSPrintInfo().
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Prasanta
>>>>>>>> On 3/21/2017 8:15 PM, Anton Litvinov wrote:
>>>>>>>>> Hello Prasanta,
>>>>>>>>>
>>>>>>>>> Thank you for review of this fix. I have tried to apply the 
>>>>>>>>> approach which you suggested and it allowed to resolve the 
>>>>>>>>> issue. In this case I agree that it would be more correct to 
>>>>>>>>> resolve the issue in 
>>>>>>>>> "RasterPrinterJob.setAttributes(PrintRequestAttributeSet)" 
>>>>>>>>> method. In the first version of the fix I decided to change 
>>>>>>>>> the method "RasterPrinterJob.getPageFormatFromAttributes()", 
>>>>>>>>> because it is invoked only from 1 place in JDK code and this 
>>>>>>>>> place is located in OS X specific code 
>>>>>>>>> "jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m", 
>>>>>>>>> so that would automatically minimize the affected by the fix 
>>>>>>>>> platforms to OS X only.
>>>>>>>>>
>>>>>>>>> Starting to work on implementation of the second version of 
>>>>>>>>> the fix including the regression test.
>>>>>>>>>
>>>>>>>>> Thank you,
>>>>>>>>> Anton
>>>>>>>>>
>>>>>>>>> On 3/21/2017 12:52 PM, Prasanta Sadhukhan wrote:
>>>>>>>>>>
>>>>>>>>>> I think the real problem is not in 
>>>>>>>>>> RasterPrinterJob.getPageFormatFromAttributes().
>>>>>>>>>>
>>>>>>>>>> One can see that, when we call 
>>>>>>>>>> RasterPrinterJob.setPrintable(), we call 
>>>>>>>>>> updatePageAttributes() which in turn calls 
>>>>>>>>>> updateAttributesWithPageFormat() where orientation, media and 
>>>>>>>>>> mediaprintablearea "attributes" get populated/cached from the 
>>>>>>>>>> "pageformat" supplied by the user.
>>>>>>>>>>
>>>>>>>>>> But, when PrinterJob.print(PrintRequestAttributeSet) is 
>>>>>>>>>> called, it calls setAttributes(attributes) where "attributes" 
>>>>>>>>>> is what is populated by the user. It does not contain 
>>>>>>>>>> orientation,media and mediaprintablearea attributes for this 
>>>>>>>>>> bug, so setAttributes sets cached attribute with this 
>>>>>>>>>> user-set attribute instance
>>>>>>>>>> />>else {//
>>>>>>>>>> //>>            // for AWT where pageable is not an instance 
>>>>>>>>>> of OpenBook,//
>>>>>>>>>> //>>            // we need to save paper info//
>>>>>>>>>> // >>           this.attributes = attributes;//
>>>>>>>>>> // >>       }//
>>>>>>>>>> /
>>>>>>>>>>
>>>>>>>>>> //thereby losing the attributes it has cached earlier from 
>>>>>>>>>> user pageformat. I think we should check if this.attributes 
>>>>>>>>>> is not null, then retain those attributes unless explicitly 
>>>>>>>>>> set by the user in user-defined attributes.
>>>>>>>>>>
>>>>>>>>>> But, this code is used by windows,linux,mac so it needs to be 
>>>>>>>>>> tested against all those platforms to ensure we are not 
>>>>>>>>>> regressing anything.
>>>>>>>>>>
>>>>>>>>>> Also, I think user should call validatePage(PageFormat) in 
>>>>>>>>>> application to check if the settings passed is compatible 
>>>>>>>>>> with the printer or not, get compatible/adjusted pageformat 
>>>>>>>>>> and call setPrintable() with that "adjusted" pageformat. If 
>>>>>>>>>> user pass 0,0,fullpaperwidth,fullpaperheight as 
>>>>>>>>>> imageablearea, then he should not expect this setting to be 
>>>>>>>>>> used since printer will have its own hardware limitation (and 
>>>>>>>>>> use some offset printing)
>>>>>>>>>>
>>>>>>>>>> BTW, a regression testcase (even if it is manual) should be 
>>>>>>>>>> created with the fix.
>>>>>>>>>>
>>>>>>>>>> Regards
>>>>>>>>>> Prasanta
>>>>>>>>>> On 3/17/2017 10:59 PM, Anton Litvinov wrote:
>>>>>>>>>>> Hello,
>>>>>>>>>>>
>>>>>>>>>>> Could you please review the following fix for the bug.
>>>>>>>>>>>
>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8167102
>>>>>>>>>>> Webrev: 
>>>>>>>>>>> http://cr.openjdk.java.net/~alitvinov/8167102/jdk9/webrev.00
>>>>>>>>>>>
>>>>>>>>>>> The bug consists in the fact that, if the user's application 
>>>>>>>>>>> specifies the required page size (media size) through 
>>>>>>>>>>> "java.awt.print.PrinterJob" API particularly via 
>>>>>>>>>>> "java.awt.print.PageFormat" instance supplied to the method 
>>>>>>>>>>> "PrinterJob.setPrintable(Printable, PageFormat)" and calls 
>>>>>>>>>>> "PrinterJob.print(PrintRequestAttributeSet)" with 
>>>>>>>>>>> "javax.print.attribute.PrintRequestAttributeSet" containing 
>>>>>>>>>>> at least 1 any "PrintRequestAttribute", then the page or 
>>>>>>>>>>> pages will be printed with "PageFormat" describing the 
>>>>>>>>>>> default page size of the printer which is different from the 
>>>>>>>>>>> expected and originally set by the user's application 
>>>>>>>>>>> "PageFormat".
>>>>>>>>>>>
>>>>>>>>>>> Debugging showed that the new "PageFormat" with unexpected 
>>>>>>>>>>> media size is created in the method 
>>>>>>>>>>> "sun.print.RasterPrinterJob.getPageFormatFromAttributes()" 
>>>>>>>>>>> which is invoked from the native function 
>>>>>>>>>>> "jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m::javaPrinterJobToNSPrintInfo". 
>>>>>>>>>>> The method "RasterPrinterJob.getPageFormatFromAttributes()" 
>>>>>>>>>>> returns a new "PageFormat" always, if the provided by the 
>>>>>>>>>>> user "PrintRequestAttributeSet" is not empty, and the 
>>>>>>>>>>> default values are set to particular instance variables of 
>>>>>>>>>>> this "PageFormat", if "PrintRequestAttributeSet" does not 
>>>>>>>>>>> contain the searched "OrientationRequested", 
>>>>>>>>>>> "MediaSizeName", "MediaPrintableArea" attributes.
>>>>>>>>>>>
>>>>>>>>>>> THE SOLUTION:
>>>>>>>>>>> Although it is clearly stated in Java Platform SE 8 API 
>>>>>>>>>>> Specification (documentation of the method 
>>>>>>>>>>> "PrinterJob.print(PrintRequestAttributeSet)")
>>>>>>>>>>> Specification URL: 
>>>>>>>>>>> http://docs.oracle.com/javase/8/docs/api/java/awt/print/PrinterJob.html#print-javax.print.attribute.PrintRequestAttributeSet-
>>>>>>>>>>>
>>>>>>>>>>> that media size, orientation and imageable area attributes 
>>>>>>>>>>> specified in "PrintRequestAttributeSet" supplied to the 
>>>>>>>>>>> method "PrinterJob.print" will be used for construction of a 
>>>>>>>>>>> new "PageFormat", which will be passed to "Printable" 
>>>>>>>>>>> object, instead of the original "PageFormat" instance set 
>>>>>>>>>>> through "PrinterJob.setPrintable" method, the observed in 
>>>>>>>>>>> this issue behavior is a bug, because in the bug test case 
>>>>>>>>>>> neither media size, nor orientation, nor imageable area 
>>>>>>>>>>> attributes are specified in "PrintRequestAttributeSet".
>>>>>>>>>>>
>>>>>>>>>>> The fix alters the method 
>>>>>>>>>>> "sun.print.RasterPrinterJob.getPageFormatFromAttributes()" 
>>>>>>>>>>> to use corresponding values from "PageFormat" instance 
>>>>>>>>>>> originally set through "PrinterJob" API during construction 
>>>>>>>>>>> of the new "PageFormat", when it is found out that 
>>>>>>>>>>> "OrientationRequested", or "MediaSizeName", or 
>>>>>>>>>>> "MediaPrintableArea" attribute is not specified in 
>>>>>>>>>>> "PrintRequestAttributeSet" supplied to "PrinterJob.print" 
>>>>>>>>>>> method.
>>>>>>>>>>>
>>>>>>>>>>> Thank you,
>>>>>>>>>>> Anton
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20170330/fc39ca7d/attachment.html>

From james.graham at oracle.com  Thu Mar 30 22:25:19 2017
From: james.graham at oracle.com (Jim Graham)
Date: Thu, 30 Mar 2017 15:25:19 -0700
Subject: [OpenJDK 2D-Dev] Review request for 8029339 Custom
 MultiResolution image support on HiDPI displays
In-Reply-To: <F19C7C5F-04CA-4721-9BD5-E98DD775F615@oracle.com>
References: <54C10E06.6090407@oracle.com> <54DE956C.9040105@oracle.com>
 <5502E763.7080008@oracle.com> <55147EBE.3010002@oracle.com>
 <551BF6AC.8000705@oracle.com> <5523AB20.30704@oracle.com>
 <552E7006.70101@oracle.com> <55A44B62.7070703@oracle.com>
 <F19C7C5F-04CA-4721-9BD5-E98DD775F615@oracle.com>
Message-ID: <d76d9820-2f82-5eb0-77dd-43fec7123a60@oracle.com>

That sounds useful, but is your example code complete?  Don't you need to declare the "image" variable with the 
appropriate generic type?

Also, do we get a lot of compiler warnings if you want to ignore the generics in other code?  What's the pain point if 
you don't care what the types of the images are?  (I suppose the most common case is that people have an "Image" without 
even realizing that it is an MRI in the first place so this is only for those who want to manipulate MRIs)...

			...jim

On 3/29/17 1:22 PM, Sergey Bylokhov wrote:
> Hi, Jim, Phil.
> I have started to use MRI and a new Robot in some of the tests and wonder why the MultiResolutionImage does not use
> generics for getResolutionVariants()?
>
> So for example if we have an API like:
> http://download.java.net/java/jdk9/docs/api/java/awt/Robot.html#createMultiResolutionScreenCapture-java.awt.Rectangle-
> We cannot specify that the MRI contains BufferedImage(not just an image). So the users will need to check it via
> instance of and cast.
> So in the worse case the user will get something like this:
>
> =====
> Test.java
>             MultiResolutionImage image =
>                     robot.createMultiResolutionScreenCapture(rect);
>             List<Image> resolutionVariants = image.getResolutionVariants();
>
>             if (resolutionVariants.size() > 1) {
>                 Image tmp = resolutionVariants.get(1);
>                 if (tmp instanceof BufferedImage) {
>                     capture = (BufferedImage) tmp;
>                 }
>             } else {
>                 Image tmp = resolutionVariants.get(0);
>                 if (tmp instanceof BufferedImage) {
>                     capture = (BufferedImage) tmp;
>                 }
>             }
> =====
>
> I am not sure but for writing the tests, I feel something like this will be simpler:
> =====
> Robot.java
>     public synchronized MultiResolutionImage<BufferedImage>
>             createMultiResolutionScreenCapture(Rectangle screenRect) {
> //
> Test.java
>             MultiResolutionImage image =
>                     robot.createMultiResolutionScreenCapture(rect);
>             List<BufferedImage> resolutionVariants = image.getResolutionVariants();
>
>             if (resolutionVariants.size() > 1) {
>                     capture = resolutionVariants.get(1);
>             } else {
>                     capture = resolutionVariants.get(0);
>             }
> =====
> Or even this:
> capture = robot.createCompatibleScreenCapture(rect);
>
>
>
>>
>> Hi Alexandr,
>>
>> Sorry that this fell into the cracks.  Here are some fairly minor updates:
>>
>> AbstractMRI - getGraphics() should include "getGraphics() not supported on Multi-Resolution Images" as the exception
>> description text.
>>
>> AbstractMRI - getBaseImage() should have doc comments:
>> /**
>> * Return the base image representing the best version of the image
>> * for rendering at the default width and height.
>> * @return the base image of the set of multi-resolution images
>> */
>> (Does it need an @since given that the entire interface is @since 1.9?)
>>
>> BaseMRI - the doc comments (both the class comment and the constructor comments) don't start with "/**" so they aren't
>> really doc comments, but they look good so make them so.
>>
>> BaseMRI - class comment - "The implementation will return the first ... satisfy the rendering request."  Add another
>> sentence right there "The last image in the array will be returned if no suitable image is found that is larger than
>> the rendering request."
>>
>> BaseMRI - move "For best effect ..." should be moved to a new paragraph and mention that no exception will be thrown
>> if the images are not sorted as suggested.
>>
>> RenderingHints - comments:
>> DEFAULT, SIZE_FIT, DPI_FIT - "an image resolution variant is chosen ..." (add "an")
>> DEFAULT - "... which may depend on the policies of the platform"
>> SIZE_FIT, DPI_FIT "... on the DPI of ..." (add "the")
>>
>> SunHints - descriptor texts:
>> SIZE_FIT, DPI_FIT "based on the DPI" (add "the")
>>
>> MRCachedImage - remind me what this is used for?
>> MRCachedImage.getResolutionVariant - use ceil or round instead of (int) cast?  ceil() would match the actions of
>> MRToolkitImage better.  Also note following comment about precision with SG2D.
>>
>> SG2D/MRI - the interface declares the values as float, the usage in SG2D computes values in double and then truncates
>> them to int to pass to the interface - should we upgrade the interface to double for completeness?  If not, then the
>> usage in SG2D should at least pass in float precision.
>>
>> SG2D.getResolutionVariant - using destRegionWH to calculate destImageWH can involve a lot of "do some math and then
>> later have additional code undo it".  Would it be faster to just compute destImageWH directly, as in:
>>
>> float destImageWidth, destImageHeight;
>>
>> if (BASE) {
>>    destImageWH = srcWH;
>> } else if (DPI) {
>>    destImageWH = (float) abs(srcWH * devScale);
>> } else {
>>    double destRegionWidth, destRegionHeight;
>>    if (type) {
>>    ...
>>    }
>>    destImageWH = (float) abs(srcWH * destRegionWH / swh);
>> }
>> Image rv = img.getRV(destImageWH);
>>
>> On the other hand, the last "else" is probably the most common case so this doesn't save anything in the common case,
>> but it avoids a bunch of math that could introduce rounding error for the BASE/DPI cases (even though it is done in
>> doubles).
>>
>> Is there intent to have the default case be mapped to DPI_FIT for Windows?
>>
>> MultiResolutionRenderinHints.java - should have "Test" appended to the name
>>
>> MRRHTest - why not render to a BufferedImage and avoid Robot?  Could it tap into internal APIs to create a
>> BImg/compatibleImage with a given devScale?
>>
>> MRRHTest - why allow up to delta=50 on the comparison?
>>
>> MRRHTest - since the scale factor comes from a dialog, we depend on running this on a HiDPI display to fully test the
>> hints?  Could using "scaled compatible images" allow testing this more definitively?
>>
>> MRRHTest - remove println before pushing?
>>
>> MRRHTest - probably shouldn't have a "right answer" for DEFAULT - it should probably just pass if the operation
>> doesn't throw an exception?
>>
>> ...jim
>>
>>
>> On 4/15/15 7:04 AM, Alexander Scherbatiy wrote:
>>>
>>>   Hello,
>>>
>>>  Could you review the updated fix:
>>>    http://cr.openjdk.java.net/~alexsch/8029339/webrev.08/
>>>
>>>  - SunGraphics2D is updated to calculate the resolution variant size
>>> according to the _BASE, _DPI_FIT, and _SIZE_FIT resolution rendering hint
>>>  - MultiResolutionRenderingHints test is added
>>>
>>>  Thanks,
>>>  Alexandr.
>>>
>>>
>>> On 4/7/2015 1:02 PM, Jim Graham wrote:
>>>> This is an interesting suggestion that would let us keep the
>>>> implementation of the various hints centralized and simplify the
>>>> interface to the part of the mechanism that is most tied in to the
>>>> implementation specifics of the database of media variants - which is
>>>> housed in the MRI-implementing object.
>>>>
>>>> I'm not sure we ever identified any need to customize the logic of
>>>> "what size is needed for this render operation" beyond what we
>>>> expressed in the hints, and given that the platform defaults may not
>>>> be easy to express to an arbitrary implementation, it is probably
>>>> better to put that part of the logic in SG2D, controlled by the easy
>>>> to express hints and keep the current API both simple to implement and
>>>> flexible to use.  Even if there was a need to customize that part of
>>>> the operation (the "what size is relevant to this rendering operation"
>>>> decision) beyond what the hints suggest, it would be inappropriate to
>>>> tie that in to the "find me media" aspect of the MRI interface
>>>> anyway.  So, best to keep them separate and have the hints affect what
>>>> SG2D does and have the MRI focused on just storing (possibly creating)
>>>> and managing/finding the variants.
>>>>
>>>>            ...jim
>>>>
>>>> On 4/1/15 6:46 AM, Alexander Scherbatiy wrote:
>>>>> On 3/27/2015 12:48 AM, Jim Graham wrote:
>>>>>> Hi Alexander,
>>>>>
>>>>>   http://cr.openjdk.java.net/~alexsch/8029339/webrev.07/
>>>>>   I have updated the fix according to the comments except
>>>>> RenderingHints.
>>>>>
>>>>>   RenderingHints are supposed to be set on Graphics2D and they have
>>>>> keys/values which are not relevant to the getResolutionVariant() method.
>>>>>   Graphics objects chooses an alternative according to the set
>>>>> rendering hints.
>>>>>   May be what SG2D should do just calculate dest image size for the
>>>>> given resolution variant hint (_BASE - base image size, _SIZE_FIT -
>>>>> including scale factor and graphics transform (Mac algorithm),
>>>>> _DPI_FIT - scaled according to the system DPI) and then pass them to
>>>>> the getResolutionVariant() method?
>>>>>
>>>>>  Thanks,
>>>>>  Alexandr.
>>>>>
>>>>>>
>>>>>> MRI.java:
>>>>>>
>>>>>> Who is the intended audience for the recommendation in the interface
>>>>>> to cache image variants?  Are we asking the developers who call the
>>>>>> methods on the interface to cache the answers? That would be unwise
>>>>>> because the list of variants may change over time for some MRIs. Are
>>>>>> we speaking to the implementer? If so, then I think that it is
>>>>>> unnecessary to remind implementers of basic implementation
>>>>>> strategies like "cache complicated objects".
>>>>>>
>>>>>> How about this wording for the getRV() method? - "Gets a specific
>>>>>> image that is the best variant to represent this logical image at
>>>>>> the indicated size and screen resolution."
>>>>>>
>>>>>> Perhaps we should clarify in the doc comments for the dimension
>>>>>> arguments in getRV() that the dimensions are measured in pixels?
>>>>>>
>>>>>> line 56 - delete blank line between doc comment and method declaration
>>>>>>
>>>>>> Also, it is probably overkill to document that the interface
>>>>>> getVariants() method returns an unmodifiable list. Responsible
>>>>>> implementations would probably use an unmodifiable list, but I don't
>>>>>> think it should be required by the interface.  We do need to specify
>>>>>> that it isn't required to be modifiable so that a caller doesn't
>>>>>> expect to be able to modify it, but that is a looser spec.  How
>>>>>> about "Gets a readable list of all resolution variants.  Note that
>>>>>> many implementations might return an unmodifiable list."?
>>>>>>
>>>>>> AbstractMIR.java:
>>>>>>
>>>>>> "provides a default implementation for the MRI" or "provides default
>>>>>> implementations of several methods in the <MRI> interface and the
>>>>>> <Image> class"?  Actually, I'll note that it provides none of the
>>>>>> implementations of the MRI methods so maybe it should be "provides
>>>>>> default implementations of several <Image> methods for classes that
>>>>>> want to implement the <MRI> interface"?
>>>>>>
>>>>>> In the doc example - wrap the list to make it unmodifiable
>>>>>>
>>>>>> The doc example could be made 2 or 3 lines shorter by simply
>>>>>> assuming the base image is in index 0 (it's just an example so I'm
>>>>>> not sure the flexibility needs to be a part of the example).
>>>>>>
>>>>>> getGraphics is allowed by the Image interface to return null.
>>>>>> Actually, the exact wording is that it can only be called for
>>>>>> "offscreen images" and a MRI is technically not "an offscreen
>>>>>> image".  Perhaps we should return null here since modifying the base
>>>>>> image is unlikely to modify the variants and arguably it would be
>>>>>> required by the wording in the method docs (even if the base image
>>>>>> was an offscreen, the MRI produced from it stops being an offscreen)?
>>>>>>
>>>>>> Are all of the empty "@Inherit" comments needed?  I thought
>>>>>> inheritance was the default?
>>>>>>
>>>>>> BaseMRI.java:
>>>>>>
>>>>>> "This class is [an] array-based implementation of the {AMRI} class"
>>>>>> (missing "an" and "the")
>>>>>>
>>>>>> We should probably include the comment about the sorting of the
>>>>>> images in the class comments as well as document that the algorithm
>>>>>> is a simple scan from the beginning for the first image large enough
>>>>>> (and default == last image).  The algorithm also might not work very
>>>>>> well if the images are not monotonically both wider and taller.  How
>>>>>> about adding this to the class comments:
>>>>>>
>>>>>> "The implementation will return the first image variant in the array
>>>>>> that is large enough to satisfy the rendering request. For best
>>>>>> effect the array of images should be sorted with each image being
>>>>>> both wider and taller than the previous image. The base image need
>>>>>> not be the first image in the array."
>>>>>>
>>>>>> getVariants() - you need to return an unmodifiable list. asList()
>>>>>> returns a list that "writes back" to the array.  You need to use
>>>>>> Collections.unmodifiableList(Arrays.asList(array)).
>>>>>>
>>>>>> RenderingHints.java:
>>>>>>
>>>>>> Where do we process this hint?  Don't we need to pass it to the
>>>>>> getVariant() method?
>>>>>>
>>>>>> I don't understand the hint values other than the one that always
>>>>>> uses the base image.  Default I guess gives us the ability to use
>>>>>> the Mac algorithm of "next larger size" on Mac and "based on Screen
>>>>>> DPI" on Windows, but the 3rd value "ON" is so vague as to not have
>>>>>> any meaning.  Perhaps we should just delete it, but then do we just
>>>>>> always do the Mac method? Or do we vaguely have our internal images
>>>>>> have a platform-specific method and the Abstract/Base classes just
>>>>>> do what they want with no control from the user?  In FX we are also
>>>>>> still struggling with this issue and we may likely just do what the
>>>>>> Mac does in all cases, but perhaps AWT needs to "behave like the
>>>>>> platform" more?  If we are going to have actual values, then we need
>>>>>> to have them do something, which means:
>>>>>>
>>>>>> - SG2D needs to track the hint just like we do the other hints that
>>>>>> affect our processing
>>>>>> - MRI.getVariant() needs to have the hint as an argument
>>>>>> - BaseMRI should probably do something with that hint
>>>>>> - hint values should include:
>>>>>>    - ..._DEFAULT - implementation gets to decide
>>>>>>    - ..._BASE - always use the base image
>>>>>>    - ..._SIZE_FIT - Mac algorithm of smallest image that is big enough
>>>>>>    - ..._DPI_FIT - choose based on DPI of the screen, ignoring
>>>>>> transform
>>>>>>
>>>>>> line 978 - missing blank line between fields
>>>>>>
>>>>>> SG2D.java:
>>>>>>
>>>>>> - The interface says that you will be passing in the "logical DPI"
>>>>>> of the display, but here you are actually passing in the screen's
>>>>>> scale factor.
>>>>>>
>>>>>> BaseMRITest.java:
>>>>>>
>>>>>> - testBaseMRI also passes in a scale rather than a DPI to the MRI
>>>>>> method.
>>>>>>
>>>>>> - How does the modification test pass when the implementation
>>>>>> doesn't use unmodifiable lists?
>>>>>>
>>>>>> MRITest.java:
>>>>>>
>>>>>> - also uses scale rather than DPI in several places
>>>>>>
>>>>>>        ...jim
>>>>>>
>>>>>> On 3/13/15 6:34 AM, Alexander Scherbatiy wrote:
>>>>>>>
>>>>>>>   Hello,
>>>>>>>
>>>>>>>   Could you review the proposed API based on MultiresolutionImage
>>>>>>> interface:
>>>>>>>     http://cr.openjdk.java.net/~alexsch/8029339/webrev.06/
>>>>>>>
>>>>>>>  - return unmodifiable list comment is added to the
>>>>>>> getResolutionVariants() method javadoc in MultiresolutionImage
>>>>>>> interface
>>>>>>>  - base image size arguments are removed form the
>>>>>>> getResolutionVariant(...) method in MultiresolutionImage interface
>>>>>>>  - BaseMultiResolutionImage class that allows to create a
>>>>>>> multi-resolution image based on resolution variant array is added
>>>>>>>  - the test for the BaseMultiResolutionImage is added
>>>>>>>
>>>>>>>  Thanks,
>>>>>>>  Alexandr.
>>>>>>>
>>>>>>> On 2/14/2015 3:23 AM, Jim Graham wrote:
>>>>>>>> The second solution looks good.  I'd make it standard practice
>>>>>>>> (perhaps even mentioned in the documentation) to return unmodifiable
>>>>>>>> lists from the getVariants() method.  The Collections class provides
>>>>>>>> easy methods to create these lists, and it sends a clear message to
>>>>>>>> the caller that the list was provided for them to read, but not write
>>>>>>>> to.  Otherwise they may add a new image to the list you provided them
>>>>>>>> and wonder why it wasn't showing up.  Also, an unmodifiable list can
>>>>>>>> be cached and reused for subsequent calls without having to create a
>>>>>>>> new list every time.
>>>>>>>>
>>>>>>>> In getResolutionVariant() was there a reason why the base dimensions
>>>>>>>> were provided as float?  The destination dimensions make sense as
>>>>>>>> float since they could be the result of a scale, but the source
>>>>>>>> dimensions are typically getWidth/getHeight() on the base image.  A
>>>>>>>> related question would be if they are needed at all, since the
>>>>>>>> implementation should probably already be aware of what the base
>>>>>>>> image
>>>>>>>> is and what its dimensions are.  I'm guessing they are provided
>>>>>>>> because the implementation in SG2D already knows them and it makes it
>>>>>>>> easier to forward the implementation on to a shared (static?) method?
>>>>>>>>
>>>>>>>> With respect to default implementations, I take it that the
>>>>>>>> BaseMRI is
>>>>>>>> along the pattern that we see in Swing for Base classes. Would it be
>>>>>>>> helpful to provide an implementation (in addition or instead) that
>>>>>>>> allows a developer to take a bunch of images and quickly make an MRI
>>>>>>>> without having to override anything?  The implementations of
>>>>>>>> getBaseImage() and getResolutionVariants() are pretty straightforward
>>>>>>>> and a fairly reasonable default algorithm can be provided for
>>>>>>>> getRV(dimensions).  This question is more of an idle question for my
>>>>>>>> own curiosity than a stumbling block...
>>>>>>>>
>>>>>>>>            ...jim
>>>>>>>>
>>>>>>>> On 1/22/2015 6:49 AM, Alexander Scherbatiy wrote:
>>>>>>>>>
>>>>>>>>>   Hi Phil,
>>>>>>>>>
>>>>>>>>>   I have prepared two versions of the proposed API:
>>>>>>>>>
>>>>>>>>>   I) Resolution variants are added directly to the Image:
>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8029339/list/webrev.00
>>>>>>>>>
>>>>>>>>>   II)  MultiResolutionImage interface is used:
>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8029339/webrev.05
>>>>>>>>>
>>>>>>>>>   It could help to decide which way should be chosen for the the
>>>>>>>>> multi-resolution image support.
>>>>>>>>>
>>>>>>>>>   Below are some comments:
>>>>>>>>>
>>>>>>>>>   1. High level goal:
>>>>>>>>>      Introduce an API that allows to create and handle an image
>>>>>>>>> with
>>>>>>>>> resolution variants.
>>>>>>>>>
>>>>>>>>>   2. What is not subject of the provided API
>>>>>>>>>     - Scale naming convention for high-resolution images
>>>>>>>>>     - Providing pixel scale factor for the screen/window
>>>>>>>>>
>>>>>>>>>   3. Use cases
>>>>>>>>>    3.1 Loading and drawing high-resolution icons in IntelliJ IDEA
>>>>>>>>>      A high-resolution image is loaded from resources and stored in
>>>>>>>>> JBHiDPIScaledImage class  which is a subclass of the buffered image.
>>>>>>>>>      The high-resolution image is used to create a disabled icon
>>>>>>>>> in the
>>>>>>>>> IconLoader.getDisabledIcon(icon) method.
>>>>>>>>> https://github.com/JetBrains/intellij-community/blob/master/platform/util/src/com/intellij/openapi/util/IconLoader.java
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>    3.2 Loading and drawing high-resolution icons in NetBeans
>>>>>>>>>      NetBeans does not have support for the high-resolution icons
>>>>>>>>> loading.
>>>>>>>>>      It loads an icon from the file system using
>>>>>>>>> Toolkit.getDefaultToolkit().getImage(url) method or from resources
>>>>>>>>>      by  ImageReader  and store it in ToolTipImage class which is
>>>>>>>>> subclass of the buffered image.
>>>>>>>>>      ImageUtilities.createDisabledIcon(icon) method creates a
>>>>>>>>> disabled
>>>>>>>>> icon by applying  RGBImageFilter to the icon.
>>>>>>>>> http://hg.netbeans.org/main/file/97dcf49eb4a7/openide.util/src/org/openide/util/ImageUtilities.java
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>    3.3 Loading system icons in JDK 1.8
>>>>>>>>>      JDK requests icons from the native system for system L&Fs and
>>>>>>>>> applies filters for them.
>>>>>>>>>      See for example AquaUtils.generateLightenedImage() method:
>>>>>>>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/e6f48c4fad38/src/java.desktop/macosx/classes/com/apple/laf/AquaUtils.java
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>   4. HiDPI support for Images on different OSes
>>>>>>>>>
>>>>>>>>>     4.1 Mac OS X
>>>>>>>>>       Cocoa API contains NSImage that allows to work with image
>>>>>>>>> representations: add/remove/get all representations.
>>>>>>>>>       It picks up an image with necessary resolution based on the
>>>>>>>>> screen backing store pixel scale factor and applied transforms.
>>>>>>>>> https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSImage_Class/Reference/Reference.html
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>     4.2 Linux
>>>>>>>>>       GTK+ 3 API has gtkcssimagescaled lib (it seems that it is not
>>>>>>>>> public/stable)
>>>>>>>>>       that parses the -gtk-scaled css property and draws a
>>>>>>>>> GtkCssImage
>>>>>>>>> according to the given scale factor.
>>>>>>>>>
>>>>>>>>>       I have not found information about the HiDPI support in Xlib.
>>>>>>>>>
>>>>>>>>>     4.3 Windows
>>>>>>>>>       I have only found the tutorial that suggests to select and
>>>>>>>>> draw a
>>>>>>>>> bitmap using the queried DPI
>>>>>>>>>       and scale the coordinates for drawing a rectangular frame
>>>>>>>>> http://msdn.microsoft.com/en-us/library/dd464659%28v=vs.85%29.aspx
>>>>>>>>>
>>>>>>>>>       Windows also provides the horizontal and vertical DPI of the
>>>>>>>>> desktop
>>>>>>>>> http://msdn.microsoft.com/en-us/library/windows/apps/dd371316
>>>>>>>>>
>>>>>>>>>   5. Pseudo API
>>>>>>>>>      Below are some ways which illustrates how multi-resolution
>>>>>>>>> images
>>>>>>>>> can be created and used.
>>>>>>>>>
>>>>>>>>>     5.1 Resolution variants are stored directly in Image class.
>>>>>>>>>     To query a resolution variant it needs to compare the
>>>>>>>>> resolution
>>>>>>>>> variant width/height
>>>>>>>>>     with the requested high-resolution size.
>>>>>>>>>     ------------
>>>>>>>>>     public abstract class Image {
>>>>>>>>>
>>>>>>>>>         public void addResolutionVariant(Image image) {...}
>>>>>>>>>         public List<Image> getResolutionVariants() {...}
>>>>>>>>>     }
>>>>>>>>>     ------------
>>>>>>>>>     // create a disabled image with resolution variants
>>>>>>>>>
>>>>>>>>>     Image disabledImage = getDisabledImage(image);
>>>>>>>>>
>>>>>>>>>     for (Image rv : image.getResolutionVariants()) {
>>>>>>>>> disabledImage.addResolutionVariant(getDisabledImage(rv));
>>>>>>>>>     }
>>>>>>>>>     ------------
>>>>>>>>>     This approach requires that all resolution variants have been
>>>>>>>>> created even not of them are really used.
>>>>>>>>>
>>>>>>>>>     5.2  Resolution variants are stored in a separate object that
>>>>>>>>> allows to create them by demand.
>>>>>>>>>     To query a resolution variant it needs to compare the
>>>>>>>>> resolution
>>>>>>>>> variant scale factor
>>>>>>>>>     with the requested scale (that can include both screen DPI
>>>>>>>>> scale
>>>>>>>>> and applied transforms).
>>>>>>>>>     ------------
>>>>>>>>>     public abstract class Image {
>>>>>>>>>
>>>>>>>>>         public static interface ResolutionVariant {
>>>>>>>>>             Image getImage();
>>>>>>>>>             float getScaleFactor();
>>>>>>>>>         }
>>>>>>>>>
>>>>>>>>>         public void addResolutionVariant(ResolutionVariant
>>>>>>>>> resolutionVariant) {...}
>>>>>>>>>         public List<ResolutionVariant> getResolutionVariants()
>>>>>>>>> {...}
>>>>>>>>>     }
>>>>>>>>>     ------------
>>>>>>>>>     // create a disabled image with resolution variants
>>>>>>>>>     Image disabledImage = getDisabledImage(image);
>>>>>>>>>
>>>>>>>>>     for (Image.ResolutionVariant rv :
>>>>>>>>> image.getResolutionVariants()) {
>>>>>>>>>         disabledImage.addResolutionVariant(new
>>>>>>>>> Image.ResolutionVariant() {
>>>>>>>>>
>>>>>>>>>             public Image getImage() {
>>>>>>>>>                 return getDisabledImage(rv.getImage());
>>>>>>>>>             }
>>>>>>>>>
>>>>>>>>>             public float getScaleFactor() {
>>>>>>>>>                 return rv.getScaleFactor();
>>>>>>>>>             }
>>>>>>>>>         });
>>>>>>>>>     }
>>>>>>>>>     ------------
>>>>>>>>>
>>>>>>>>>     It does not have problem if a predefined set of images is
>>>>>>>>> provided
>>>>>>>>> (like image.png and image at 2x.png on the file system).
>>>>>>>>>     This does not cover cases where a resolution variant can be
>>>>>>>>> created
>>>>>>>>> using the exact requested size (like loading icons from the native
>>>>>>>>> system).
>>>>>>>>>     A resolution variant can be queried based on a scale factor and
>>>>>>>>> applied transforms.
>>>>>>>>>
>>>>>>>>>     5.3 The provided example allows to create a resolution variant
>>>>>>>>> using the requested high-resolution image size.
>>>>>>>>>     ------------
>>>>>>>>>     public interface MultiResolutionImage {
>>>>>>>>>         Image getResolutionVariant(float width, float height);
>>>>>>>>>     }
>>>>>>>>>     ------------
>>>>>>>>>     // create a multi-resolution image
>>>>>>>>>     Image mrImage = new AbstractMultiResolutionImage() {
>>>>>>>>>
>>>>>>>>>             public Image getResolutionVariant(float width, float
>>>>>>>>> height) {
>>>>>>>>>                 // create and return a resolution variant with
>>>>>>>>> exact
>>>>>>>>> requested width/height size
>>>>>>>>>             }
>>>>>>>>>
>>>>>>>>>             protected Image getBaseImage() {
>>>>>>>>>                 return baseImage;
>>>>>>>>>             }
>>>>>>>>>         };
>>>>>>>>>     ------------
>>>>>>>>>     // create a disabled image with resolution variants
>>>>>>>>>     Image disabledImage = null;
>>>>>>>>>     if (image instanceof MultiResolutionImage) {
>>>>>>>>>         final MultiResolutionImage mrImage = (MultiResolutionImage)
>>>>>>>>> image;
>>>>>>>>>         disabledImage = new AbstractMultiResolutionImage(){
>>>>>>>>>
>>>>>>>>>             public Image getResolutionVariant(float width, float
>>>>>>>>> height) {
>>>>>>>>>                 return
>>>>>>>>> getDisabledImage(mrImage.getResolutionVariant(width, height));
>>>>>>>>>             }
>>>>>>>>>
>>>>>>>>>             protected Image getBaseImage() {
>>>>>>>>>                 return getDisabledImage(mrImage);
>>>>>>>>>             }
>>>>>>>>>         };
>>>>>>>>>     } else {
>>>>>>>>>         disabledImage = getDisabledImage(image);
>>>>>>>>>     }
>>>>>>>>>     ------------
>>>>>>>>>
>>>>>>>>>   Thanks,
>>>>>>>>>   Alexandr.
>>>>>>>
>>>>>
>>>>
>>>
>