[OpenJDK 2D-Dev] [9] RFR 4987884: PrinterJob carries over some values between calls to print.

[Prasanta Sadhukhan]

Modified webrev to ensure attributes set are cleared before return so 
that subsequent print() call start off with clean-slate.

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

One thing is, due to this contract for print(PrintRequestAttributes) 
which specifies
/"some attributes may be set directly on the PrinterJob by equivalent 
method calls, (for example), copies: //|setcopies(int)|//, job name: 
//|setJobName(String)|//....
//If a supported attribute-value is specified in this attribute set, it 
will take precedence over the API settings for this print() operation 
only. /"

setCopies, setJobName() attributes can also be set via APIs so those 
attributes are cleared only if set via attributeSet and not when set via 
APIs because in that case, it should be valid across print() calls.

Regards
Prasanta
On 11/5/2016 12:00 AM, Phil Race wrote:
> I've always considered it unfortunate that PrinterJob did not
> prohibit print() being called twice from day one.
> It is not something I would encourage apps to do and I
> would not be surprised to see this as the source of odd bugs.
> If I could I would go update all the implementation code to
> throw IllegalStateException if you call print() twice but
> I suspect it may break code that does this for some reason
> that in all probability is historical (like "I'm saving 
> CPU/memory/whatever")
> So I don't want to put anything in the docs that imply that
> it is something that an app might be encouraged to do.
>
> i.e. in the test the app does
>
> aset.add(new PageRanges(1,1));
> ..
> pjob.print(aset);
>
> ...
> pjob.print();
> ...
>
> PageRanges is *an example* of what should not be carried over.
>
> So I think this (and the initial v0 fix) is missing the point of the bug
> which is "The attribute set passed in a by the app should not be 
> remembered
> across calls."
>
> In fact the proposed doc. arguably legitimises the opposite.
> 1427 * If {@code print(PrintRequestAttributeSet attributes)} is called 
> before
> 1428 * this method for the same PrinterJob, it is expected to 
> use/carryover the
> 1429 * same attributes set passed to
> 1430 * {@code print(PrintRequestAttributeSet attributes)}
>
> What I was asking for in the bug report was that *any* settings
> in that first print(aset) call should not be preserved as internal
> state once print(aset) returns. So it seems like a clean-up-before-return
> rather than a clean-up-on-reentry.
>
> This requires careful attention to the contract of this method
>
> https://docs.oracle.com/javase/8/docs/api/java/awt/print/PrinterJob.html#print-javax.print.attribute.PrintRequestAttributeSet-
>
> Now since this bug was filed we added the ability to use the native
> dialogs with an attribute set, so there may be some additional
> or deeper pollution of the native state which may make this harder
> to achieve. I don't have a ready answer for that but it does not
> mean that we should give up with out a proper study of this ..
>
> -phil.
>
> On 09/29/2016 02:39 AM, Prasanta Sadhukhan wrote:
>>
>>
>> On 9/12/2016 12:33 PM, Prasanta Sadhukhan wrote:
>>> Hi All,
>>>
>>> Updated the spec to clarify that it is expected to use the same 
>>> attribute set passed to print(PrintRequestAttributeSet) if it is 
>>> called before no-args print() method for same PrinterJob.
>>> http://cr.openjdk.java.net/~psadhukhan/4987884/webrev.01/
>>>
>> Updated PrinterJob spec as opposed to inner class RasterPrinterJob so 
>> that javadocs is updated.
>> http://cr.openjdk.java.net/~psadhukhan/4987884/webrev.02/
>>
>> Regards
>> Prasanta
>>> Regards
>>> Prasanta
>>> On 8/29/2016 1:41 PM, Prasanta Sadhukhan wrote:
>>>> Hi All,
>>>>
>>>> If we call
>>>> -----------------
>>>> /        pageFormat = job.pageDialog(pageFormat);//
>>>> //        pageFormat.setPaper(paper);//
>>>> //        job.setPrintable(p, pageFormat);//
>>>> ////
>>>> //        try {//
>>>> //            job.printDialog();//
>>>> //            job.print();//
>>>> //        } catch (PrinterException e) {}//
>>>> /-------------------
>>>> then these attributes are added
>>>> Media, OrientationRequested, MediaPrintableArea, Chromaticity, 
>>>> PrinterResolution, Copies, SheetCollate, Sides
>>>> even if we do not change any fields
>>>> and PageRanges attribute is added if we change page selection from 
>>>> "All" to "Pages".
>>>>
>>>> In light of that, I do not think we can remove PageRanges attribute 
>>>> from no-args print() method as that will remove user selection.
>>>>  Or for that matter, any attributes as those can be set via 
>>>> pageDialog or printDialog.
>>>>
>>>> I guess we need to mark this as "Wont fix" . spec also is not clear 
>>>> if we are not supposed to honour any attributes already set, if we 
>>>> call no-args print() method.
>>>> Any comments?
>>>>
>>>> Regards
>>>> Prasanta
>>>> On 7/5/2016 10:52 AM, Prasanta Sadhukhan wrote:
>>>>> Hi All,
>>>>>
>>>>> Please review a fix whereby it is seen that the PageRanges 
>>>>> attribute passed to 1st print() call is inadvertently been carried 
>>>>> forward to 2nd print
>>>>> if some program tries calling in this sequence
>>>>> ----------
>>>>> /PrinterJob pj = PrinterJob.getPrinterJob();//
>>>>> //pj.setPageable(..)//
>>>>> //pj.print(..)//
>>>>> //pj.setPageable(..)//
>>>>> //pj.print(..)
>>>>> ------------
>>>>> /
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-4987884/
>>>>> /webrev: http://cr.openjdk.java.net/~psadhukhan/4987884/webrev.00//
>>>>>
>>>>> /This is because no-args print() uses an internal attribute set 
>>>>> which is presumed to carry over information not supplied
>>>>> by the client directly but created during a call to no-args 
>>>>> printDialog() or during call to setPrintable() called via 
>>>>> setAttributes().
>>>>> but it apparently seems, we should not be remembering PageRange 
>>>>> attribute between calls to print() as it will result in wrong page 
>>>>> numbers being printed.
>>>>>
>>>>> Proposed fix to remove the PageRanges attribute from no-args 
>>>>> print() between print() calls.
>>>>>
>>>>> Regards
>>>>> Prasanta
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20161110/d40bec0d/attachment.html>