I pushed with that small test change :
For the record: http://cr.openjdk.java.net/~prr/8240342.1/
-phil
On 4/1/20, 1:37 AM, Prasanta Sadhukhan wrote:
Looks good to me too. Only minor nit is, probably in testcase, we can
shift the BufferedImage creation code after the print service is found
Looks good to me too. Only minor nit is, probably in testcase, we can
shift the BufferedImage creation code after the print service is found
Regards
Prasanta
On 01-Apr-20 7:37 AM, Sergey Bylokhov wrote:
On 3/31/20 5:42 pm, Philip Race wrote:
On 3/31/20 1:37 pm, Philip Race wrote:
The fix is
On 3/31/20 5:42 pm, Philip Race wrote:
On 3/31/20 1:37 pm, Philip Race wrote:
The fix is in code used on Linux/Solaris and Windows only.
The Mac printing path is quite different and was not affected.
So are you misunderstanding my comment ?
Yep, reading your comment I assumed that the code
On 3/31/20, 4:57 PM, Sergey Bylokhov wrote:
Hi, Phil.
Why the "AlphaComposite.SRC_OVER" is counted as "non-compositing" mode?
This is copied from share/classes/sun/print/PeekMetrics.java.
It means that the normal drawing path can handle it.
1904 if (alpha != 1.0
1905
Hi, Phil.
Why the "AlphaComposite.SRC_OVER" is counted as "non-compositing" mode?
1904 if (alpha != 1.0
1905 || (rule != AlphaComposite.SRC
1906 && rule != AlphaComposite.SRC_OVER))
1907 {
1908 isCompositing =
bug: https://bugs.openjdk.java.net/browse/JDK-8240342
webrev : http://cr.openjdk.java.net/~prr/8240342/
The code that determines if we could print an image via platform APIs
was not checking for custom composites.
The fix is in code used on Linux/Solaris and Windows only.
The Mac printing path
