date:20160817

Re: [OpenJDK 2D-Dev] [9] RFR JDK-6357887: selected printertray is ignored under linux

2016-08-17 Thread Prasanta Sadhukhan




On 8/18/2016 12:11 PM, Prasanta Sadhukhan wrote:
MediaTray values are bundled with "Media" attribute so calling 
attributes.get(CustomMediatray.class) returns null.
Modified webrev to get Media attribute and then see if the attribute 
is an instance of CustomMediatray.


http://cr.openjdk.java.net/~psadhukhan/6357887/webrev.01/


Also,removed some unused imports.

Regards
Prasanta
On 8/17/2016 9:09 PM, Philip Race wrote:

This all looks fine although this can be a simple call to
attributes.get(CustomMediaTray.class) can't it ?

502 for (int i=0; i< attrs.length; i++) {
 503 Attribute attr = attrs[i];
 504 try {
 505 if (attr instanceof CustomMediaTray) {
 506 CustomMediaTray customTray = 
(CustomMediaTray)attr;
 507 mOptions = " InputSlot="+ 
customTray.getChoiceName();

 508 }
 509 } catch (ClassCastException e) {

-phil.

On 8/10/16, 1:59 AM, Prasanta Sadhukhan wrote:

Hi All,

Please review a fix for an issue where it is seen that the selected 
printer tray is ignored in linux and default standard tray is used 
for printing.


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

Issue was lpr command needs "-o InputSlot=" to select the 
printertray which was not being passed to lpr command.
Proposed fix added InputSlot option to lpr command to select the 
printertray.


Tested in ubuntu and solaris11.

Regards
Prasanta

Re: [OpenJDK 2D-Dev] [9] RFR JDK-6357887: selected printertray is ignored under linux

2016-08-17 Thread Prasanta Sadhukhan

MediaTray values are bundled with "Media" attribute so calling 
attributes.get(CustomMediatray.class) returns null.
Modified webrev to get Media attribute and then see if the attribute is 
an instance of CustomMediatray.


http://cr.openjdk.java.net/~psadhukhan/6357887/webrev.01/

Regards
Prasanta
On 8/17/2016 9:09 PM, Philip Race wrote:

This all looks fine although this can be a simple call to
attributes.get(CustomMediaTray.class) can't it ?

502 for (int i=0; i< attrs.length; i++) {
 503 Attribute attr = attrs[i];
 504 try {
 505 if (attr instanceof CustomMediaTray) {
 506 CustomMediaTray customTray = 
(CustomMediaTray)attr;
 507 mOptions = " InputSlot="+ 
customTray.getChoiceName();

 508 }
 509 } catch (ClassCastException e) {

-phil.

On 8/10/16, 1:59 AM, Prasanta Sadhukhan wrote:

Hi All,

Please review a fix for an issue where it is seen that the selected 
printer tray is ignored in linux and default standard tray is used 
for printing.


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

Issue was lpr command needs "-o InputSlot=" to select the 
printertray which was not being passed to lpr command.
Proposed fix added InputSlot option to lpr command to select the 
printertray.


Tested in ubuntu and solaris11.

Regards
Prasanta

Re: [OpenJDK 2D-Dev] [9] Review Request: JDK-8158524: Test file added for VolatileImage -vs- BufferedImage output comparison

2016-08-17 Thread Prasanta Sadhukhan

+1 although I am not sure if JFrame is required. Probably it can be done 
with Frame too.


Regards
Prasanta
On 8/16/2016 1:41 PM, Prahalad Kumar Narayanan wrote:

Hello Everyone

This is a follow-up to my webrev.

Thanks to Sergey for his feedback.
I 've incorporated the feedback and changes are now available for review
   Link: http:// 
http://cr.openjdk.java.net/~pnarayanan/8158524/webrev.02/

Summary on changes from previous revision:
. '@key headful' has been added to the jtreg comments
. Swing UI components are invoked on EDT

Kindly review the changes and provide your feedback at your convenience

Thank you
Have a good day

Prahalad N.


-Original Message-
From: Sergey Bylokhov
Sent: Friday, August 12, 2016 6:39 PM
To: Prahalad Kumar Narayanan; Prasanta Sadhukhan; 2d-dev@openjdk.java.net
Subject: Re: [OpenJDK 2D-Dev] [9] Review Request: JDK-8158524: Test file added 
for VolatileImage -vs- BufferedImage output comparison

On 12.08.16 16:06, Sergey Bylokhov wrote:

Looks fine.
Please add @key heedful jtreg tag before the push.

Ouch I just realize that the test use the Swing components on non-EDT.


On 11.08.16 13:22, Prahalad Kumar Narayanan wrote:

Hello Everyone

First, Thanks to Prasanta for his feedback.
I 've incorporated the feedback in the code and changes are available
for review.
   Review Link:
http://cr.openjdk.java.net/~pnarayanan/8158524/webrev.01/

Quick summary on changes from previous revision:
   . Wild card imports have been replaced with specific imports
   . @override annotation has been added to the paint() method
   . RuntimeException is thrown instead of Error though both would
report regression failure.
   . Image loading has been corrected with proper filePath.
   . With regard to image and licensing issue:
 . I checked the image properties. There is no
'author/copyright' information with this image.
 . The file matches when compared (binary) with the
similar .gif image in test/java/awt/print/PrinterJob/

Kindly review the changes at your convenience and share your views.

Thank you
Have a good day

Prahalad N.


-Original Message-
From: Prasanta Sadhukhan
Sent: Thursday, August 11, 2016 1:02 PM
To: Prahalad Kumar Narayanan; 2d-dev@openjdk.java.net
Cc: Philip Race; Sergey Bylokhov
Subject: Re: [OpenJDK 2D-Dev] [9] Review Request: JDK-8158524: Test
file added for VolatileImage -vs- BufferedImage output comparison

You need to use @Override annotation for paint() method. Also, you
can use specific imports rather than package imports.
Also, I guess it's better to throw RuntimeException than Error for
failure, not sure how jtreg will react to it.
Lastly, I am not sure if you can use duke.gif image which maynot be
licensed although we have similar duke.gif in java/awt/print/PrinterJob.

Regards
Prasanta
On 8/11/2016 11:30 AM, Prahalad Kumar Narayanan wrote:

Hello Everyone

Good day to you.

I 'm planning to add a test file into jdk/test/ repository.
The webrev changes for the test file is presented herewith.
 Link:
http://cr.openjdk.java.net/~pnarayanan/8158524/webrev.00/

Brief on the test & its objectives:
  . As we know, VolatileImage utilizes accelerated rendering
using GPU while BufferedImage utilizes software rendering
  . The objective of this test-case is to check whether the
rendered 2d primitives appear same on VolatileImage and BufferedImage
  . In rare cases, the rendering on VolatileImage might
differ by few pixels from BufferedImage due to D3D/OpenGL driver 's
handling of primitives
   . Java2D pipelines for D3D/OpenGL APIs use fudge
factors to fine tune rendering calls so that output matches with
output of BufferedImage.
   . Thus the test case will help in checking for
consistent rendering across pipelines and also in identifying
scenarios where pipelines need to be fine-tuned.

Kindly review the test file and share your views at your convenience

Thank you
Have a good day

Prahalad N.




--
Best regards, Sergey.

Re: [OpenJDK 2D-Dev] [9] RFR JDK-4924727 : reader.abort() method does not work when called inside imageStarted for PNG

2016-08-17 Thread Phil Race


I think we can
- get all plugins,and for each
- write a file in that format
- read it back and apply the test

It is also worth verifying that the writer abort checks are in sync with 
the reader aborts,

ie happen at such equivalent points as might exist.

-phil.

On 08/15/2016 11:30 AM, Sergey Bylokhov wrote:
Is it possible to unify the test for all our plugins? I assume they 
should work in the same way. I am not sure but probably the image can 
be generated at runtime?


On 11.08.16 21:59, Jayathirth D V wrote:

Hi,



Please review the following fix in JDK9 at your convenience:



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



Webrev : http://cr.openjdk.java.net/~jdv/4924727/webrev.00/



Issue : When we issue ImageReader.abort() in
IIOReadProgressListener.imageStarted(), reading is not aborted and it is
continued.



Root cause : After IIOReadProgressListener.imageStarted() call in
PNGImageReader.java when we enter decodeImage() we call
clearAbortRequest() which will clear the abort request from
IIOReadProgressListener.imageStarted().



Solution : clearAbortRequest() documentation mentions that it should be
called before reading of image starts, so it should be called before
IIOReadProgressListener.imageStarted()(In PNGImageReader.java it is
processImageStarted(0) in readImage()). So moved clearAbortRequest()
call from decodeImage() to readImage(). Also we should call
abortRequested() in PNGImageReader.java at places mapping to
IIOReadProgressListener and not randomly at end of functions or at
places related to IIOReadUpdateListener, updated the code for the same.





Observation not related to this issue : We don’t have call similar to
IIOReadProgressListener.readAborted() in IIOReadUpdateListener, but user
can call ImageReader.abort() from IIOReadUpdateListener methods. Is
there a need to add similar method in IIOReadUpdateListener? Any inputs
on this also would be helpful.



Thanks,

Jay

Re: [OpenJDK 2D-Dev] [9] RFR JDK-6574279: validatePage from PrinterJob returns argument under linux

2016-08-17 Thread Phil Race


The cups docs say you can get physical margins as described here :

http://opensource.apple.com//source/cups/cups-62/doc/spm.shtml?txt#CUPS_API

PPD files specify all of the available pages sizes and the physical
margins associated with them.
...

ppd_sizet_ size   = ppdPageSize(ppd, "/size/");
...

The|  ||ppd_size_t|  structure contains the width, length, and margin 
information:

   typedef struct/ Page Sizes /
   {
  int   marked;   /* Page size selected? */
  char  name[41]; /* Media size option */
  float width,/* Width of media in points */
length,   /* Length of media in points */
left, /* Left printable margin in points */
bottom,   /* Bottom printable margin in points */
right,/* Right printable margin in points */
top;  /* Top printable margin in points */
   } ppd_size_t;


   


Moreover we are *already* calling that code :
See Java_sun_print_CUPSPrinter_getPageSizes

Does that not work ?
Perhaps the gap is that CUPSPrinter.java does not tie the MPA to the Media
it has created. Not sure of the best way to do this. Maybe the windows code
solves this differently but a simple HashMap may work here. You'll have to
investigate.

A few specific comments on the code :-


484 if (option != NULL && option->num_choices > 0) { we are expecting an 
array of 4 elements here so may be >=4 is what we should require ? 500 
JNU_ThrowOutOfMemoryError(env, "Could not create printer name");

comment seems to be a copy from an earlier line .. this is about
allocating an array

 516 @Override
 517 protected void validatePaper(Paper origPaper, Paper newPaper) {
 518 if (!(getPrintService() instanceof IPPPrintService)) {
 519 super.validatePaper(origPaper, newPaper);
 520 return;

Hmm.  IPPPrintService is Unix only whereas PSPrinterJob is shared code ..
so I will bet you didn't try yet to compile this on Windows.


-phil.

On 8/16/16, 4:47 AM, Prasanta Sadhukhan wrote:

Hi All,

On 8/11/2016 2:08 PM, Prasanta Sadhukhan wrote:

Hi Phil,

On 8/11/2016 3:05 AM, Phil Race wrote:

There does not seem to be a link to the new webrev in here.

Is it this : http://cr.openjdk.java.net/~psadhukhan/6574279/webrev.01/ ?

> to default Paper (Letter in US, A4 otherwise) imageable area

I don't think that will ever be A4. Where is that coming from ?

And you still have not fixed the problem with how you retrieve the 
MPA :-

 512 MediaPrintableArea mpa = (MediaPrintableArea)
 513 
getPrintService().getDefaultAttributeValue(MediaPrintableArea.class);



It is not supposed to be the MPA of the *default* paper. You want 
the MPA of *this* paper.
Only if origPaper is not a supported paper do you go look for the 
default paper.


As you suggested, I have modified to check if mpa of origPaper is 
amongst supported mpa(s) of the printer, if not, then go for mpa of 
default paper.

However, it seems among 61 mpas returned by CUPSPrinter ,
origPaper of 0,0,8.26",11.69" is within supported mpa of a paper size 
0,0,11.69",16.52" so it means 0,0,8",11" comes out to be supported mpa.


Can you please comment on this modified webrev on what more we can do?
http://cr.openjdk.java.net/~psadhukhan/6574279/webrev.02/

I guess we need to find out the physical limitation of printer via 
CUPS same what we do in windows via  GetDeviceCaps(printDC, 
PHYSICALOFFSETX); and use that in calculation for valid margin

but I could not find equivalent cups function. Can you suggest anyways?

I tried calling ppdFindOption(ppd, "HWMargins") in CUPS but it returns 
null although my printer ppd file has this line


*%=== Custom Paper Support =
*LeadingEdge Short: ""
*LeadingEdge Long: ""
*DefaultLeadingEdge: Short

*MaxMediaWidth:  "865"
*MaxMediaHeight: "1701"
**HWMargins:  12 12 12 12

*Anyways, I have updated the webrev to take care of the review 
comments and also get HWMargin (if the above ppdFindOption return null 
then fall back to custom margin as reported via ppd_file_t structure

https://www.cups.org/doc/api-ppd.html#ppd_file_s)

http://cr.openjdk.java.net/~psadhukhan/6574279/webrev.03/

Please review. Tested in ubuntu and solaris11.

Regards
Prasanta

Regards
Prasanta

-phil.

On 08/05/2016 03:20 AM, Prasanta Sadhukhan wrote:



On 8/4/2016 5:45 PM, Prasanta Sadhukhan wrote:

I will override in PSPrinterJob but
1662 MediaPrintableArea mpa =
1663 (MediaPrintableArea)getPrintService().
1664 getDefaultAttributeValue(MediaPrintableArea.class);

is returning imageable area of default media of chosen printer 
from CUPS [ all supported media printable area is obtained from 
CUPSPrinter#getPageSizes(printer) & then initMedia() populates 
cupsMediaPrintables which is returned in getMediaPrintableArea()]

as IPPPrintService#getDefaultAttributeValue() does
--
if (category == MediaPrintableArea.class) {
MediaPrintableArea[]

Re: [OpenJDK 2D-Dev] [9] RFC JDK-8154058: [TIFF] ignoreMetadata parameter of TIFFImageReader's setInput() method affects TIFFImageReadParam in non-obvious way

2016-08-17 Thread Phil Race

Hi,

That all seems fine (for the case of ignoreMetaData == true).

But there may be still a bug - of some kind - uncovered by this test.
The submitter has this case  :

ignore = false:
EXIF: true
Fax : true
GPS : true

which means that all metadata is being read .. as is the default per the 
docs
on the TIFF package description. But I am wondering what the effect 
setting of

 param.removeAllowedTagSet(FaxTIFFTagSet.getInstance());

should have been in this case.
A strict reading of the spec. makes it sound like it only has any effect
when you specify ignoreMetadata == true but I don't see the point
of the API in that case, since you are already ignoring metadata, unless
it is just a matter of being more clear to the reader that the latitude
it has to read metadata anyway regardless should be tempered by
this additional call.

But is there not also value in being able to remove the tag from
the allowed set in the ignoreMetadata == false case ?

That seemed to be the gist of the text here :-
>In cases where the IFD includes fields which contain
> large amounts of data this could be very inefficient.
> Which fields are loaded may be controlled by setting
>which TIFF tags the reader is allowed to recognize and whether it is 
ignoring metadata.

eg .. "I want all metadata except Fax" ..

-phil.

On 08/12/2016 11:23 AM, Brian Burkhalter wrote:

Please comment at your convenience.

Issue:https://bugs.openjdk.java.net/browse/JDK-8154058
Solution:Resolve as “Not an Issue”

According to [1],

/The |ignoreMetadata| parameter, if set to |true|, allows the reader 
to disregard any metadata encountered during the read. Subsequent 
calls to the |getStreamMetadata| and |getImageMetadata| methods may 
return |null|, and an |IIOImage| returned from |readAll| may return 
|null| from their |getMetadata| method. Setting this parameter may 
allow the reader to work more efficiently. The reader may choose to 
disregard this setting and return metadata normally. /

According to [2], setting ignoreMetadata has the effect of asking the 
reader to ignore any TIFF Fields which are not contained in any of the 
TIFFTagSets known to the reader. This seems to be within the scope of 
the specification in [1].

As a result of the foregoing I suggest that the issue be resolved as 
“Will not Fix.”

Thanks,

Brian

[1] 
http://download.java.net/java/jdk9/docs/api/javax/imageio/ImageReader.html#setInput-java.lang.Object-boolean-boolean-
[2] 
http://hg.openjdk.java.net/jdk9/client/jdk/file/d5dc0c4fb473/src/java.desktop/share/classes/javax/imageio/metadata/doc-files/tiff_metadata.html, 
lines 219-234

Re: [OpenJDK 2D-Dev] [9] RFR JDK-8149562: TIFFField#createFromMetadataNode javadoc should provide information about sibling/child nodes that should be part of parameter node

2016-08-17 Thread Phil Race


+1

-phil.

On 08/16/2016 09:02 AM, Brian Burkhalter wrote:

Please review at your convenience.

Issue:https://bugs.openjdk.java.net/browse/JDK-8149562
Patch:[1]

Add one sentence to the TIFFField.createFromMetadataNode method 
specification stating that the supplied Node parameter must adhere to 
the TIFFField element structure defined by the TIFF native image 
metadata DTD.


Thanks,

Brian

[1] diff

--- 
a/src/java.desktop/share/classes/javax/imageio/plugins/tiff/TIFFField.java
+++ 
b/src/java.desktop/share/classes/javax/imageio/plugins/tiff/TIFFField.java


 /**
  * Creates a {@code TIFFField} from a TIFF native image
  * metadata node. If the value of the {@code “number"} attribute
  * of the node is not found in {@code tagSet} then a new
  * {@code TIFFTag} with name {@code TIFFTag.UNKNOWN_TAG_NAME}
- * will be created and assigned to the field.
+ * will be created and assigned to the field. If the {@code Node}
+ * parameter content does not adhere to the {@code TIFFField} element
+ * structure defined by the
+ * href="../../metadata/doc-files/tiff_metadata.html#ImageMetadata">

+ * TIFF native image metadata format specification
+ * an {@code Exception} will be thrown.
  *
  * @param tagSet The {@code TIFFTagSet} to which the
  * {@code TIFFTag} of the field belongs.
  * @param node A native TIFF image metadata {@code TIFFField} node.
  * @throws NullPointerException if {@code node} is
  * {@code null}.
  * @throws IllegalArgumentException if the name of the node is not
  * {@code "TIFFField"}.
  * @throws NullPointerException if the node does not contain any 
data.
  * @throws IllegalArgumentException if the combination of node 
attributes
  * and data is not legal per the {@link 
#TIFFField(TIFFTag,int,int,Object)}

  * constructor specification.
  * @return A new {@code TIFFField}.
  */
 public static TIFFField createFromMetadataNode(TIFFTagSet tagSet,
  Node node) {

Re: [OpenJDK 2D-Dev] [9] RFR 8164205 [PIT][TEST_BUG] test javax/print/attribute/ServiceDlgPageRangeTest.java doesn't compile

2016-08-17 Thread Phil Race


+1

-phil.

]On 08/17/2016 09:06 AM, Prasanta Sadhukhan wrote:
will add this  bugid to the test as well which is missing in the below 
diff.


Regards
Prasanta
On 8/17/2016 8:33 PM, Prasanta Sadhukhan wrote:

Hi All,

Please review a modification to the testcase (wrong version was 
putbacked by mistake)


hg diff test/javax/print/attribute/ServiceDlgPageRangeTest.java
diff -r 0d3894b7fc66 
test/javax/print/attribute/ServiceDlgPageRangeTest.java
--- a/test/javax/print/attribute/ServiceDlgPageRangeTest.java Tue Aug 
09 13:22:58 2016 +0530
+++ b/test/javax/print/attribute/ServiceDlgPageRangeTest.java Wed Aug 
17 20:30:51 2016 +0530

@@ -29,6 +29,8 @@
  */
 import java.awt.BorderLayout;
 import java.awt.FlowLayout;
+import java.awt.event.WindowAdapter;
+import java.awt.event.WindowEvent;
 import javax.print.DocFlavor;
 import javax.print.PrintService;
 import javax.print.PrintServiceLookup;

Regards
Prasanta

Re: [OpenJDK 2D-Dev] [9] RFR 8164205 [PIT][TEST_BUG] test javax/print/attribute/ServiceDlgPageRangeTest.java doesn't compile

2016-08-17 Thread Prasanta Sadhukhan

will add this  bugid to the test as well which is missing in the below 
diff.


Regards
Prasanta
On 8/17/2016 8:33 PM, Prasanta Sadhukhan wrote:

Hi All,

Please review a modification to the testcase (wrong version was 
putbacked by mistake)


hg diff test/javax/print/attribute/ServiceDlgPageRangeTest.java
diff -r 0d3894b7fc66 
test/javax/print/attribute/ServiceDlgPageRangeTest.java
--- a/test/javax/print/attribute/ServiceDlgPageRangeTest.java Tue Aug 
09 13:22:58 2016 +0530
+++ b/test/javax/print/attribute/ServiceDlgPageRangeTest.java Wed Aug 
17 20:30:51 2016 +0530

@@ -29,6 +29,8 @@
  */
 import java.awt.BorderLayout;
 import java.awt.FlowLayout;
+import java.awt.event.WindowAdapter;
+import java.awt.event.WindowEvent;
 import javax.print.DocFlavor;
 import javax.print.PrintService;
 import javax.print.PrintServiceLookup;

Regards
Prasanta

Re: [OpenJDK 2D-Dev] [9] RFR JDK-6357887: selected printertray is ignored under linux

2016-08-17 Thread Philip Race


This all looks fine although this can be a simple call to
attributes.get(CustomMediaTray.class) can't it ?

502 for (int i=0; i< attrs.length; i++) {
 503 Attribute attr = attrs[i];
 504 try {
 505 if (attr instanceof CustomMediaTray) {
 506 CustomMediaTray customTray = 
(CustomMediaTray)attr;
 507 mOptions = " InputSlot="+ 
customTray.getChoiceName();

 508 }
 509 } catch (ClassCastException e) {

-phil.

On 8/10/16, 1:59 AM, Prasanta Sadhukhan wrote:

Hi All,

Please review a fix for an issue where it is seen that the selected 
printer tray is ignored in linux and default standard tray is used for 
printing.


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

Issue was lpr command needs "-o InputSlot=" to select the 
printertray which was not being passed to lpr command.
Proposed fix added InputSlot option to lpr command to select the 
printertray.


Tested in ubuntu and solaris11.

Regards
Prasanta

[OpenJDK 2D-Dev] [9] RFR 8164205 [PIT][TEST_BUG] test javax/print/attribute/ServiceDlgPageRangeTest.java doesn't compile

2016-08-17 Thread Prasanta Sadhukhan


Hi All,

Please review a modification to the testcase (wrong version was 
putbacked by mistake)


hg diff test/javax/print/attribute/ServiceDlgPageRangeTest.java
diff -r 0d3894b7fc66 test/javax/print/attribute/ServiceDlgPageRangeTest.java
--- a/test/javax/print/attribute/ServiceDlgPageRangeTest.javaTue Aug 
09 13:22:58 2016 +0530
+++ b/test/javax/print/attribute/ServiceDlgPageRangeTest.javaWed Aug 
17 20:30:51 2016 +0530

@@ -29,6 +29,8 @@
  */
 import java.awt.BorderLayout;
 import java.awt.FlowLayout;
+import java.awt.event.WindowAdapter;
+import java.awt.event.WindowEvent;
 import javax.print.DocFlavor;
 import javax.print.PrintService;
 import javax.print.PrintServiceLookup;

Regards
Prasanta

Re: [OpenJDK 2D-Dev] [9] RFR JDK-8163922: Print-to-file is disabled for SERVICE_FORMATTED docflavor in linux

2016-08-17 Thread Philip Race

+1 with the caveat that I am assuming you tested this did not regress 
anything else ..


-phil.

On 8/11/16, 10:22 PM, Prasanta Sadhukhan wrote:

Hi All,

Please review a fix for an issue where it is seen that Print-to-File 
option is disabled even for SERVICE_FORMATTED DocFlavor after 
JDK-5049012  fix.

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

We need to enabled dstSupported even if the destination is not 
specified for SERVICE_FORMATTED DocFlavor.


Regards
Prasanta

Re: [OpenJDK 2D-Dev] [9] Review Request: 8164104 Cleanup of javaclient related mapfiles

2016-08-17 Thread Sergey Bylokhov

Tested on solarisX64/solarisSparc/linuxX64 no issues were 
found(SwingSet2/Java2Demo).
But I wonder why the text on solarissparc filled by yellow shadow(Is it 
a known issue)?


On 16.08.16 19:33, Phil Race wrote:

I think "JPRT is OK" is good but may be not enough here?
I am not sure if the build will complain about missing entries
for JNI methods since there is no direct linking against these.
Can you do a quick sanity run through of Java2Demo on Linux ..
and ideally Solaris x64 too.

-phil.

On 08/16/2016 09:22 AM, Sergey Bylokhov wrote:

Hello.

Please review cleanup of mapfiles, initially the problem was found here:
http://mail.openjdk.java.net/pipermail/awt-dev/2016-August/011734.html

 - tabs were replaced by spaces
 - doubled empty lines removed

jprt is ok.

Bug: https://bugs.openjdk.java.net/browse/JDK-8164104
Patch can be found at:
http://cr.openjdk.java.net/~serb/8164104/webrev.00/jdk.patch






--
Best regards, Sergey.

Re: [OpenJDK 2D-Dev] [9] RFR JDK-6357887: selected printertray is ignored under linux

Re: [OpenJDK 2D-Dev] [9] RFR JDK-6357887: selected printertray is ignored under linux

Re: [OpenJDK 2D-Dev] [9] Review Request: JDK-8158524: Test file added for VolatileImage -vs- BufferedImage output comparison

Re: [OpenJDK 2D-Dev] [9] RFR JDK-4924727 : reader.abort() method does not work when called inside imageStarted for PNG

Re: [OpenJDK 2D-Dev] [9] RFR JDK-6574279: validatePage from PrinterJob returns argument under linux

Re: [OpenJDK 2D-Dev] [9] RFC JDK-8154058: [TIFF] ignoreMetadata parameter of TIFFImageReader's setInput() method affects TIFFImageReadParam in non-obvious way

Re: [OpenJDK 2D-Dev] [9] RFR JDK-8149562: TIFFField#createFromMetadataNode javadoc should provide information about sibling/child nodes that should be part of parameter node

Re: [OpenJDK 2D-Dev] [9] RFR 8164205 [PIT][TEST_BUG] test javax/print/attribute/ServiceDlgPageRangeTest.java doesn't compile

Re: [OpenJDK 2D-Dev] [9] RFR 8164205 [PIT][TEST_BUG] test javax/print/attribute/ServiceDlgPageRangeTest.java doesn't compile

Re: [OpenJDK 2D-Dev] [9] RFR JDK-6357887: selected printertray is ignored under linux

[OpenJDK 2D-Dev] [9] RFR 8164205 [PIT][TEST_BUG] test javax/print/attribute/ServiceDlgPageRangeTest.java doesn't compile

Re: [OpenJDK 2D-Dev] [9] RFR JDK-8163922: Print-to-file is disabled for SERVICE_FORMATTED docflavor in linux

Re: [OpenJDK 2D-Dev] [9] Review Request: 8164104 Cleanup of javaclient related mapfiles

13 matches

Site Navigation

Mail list logo

Footer information