<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    I can believe that there are problems with some printers and not
    others.<br>
    Is this a Postscript printer, or not. <br>
    <br>
    IIRC you have Ricoh Aficio MP 5002 which is Postscript capable ..
    but it sounds to be an option :<br>
<a class="moz-txt-link-freetext" href="https://www.ricoh-usa.com/en/products/pd/mp-5002-black-and-white-laser-multifunction-printer/_/R-415957">https://www.ricoh-usa.com/en/products/pd/mp-5002-black-and-white-laser-multifunction-printer/_/R-415957</a><br>
    <br>
    Anyway, I prefer this approach - not denying the ability to do
    collation just because<br>
    it fails on some printers.<br>
    <br>
    +1<br>
    <br>
    -phil.<br>
    <br>
    <div class="moz-cite-prefix">On 12/16/2016 05:16 AM, Prasanta
      Sadhukhan wrote:<br>
    </div>
    <blockquote
      cite="mid:1a9dc491-0397-f9a7-76d8-2bd22808479f@oracle.com"
      type="cite">
      <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
      <p>I could finally manage to build on ubuntu16.04 (seems it uses
        gcc5.4 which is more than officially supported 4.9 causing some
        hotspot failure).</p>
      <p>Anyways, I am seeing the same "uncollation" issue in 16.04 ie
        it always collate irrespective of "collate" box is checked or
        not. I am not sure if it's got anything to do with my Ricoh
        printer.<br>
      </p>
      But, if you are seeing it working in yours, then probably all is
      well, so I am sending this modified webrev which causes awt
      functional test to show the printer dialog as expected.<br>
      <a moz-do-not-send="true" class="moz-txt-link-freetext"
        href="http://cr.openjdk.java.net/%7Epsadhukhan/8170352/webrev.01/">http://cr.openjdk.java.net/~psadhukhan/8170352/webrev.01/</a><br>
      <br>
      Probably Yuri or submitter can verify it at their end with this
      patch if it works.<br>
      <br>
      Regards<br>
      Prasanta<br>
      <div class="moz-cite-prefix">On 12/15/2016 4:55 AM, Phil Race
        wrote:<br>
      </div>
      <blockquote
        cite="mid:a1ea93b6-7f91-e62b-35d5-6299166a4e6f@oracle.com"
        type="cite">
        <meta content="text/html; charset=utf-8"
          http-equiv="Content-Type">
        With a hacked JDK 9 (so that collate is not disabled) I can
        print either collated or un-collated.<br>
        This is on Ubuntu 16.04 with HP CP4525<br>
        <br>
        testing this is a pain since the spooler hangs in "processing"
        after every job<br>
        and I need to kill the process and restart the printer.<br>
        <br>
        That is not a JDK problem since (a) outside our scope and (b)
        same problem with libreoffice printing ..<br>
        <br>
        But it makes me think that we should be looking at reverting
        8016737 .. not extending it.<br>
        <br>
        -phil.<br>
        <br>
        <div class="moz-cite-prefix">On 12/14/2016 01:20 PM, Phil Race
          wrote:<br>
        </div>
        <blockquote
          cite="mid:65b9d9c0-6a1a-3e47-761b-27aebe206488@oracle.com"
          type="cite">
          <meta content="text/html; charset=utf-8"
            http-equiv="Content-Type">
          <br>
          <br>
          <div class="moz-cite-prefix">On 12/14/2016 01:40 AM, Prasanta
            Sadhukhan wrote:<br>
          </div>
          <blockquote
            cite="mid:a4f147ff-c332-af5f-456e-dd367f539ebb@oracle.com"
            type="cite">
            <meta content="text/html; charset=utf-8"
              http-equiv="Content-Type">
            <p>Hi Phil,<br>
            </p>
            <br>
            <div class="moz-cite-prefix">On 12/14/2016 1:40 AM, Phil
              Race wrote:<br>
            </div>
            <blockquote
              cite="mid:71938210-24da-b2f0-6256-bf8d65321c3c@oracle.com"
              type="cite">
              <meta content="text/html; charset=utf-8"
                http-equiv="Content-Type">
              Hi,<br>
              <br>
              Thanks for checking that.<br>
              <br>
              The bit I don't like here is that the end-user can then no
              longer ask for collation<br>
              at all on Linux even though it has some chance of working
              on some versions.<br>
              <br>
            </blockquote>
            This is the case even without my change and collate option
            is disabled for PrinterJob. <br>
            My fix (?) makes it disabled for PrintJob too.<br>
          </blockquote>
          <br>
          Ah yes.<br>
          <blockquote
            cite="mid:a4f147ff-c332-af5f-456e-dd367f539ebb@oracle.com"
            type="cite">
            <blockquote
              cite="mid:71938210-24da-b2f0-6256-bf8d65321c3c@oracle.com"
              type="cite"> Hmm ..<br>
              <br>
              <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://stackoverflow.com/questions/31056278/postscript-file-is-not-collating-when-cups-copies-is-set">http://stackoverflow.com/questions/31056278/postscript-file-is-not-collating-when-cups-copies-is-set</a><br>
              ---<br>
              In our cups class we were doing a cupsAddOption("copies",
              "2",.. and cupsAddOption("Collate", "True", .. commands
              (see examples below). It turns out the the cups "copies"
              command was killing the Collating if it set to 2. Like the
              orientation postscript/cups conflict you need to set the
              cups copies value to 1 to get the collation to work. The
              postscript file already knows its going to print out, for
              example 2 copies. <br>
              ---<br>
              <br>
              We set NumCopies in the Postscript along with collate :-<br>
                          mPSStream.print(isCollated() ? " /Collate
              true":"");<br>
                          mPSStream.print(" /NumCopies "
              +getCopiesInt());<br>
              <br>
              So when we exec we also do "lp -# 2 .. " or whatever do
              set copies.<br>
              <br>
            </blockquote>
            We are setting copies to 1 in <a moz-do-not-send="true"
              class="moz-txt-link-freetext"
href="http://hg.openjdk.java.net/jdk9/client/jdk/file/dc658d7dde90/src/java.desktop/share/classes/sun/print/PSPrinterJob.java#l735">http://hg.openjdk.java.net/jdk9/client/jdk/file/dc658d7dde90/src/java.desktop/share/classes/sun/print/PSPrinterJob.java#l735</a>.<br>
          </blockquote>
          <br>
          OK.<br>
          <br>
          <blockquote
            cite="mid:a4f147ff-c332-af5f-456e-dd367f539ebb@oracle.com"
            type="cite"> <br>
            One thing is that, in my testing in ubuntu14.04 "collation"
            is working and "uncollation" is not working. When I print 2
            copies and do not select "collate" option in printer dialog
            [I enabled collate option by commenting out the isLinux
            check from <a moz-do-not-send="true"
              class="moz-txt-link-freetext"
href="http://hg.openjdk.java.net/jdk9/client/jdk/file/a21bac70753d/src/java.desktop/unix/classes/sun/print/IPPPrintService.java#l1062">http://hg.openjdk.java.net/jdk9/client/jdk/file/a21bac70753d/src/java.desktop/unix/classes/sun/print/IPPPrintService.java#l1062</a>]
            <br>
            then, it prints Page 0, Page 1, Page 0, Page 1 [same as,
            when I checked "collate" option] in my Ricoh printer in
            double-sided print. I think for uncollation, it should print
            Page 0, Page 0 back-to-back in 1 copy and Page1-Page1 in
            another copy, right?<br>
          </blockquote>
          <br>
          Yes, uncollated should be as you say.<br>
          What is going on ??? Is this for PrinterJob or PrintJob or
          both ?<br>
          I need to configure a printer on my Ubuntu .. I lost them
          recently when my hard drive went bad.<br>
          <br>
          -phil..<br>
          <br>
          <blockquote
            cite="mid:a4f147ff-c332-af5f-456e-dd367f539ebb@oracle.com"
            type="cite"> <br>
            Regards<br>
            Prasanta<br>
            <blockquote
              cite="mid:71938210-24da-b2f0-6256-bf8d65321c3c@oracle.com"
              type="cite"> Does it help if we stop doing that  for the
              collated case ?<br>
              <br>
              <br>
              -phil.<br>
              <br>
              <div class="moz-cite-prefix">On 12/10/2016 12:19 AM,
                Prasanta Sadhukhan wrote:<br>
              </div>
              <blockquote
                cite="mid:5bac0cf5-f5a8-7a31-1416-f141c9d6ba0d@oracle.com"
                type="cite">
                <meta content="text/html; charset=utf-8"
                  http-equiv="Content-Type">
                <p><br>
                </p>
                <br>
                <div class="moz-cite-prefix">On 12/10/2016 4:58 AM, Phil
                  Race wrote:<br>
                </div>
                <blockquote
                  cite="mid:06b1dd80-c128-4eeb-ae58-2ede9badf60c@oracle.com"
                  type="cite">
                  <meta content="text/html; charset=utf-8"
                    http-equiv="Content-Type">
                  <pre><span class="new">
Regarding being hard-coded for "Selection", the point there is that in the AWT code path
we always generate Postscript, whereas in the 2D path we may send some other content.
</span><span class="new"><span class="new">Since we generate Postscript my instinct here is that Collate should always work since
that gets embedded in the Postscript.
The CUPS filter should then do whatever is necessary to generate the right number
of collated or uncollated copies for the printer.
</span></span><span class="new"><span class="new"><span class="new">
I tracked down the changeset that has the code you reference
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/dead66347eca">http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/dead66347eca</a>

If you read the bug report for that : <a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://bugs.openjdk.java.net/browse/JDK-8016737">https://bugs.openjdk.java.net/browse/JDK-8016737</a>
then it becomes clear (sort of) that this was a workaround for the oddity that Collate
worked on Ubuntu 12.04 but not on Ubuntu 13.04, so the idea was to stop saying it
was supported.

That is very annoying of course and I'd love to know if we've rechecked from the source that
"</span></span></span><span class="new"><span class="new"><span class="new">CUPS does not report collate as a supported attribute"</span></span></span></pre>
                </blockquote>
                I checked getAttMap (response received from cups)<br>
                <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://hg.openjdk.java.net/jdk9/client/jdk/file/dc658d7dde90/src/java.desktop/unix/classes/sun/print/IPPPrintService.java#l1767">http://hg.openjdk.java.net/jdk9/client/jdk/file/dc658d7dde90/src/java.desktop/unix/classes/sun/print/IPPPrintService.java#l1767</a><br>
                and there is no "collate-supported" attribute in there.<br>
                <blockquote
                  cite="mid:06b1dd80-c128-4eeb-ae58-2ede9badf60c@oracle.com"
                  type="cite">
                  <pre><span class="new"><span class="new"><span class="new">

It is mentioned in CUPS docs.
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://opensource.apple.com/source/cups/cups-62/doc/spm.shtml?txt#CONSTANTS">https://opensource.apple.com/source/cups/cups-62/doc/spm.shtml?txt#CONSTANTS</a>
</span></span>

Also the fix you are proposing doesn't seem to change anything that will help
the test. It expects Collate to be checked. Doesn't it ?
</span></pre>
                </blockquote>
                The fix does not directly help the test. The idea is to
                have the test call first
                isAttributeCategorySupprted(SheetCollate.class) and only
                execute the test if it is supported. It is mentioned
                inthe bug report.<br>
                Since, now our code returns false for SheetCollate
                attribute, my fix will disable the collate option to
                prevent anomaly of returning false for support but
                enabling the collate option.<br>
                <br>
                Regards<br>
                Prasanta<br>
                <blockquote
                  cite="mid:06b1dd80-c128-4eeb-ae58-2ede9badf60c@oracle.com"
                  type="cite">
                  <pre><span class="new">
-phil.

</span></pre>
                  <br>
                  <br>
                  <div class="moz-cite-prefix">On 12/09/2016 12:22 AM,
                    Prasanta Sadhukhan wrote:<br>
                  </div>
                  <blockquote
                    cite="mid:cf5c7acd-b269-07c9-f828-9020ca73fe40@oracle.com"
                    type="cite">
                    <meta content="text/html; charset=utf-8"
                      http-equiv="Content-Type">
                    <p>Hi All,</p>
                    <p>In continuation with the below mail, the issue is
                      "collate" option is not checked for linux.</p>
                    <p>Bug: <a moz-do-not-send="true"
                        class="moz-txt-link-freetext"
                        href="https://bugs.openjdk.java.net/browse/JDK-8170352">https://bugs.openjdk.java.net/browse/JDK-8170352</a></p>
                    <p>webrev: <a moz-do-not-send="true"
                        class="moz-txt-link-freetext"
                        href="http://cr.openjdk.java.net/%7Epsadhukhan/8170352/webrev.00/">http://cr.openjdk.java.net/~psadhukhan/8170352/webrev.00/</a><br>
                    </p>
                    <p>Proposed fix is to disable collate option for
                      linux in printer dialog.<br>
                    </p>
                    Regards<br>
                    Prasanta<br>
                    <div class="moz-cite-prefix">On 12/8/2016 4:23 PM,
                      Prasanta Sadhukhan wrote:<br>
                    </div>
                    <blockquote
                      cite="mid:beb05a66-bf2d-ff16-47a8-291688670489@oracle.com"
                      type="cite">
                      <meta http-equiv="content-type"
                        content="text/html; charset=utf-8">
                      <p>Hi Phil,</p>
                      <p>I was investigating JDK-8170352: The collate
                        option is not checked and I found that CUPS does
                        not report collate as supported attribute. <br>
                      </p>
                      It is removed from printRequestAttrib [<a
                        moz-do-not-send="true"
                        class="moz-txt-link-freetext"
href="http://hg.openjdk.java.net/jdk9/client/jdk/file/a21bac70753d/src/java.desktop/unix/classes/sun/print/IPPPrintService.java#l167"><a class="moz-txt-link-freetext" href="http://hg.openjdk.java.net/jdk9/client/jdk/file/a21bac70753d/src/java.desktop/unix/classes/sun/print/IPPPrintService.java#l167">http://hg.openjdk.java.net/jdk9/client/jdk/file/a21bac70753d/src/java.desktop/unix/classes/sun/print/IPPPrintService.java#l167</a></a>]<br>
                      so we do not look for collate-supported attribute
                      in CUPS. Infact, getAttMap does not have any
                      "collate-supported" attribute too!!<br>
                      Also, this code [<a moz-do-not-send="true"
                        class="moz-txt-link-freetext"
href="http://hg.openjdk.java.net/jdk9/client/jdk/file/a21bac70753d/src/java.desktop/unix/classes/sun/print/IPPPrintService.java#l1062">http://hg.openjdk.java.net/jdk9/client/jdk/file/a21bac70753d/src/java.desktop/unix/classes/sun/print/IPPPrintService.java#l1062</a>]
                      has been added [for 8016737] <br>
                      to remove SheetCollate from supported attributes.<br>
                      <br>
                      In light of this, I think we should disabled
                      collate option from our print dialog even for
                      Toolkit based PrintJob. It seems, from this code <br>
                      <a moz-do-not-send="true"
                        class="moz-txt-link-freetext"
href="http://hg.openjdk.java.net/jdk9/client/jdk/file/a21bac70753d/src/java.desktop/share/classes/sun/print/ServiceDialog.java#l1251">http://hg.openjdk.java.net/jdk9/client/jdk/file/a21bac70753d/src/java.desktop/share/classes/sun/print/ServiceDialog.java#l1251</a><br>
                      it is enabled if we specify in testcase<br>
                      <i>job.setDefaultSelection(JobAttributes.DefaultSelectionType.SELECTION);
                      </i>in which case isAWT set to true.<br>
                      even though selection is determined by attribute
                      support [<a moz-do-not-send="true"
                        class="moz-txt-link-freetext"
href="http://hg.openjdk.java.net/jdk9/client/jdk/file/a21bac70753d/src/java.desktop/share/classes/sun/print/ServiceDialog.java#l1320">http://hg.openjdk.java.net/jdk9/client/jdk/file/a21bac70753d/src/java.desktop/share/classes/sun/print/ServiceDialog.java#l1320</a>]<br>
                      <br>
                      I could not find why it is hardcoded to
                      setEnabled(true) for "Selection". Do you know?
                      mercurial history shows that line from jdk7 and I
                      could not find previous history.<br>
                       I think there also, we should check for "<span
                        id="l1320">scSupported" to enable sheetcollate?
                        Anyways, "Selection" option is not there in
                        linux.<br>
                        Please let me know your views.<br>
                      </span><br>
                      Regards<br>
                      Prasanta<br>
                    </blockquote>
                    <br>
                  </blockquote>
                  <br>
                </blockquote>
                <br>
              </blockquote>
              <br>
            </blockquote>
            <br>
          </blockquote>
          <br>
        </blockquote>
        <br>
      </blockquote>
      <br>
    </blockquote>
    <br>
  </body>
</html>