<AWT Dev> [9] Review request for 8044444 The output's 'Page-n' footer does not show completely.
Phil Race
philip.race at oracle.com
Mon Dec 1 17:28:44 UTC 2014
Hmm .. it looks as if this breaks the case when the Swing dialog is
used, doesn't it ?
I think this update needs to be accompanied by regression tests that
show that
this kind of page set up using native & swing dialogs both work.
We can't easily use the JCK tests for this.
-phil.
On 11/27/14 7:45 AM, Alexander Scherbatiy wrote:
> On 11/21/2014 9:20 PM, Phil Race wrote:
>> This seems to me to be asking about something I covered already.
>>
>> >The latter one appears 'correct' in this case since applying it second
>> >fixes the output but I don't have enough information to know why the
>> >values differ.
>>
>> But you have the test case and I don't ..
>>
>> Did you try any of what I suggested ?
>
> The CPrinterJob.getPageFormat() returns right selected printer
> format. The problem is that RasterPrinterJob.attributeToPageFormat()
> method creates
> a default page with right page format and overrides page
> size/imageable area after that to predefined ones.
> This happens only because the CPrinterJob.printLoop() native method
> calls javaPrinterJobToNSPrintInfo(...) method after
> javaPageFormatToNSPrintInfo(...).
>
> The JCK has a set of JTable print tests. I run them using the
> predefined page size/imageable area and with the selected printer
> settings.
> The page number is properly printed when the selected printer
> settings are used.
>
> I have updated the fix to preserve the selected printer page size:
> http://cr.openjdk.java.net/~alexsch/8044444/webrev.01/
>
> Thanks,
> Alexandr.
>
>
>>
>> -phil.
>>
>> On 11/18/14 8:17 AM, Alexander Scherbatiy wrote:
>>>
>>>
>>> Hi Phil,
>>>
>>> Before the 8011069 fix
>>> RasterPrinterJob.getPageFormatFromAttributes() method returns null
>>> for null attributes
>>> and native page size for ImageableArea has been used.
>>> After the 8011069 fix the attributes are not null and
>>> updateAttributesWithPageFormat() method rewrites
>>> the ImageableArea size to the default constants.
>>>
>>> The question is which ImageableArea size is correct? If there
>>> should be used default values then the 8044444 is not an issue as
>>> all works as expected.
>>> If it is necessary to use native size then I can update the fix to
>>> do that.
>>>
>>> Thanks,
>>> Alexandr.
>>>
>>>
>>> On 10/30/2014 11:10 PM, Phil Race wrote:
>>>> When we reach this code everything in the job is already configured
>>>> by a
>>>> combination of initial settings and user updates and and we just
>>>> need to read
>>>> the settings and pass it on to the native NSPrintInfo.
>>>> So surely switching the order should not matter unless one of these
>>>> is using the 'wrong' PageFormat ?
>>>>
>>>> -----------------
>>>> the body of the method called here :-
>>>>
>>>> javaPrinterJobToNSPrintInfo(env, jthis, pageable, printInfo);
>>>>
>>>> gets its PageFormat as follows :-
>>>>
>>>> static JNF_MEMBER_CACHE(jm_getPageFormat, sjc_CPrinterJob,
>>>> "getPageFormatFromAttributes", "()Ljava/awt/print/PageFormat;");
>>>> ....
>>>>
>>>> jobject page = JNFCallObjectMethod(env, srcPrinterJob,
>>>> jm_getPageFormat);
>>>> if (page != NULL) {
>>>> javaPageFormatToNSPrintInfo(env, NULL, page, dst);
>>>> }
>>>>
>>>>
>>>> So this uses the result of making a call to
>>>> RasterPrinterJob.getPageFormatFromAttributes()
>>>>
>>>> protected PageFormat getPageFormatFromAttributes() {
>>>> if (attributes == null) {
>>>> return null;
>>>> }
>>>> return attributeToPageFormat(getPrintService(),
>>>> this.attributes);
>>>> }
>>>>
>>>> -----------------------------
>>>>
>>>> whereas
>>>>
>>>> javaPageFormatToNSPrintInfo(env, jthis, page, printInfo);
>>>>
>>>> is using a PageFormat obtained as follows :-
>>>>
>>>> static JNF_MEMBER_CACHE(jm_getPageFormat, sjc_CPrinterJob,
>>>> "getPageFormat", "(I)Ljava/awt/print/PageFormat;");
>>>>
>>>> jobject page = JNFCallObjectMethod(env, jthis,
>>>> jm_getPageFormat, 0);
>>>>
>>>> This is CPrinterJob.getPageFormat() { .. }
>>>>
>>>>
>>>> Although its not easily apparent what the returned values are in
>>>> each of these cases
>>>> it does seem they must be different.
>>>>
>>>> The latter one appears 'correct' in this case since applying it second
>>>> fixes the output but I don't have enough information to know why the
>>>> values differ.
>>>>
>>>> Looking at the fix for 8011069, it avoided an NPE by always
>>>> creating an 'attributes' map, albeit an empty one.
>>>> This can change the result of calling getPageFormatFromAttributes from
>>>> 'null' to a PageFormat built from an empty attribute set.
>>>> If the no-args native printDialog() and the no-args print() call is
>>>> used this will be empty.
>>>>
>>>> So the method will indeed build - at that moment - a page format
>>>> built from
>>>> default values.
>>>>
>>>> Now. If we *do* use the printDialog(PrintRequestAttributeSet) and
>>>> print(PrintRequestAttributeSet) methods, then it may well be that this
>>>> method is the one that should be called.
>>>>
>>>> And I think we were previously only in this block of code if that
>>>> were the case
>>>> by virtue of the block being guarded by "if (page != NULL)", which
>>>> means
>>>> there is an attributeset, which previously meant one of those "with
>>>> args"
>>>> methods had been used.
>>>>
>>>> So I wonder/suspect if the switching of the order will introduce
>>>> the equivalent
>>>> problem in that 'with args' case.
>>>>
>>>> As you can tell just looking at the webrev its nigh on impossible
>>>> to tell
>>>> for sure and you'd probably need to play around with testing changing
>>>> paper size and orientation in native and cross-platform dialogs to
>>>> test it.
>>>>
>>>> You could start by seeing if the test 'passes' simply by switching to
>>>> 'with args' before & after your fix - ensuring that the same paper
>>>> sizes
>>>> are being used. I am not sure what the default settings were that were
>>>> created for the empty attribute set vs the ones that are used when you
>>>> fixed this. You'll have to tell me that.
>>>>
>>>> Perhaps what is needed is a unified call to get the PageFormat which
>>>> can figure out whether to use the attributes or not. And you could
>>>> check if the call to CPrinterJob.getPageFormat() already performs
>>>> that ..
>>>>
>>>> -phil.
>>>>
>>>>
>>>> On 10/28/2014 01:03 PM, Alexander Scherbatiy wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> Could you review the fix?
>>>>>
>>>>> Thanks,
>>>>> Alexandr.
>>>>>
>>>>> On 7/15/2014 3:28 PM, Alexander Scherbatiy wrote:
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> Could you review the fix:
>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8044444
>>>>>> webrev: http://cr.openjdk.java.net/~alexsch/8044444/webrev.00
>>>>>>
>>>>>> Native method printLoop from CPrinterJob calls
>>>>>> javaPrinterJobToNSPrintInfo(...) method after
>>>>>> javaPageFormatToNSPrintInfo(...).
>>>>>> Both methods set the page size. The initial page size is set in
>>>>>> defaultPage(PageFormat) method.
>>>>>> After the fix 8011069 the printDialog() initializes attributes
>>>>>> which leads that new page size is created in the
>>>>>> attributeToPageFormat(PrintService, PrintRequestAttributeSet)
>>>>>> method.
>>>>>>
>>>>>> The fix changes order of the javaPrinterJobToNSPrintInfo(...)
>>>>>> javaPageFormatToNSPrintInfo(...) call so initial page size is set
>>>>>> at the end.
>>>>>>
>>>>>> There is the JCK test that covers the issue.
>>>>>>
>>>>>> Thanks,
>>>>>> Alexandr.
>>>>>>
>>>>>
>>>>
>>>
>>
>
More information about the awt-dev
mailing list