<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <p>I think the real problem is not in
      RasterPrinterJob.getPageFormatFromAttributes(). <br>
    </p>
    <p>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. <br>
    </p>
    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<br>
    <i>>>else {</i><i><br>
    </i><i>>>            // for AWT where pageable is not an
      instance of OpenBook,</i><i><br>
    </i><i>>>            // we need to save paper info</i><i><br>
    </i><i> >>           this.attributes = attributes;</i><i><br>
    </i><i> >>       }</i><i><br>
    </i>
    <p><i> </i>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.<br>
    </p>
    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. <br>
    <br>
    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)<br>
    <br>
    BTW, a regression testcase (even if it is manual) should be created
    with the fix.<br>
    <br>
    Regards<br>
    Prasanta<br>
    <div class="moz-cite-prefix">On 3/17/2017 10:59 PM, Anton Litvinov
      wrote:<br>
    </div>
    <blockquote
      cite="mid:17a96ade-ea01-95bd-728a-ec3106d1fbfa@oracle.com"
      type="cite">Hello,
      <br>
      <br>
      Could you please review the following fix for the bug.
      <br>
      <br>
      Bug: <a class="moz-txt-link-freetext" href="https://bugs.openjdk.java.net/browse/JDK-8167102">https://bugs.openjdk.java.net/browse/JDK-8167102</a>
      <br>
      Webrev:
      <a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~alitvinov/8167102/jdk9/webrev.00">http://cr.openjdk.java.net/~alitvinov/8167102/jdk9/webrev.00</a>
      <br>
      <br>
      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".
      <br>
      <br>
      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.
      <br>
      <br>
      THE SOLUTION:
      <br>
      Although it is clearly stated in Java Platform SE 8 API
      Specification (documentation of the method
      "PrinterJob.print(PrintRequestAttributeSet)")
      <br>
      Specification URL:
<a class="moz-txt-link-freetext" href="http://docs.oracle.com/javase/8/docs/api/java/awt/print/PrinterJob.html#print-javax.print.attribute.PrintRequestAttributeSet">http://docs.oracle.com/javase/8/docs/api/java/awt/print/PrinterJob.html#print-javax.print.attribute.PrintRequestAttributeSet</a>-<br>
      <br>
      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".
      <br>
      <br>
      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.
      <br>
      <br>
      Thank you,
      <br>
      Anton
      <br>
    </blockquote>
    <br>
  </body>
</html>