Hi,
Thanks for checking that.
The bit I don't like here is that the end-user can then no longer ask
for collation
at all on Linux even though it has some chance of working on some versions.
Hmm ..
http://stackoverflow.com/questions/31056278/postscript-file-is-not-collating-when-cups-copies-is-set
---
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.
---
We set NumCopies in the Postscript along with collate :-
mPSStream.print(isCollated() ? " /Collate true":"");
mPSStream.print(" /NumCopies " +getCopiesInt());
So when we exec we also do "lp -# 2 .. " or whatever do set copies.
Does it help if we stop doing that for the collated case ?
-phil.
On 12/10/2016 12:19 AM, Prasanta Sadhukhan wrote:
On 12/10/2016 4:58 AM, Phil Race wrote:
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. 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. I tracked down the changeset that has the
code you reference
http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/dead66347eca If you read
the bug report for that :
https://bugs.openjdk.java.net/browse/JDK-8016737 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 "CUPS
does not report collate as a supported attribute"
I checked getAttMap (response received from cups)
http://hg.openjdk.java.net/jdk9/client/jdk/file/dc658d7dde90/src/java.desktop/unix/classes/sun/print/IPPPrintService.java#l1767
and there is no "collate-supported" attribute in there.
It is mentioned in CUPS docs.
https://opensource.apple.com/source/cups/cups-62/doc/spm.shtml?txt#CONSTANTS
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 ?
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.
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.
Regards
Prasanta
-phil.
On 12/09/2016 12:22 AM, Prasanta Sadhukhan wrote:
Hi All,
In continuation with the below mail, the issue is "collate" option
is not checked for linux.
Bug: https://bugs.openjdk.java.net/browse/JDK-8170352
webrev: http://cr.openjdk.java.net/~psadhukhan/8170352/webrev.00/
Proposed fix is to disable collate option for linux in printer dialog.
Regards
Prasanta
On 12/8/2016 4:23 PM, Prasanta Sadhukhan wrote:
Hi Phil,
I was investigating JDK-8170352: The collate option is not checked
and I found that CUPS does not report collate as supported attribute.
It is removed from printRequestAttrib
[http://hg.openjdk.java.net/jdk9/client/jdk/file/a21bac70753d/src/java.desktop/unix/classes/sun/print/IPPPrintService.java#l167]
so we do not look for collate-supported attribute in CUPS. Infact,
getAttMap does not have any "collate-supported" attribute too!!
Also, this code
[http://hg.openjdk.java.net/jdk9/client/jdk/file/a21bac70753d/src/java.desktop/unix/classes/sun/print/IPPPrintService.java#l1062]
has been added [for 8016737]
to remove SheetCollate from supported attributes.
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
http://hg.openjdk.java.net/jdk9/client/jdk/file/a21bac70753d/src/java.desktop/share/classes/sun/print/ServiceDialog.java#l1251
it is enabled if we specify in testcase
/job.setDefaultSelection(JobAttributes.DefaultSelectionType.SELECTION);
/in which case isAWT set to true.
even though selection is determined by attribute support
[http://hg.openjdk.java.net/jdk9/client/jdk/file/a21bac70753d/src/java.desktop/share/classes/sun/print/ServiceDialog.java#l1320]
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.
I think there also, we should check for "scSupported" to enable
sheetcollate? Anyways, "Selection" option is not there in linux.
Please let me know your views.
Regards
Prasanta
