That's why I call the new code before setAttributes() so that user's
selection is not overridden. I put a comment regarding that in the fix.
Regards
Prasanta
On 9/22/2016 10:38 PM, Philip Race wrote:
What happens if the application does not display a dialog but
instead the application code explicitly does this:
aset.add(JobSheets.STANDARD);
print(aset)
?
It appears to me you will over-ride that.
-phil.
On 9/22/16, 9:54 AM, Prasanta Sadhukhan wrote:
Hi Phil,
My new code takes care of the problem when attribute is not set by
the user who directly calls PrinterJob.print(). If no print dialog is
shown, then print(attr) seems to be called with Null attribute
and since noJobSheet was false, it used to print the banner page.
I now checked only the
PrintService.getDefaultAttributeValue(JobSheets.class) and if IPP
returns "none", I change the default noJobSheet to true so that no
banner page is printed (to honor system default).
Regards
Prasanta
On 9/22/2016 10:16 PM, Philip Race wrote:
This looks wrong to me. Shouldn't the logic look like the one you
have earlier in
the file ? ie this :
1271 JobSheets jobSheets =
(JobSheets)attributes.get(JobSheets.class);
1272 if (jobSheets != null) {
1273 noJobSheet = jobSheets == JobSheets.NONE;
1274 } else {
1275 JobSheets js = (JobSheets)getPrintService().
1276 getDefaultAttributeValue(JobSheets.class);
1277 if (js != null && js.equals(JobSheets.NONE)) {
1278 noJobSheet = true;
1279 }
1280 }
As it is your new code seems to completely disregard any setting by
the application in the attribute set - which *does not* have
anything to do with
whether a dialog was set.
Also I reject that this can be a TCK failure.
"I got a banner page" is something that can be a system configuration
parameter and is wholly outside anything JCK can (or should) care
about.
You could fix this but it could then behave the same on a different
system.
In fact my reading of the bug is simply that they noticed this when
running
a TCK test. That does not make it a TCK failure.
I have removed the tck labels from the bug and JCK can argue with me
if they want to ..
-phil.
On 9/16/16, 3:21 AM, Prasanta Sadhukhan wrote:
Hi All,
Please review a fix for a tck failure in jdk9 whereby "banner page"
(cover page) is printed by default when print() is called directly
without any print dialog being shown.
Bug: https://bugs.openjdk.java.net/browse/JDK-8165947
webrev: http://cr.openjdk.java.net/~psadhukhan/8165947/webrev.00/
Issue was in RasterPrinterJob, "noJobSheet" variable was set to
false which when passed to PSPrinterJob#printExecCmd(), it results
in adding "-o job-sheets=standard" to lpr command and
therefore, Banner page was getting printed by default.
Proposed fix is to check for defaultAttributeValue for JobSheets
attribute so that we can find what is the default value reported by
underlying platform and set "noJobSheet" value to default jobsheet
native value
(like CUPS report job-sheet=none so that no banner page is to be
printed by default even though it supports jobsheet)
I tested "6575247:Banner checkbox in PrinterJob print dialog
doesn't work" testcase in windows, solaris, linux and it works as
expected.
JCK test api/javax_swing/interactive/PrintTest.html#PrintTest via
command
"/jdk-9/bin/java -showversion
-Dswing.defaultlaf=com.sun.java.swing.plaf.motif.MotifLookAndFeel
-cp /root/jck/JCK-runtime-9/classes:
-Djava.security.policy=/root/jck/JCK-runtime-9/lib/jck.policy
javasoft.sqe.tests.api.java.awt.interactive.PrintTest
-platform.hasPrinter true -TestCaseID ALL"
also works ie no banner page is printed by default.
Regards
Prasanta
