<Swing Dev> RFR: [9] [JDK-8081491] The case print incomplete.

[prasanta sadhukhan]

Thanks Sergey for pointing this.
I have taken care of this plus formatting in for loop.
Please have a look

http://cr.openjdk.java.net/~psadhukhan/8081491/webrev.04/

Regards
Prasanta
On 9/8/2015 3:32 PM, Sergey Bylokhov wrote:
> Hi, Prasanta.
> A few small notes:
>  - BasicTableUI: typo "1850 // otherwise 1 extra rows are ptinted"
>  - ImageableAreaTest: the test instructions have copy pasted numbers 
> 1/2/2/2 etc.
>
>
>
> On 08.09.15 12:43, prasanta sadhukhan wrote:
>> Thanks for your review.
>>   I need +1 for this. Alexander Z/Sergey, can you please approve this 
>> fix?
>>
>> Regards
>> Prasanta
>> On 9/8/2015 3:02 PM, Alexander Scherbatiy wrote:
>>>
>>>   The fix looks good to me.
>>>
>>>   But you need to properly format spaces in the 'for' loop on line
>>> TablePrintable:410 before the push.
>>>
>>>   Thanks,
>>>   Alexandr.
>>>
>>> On 9/8/2015 12:26 PM, prasanta sadhukhan wrote:
>>>>
>>>>
>>>> On 9/7/2015 5:50 PM, Alexander Scherbatiy wrote:
>>>>> On 9/7/2015 9:23 AM, prasanta sadhukhan wrote:
>>>>>> I guess it will be same but anyways have modified to use
>>>>>> visibleBounds.getLocation() to be on safeside as we are dealing
>>>>>> with visible region for this fix.
>>>>>> Please review the updated webrev
>>>>>> http://cr.openjdk.java.net/~psadhukhan/8081491/webrev.02/
>>>>>
>>>>>     TablePrintable:
>>>>>      - Could the rMin be equal to -1?
>>>> This should never happen so long bounds intersects the clip but as
>>>> done in BasicTableUI, I have added the check just in case
>>>>> - Line: 406  int rowHeight = (rMax-rMin) * table.getRowHeight();
>>>>>        Rows can have different height in the table. Could you also
>>>>> add a test for the this case too?
>>>>>
>>>> Added test for this case too.
>>>> Please review this webrev:
>>>> http://cr.openjdk.java.net/~psadhukhan/8081491/webrev.03/
>>>>
>>>> Regards
>>>> Prasanta
>>>>> Thanks,
>>>>>     Alexandr.
>>>>>
>>>>>>
>>>>>> Regards
>>>>>> Prasanta
>>>>>> On 9/4/2015 8:57 PM, Alexander Scherbatiy wrote:
>>>>>>>
>>>>>>>  Could the clip.getLocation() be differ from them
>>>>>>> visibleBounds.getLocation()?
>>>>>>>
>>>>>>>  Thanks,
>>>>>>>  Alexandr.
>>>>>>>
>>>>>>> On 9/4/2015 3:32 PM, prasanta sadhukhan wrote:
>>>>>>>> Any reviewers for this please?
>>>>>>>>
>>>>>>>> On 9/2/2015 5:06 PM, prasanta sadhukhan wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> Can this fix be reviewed?
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> Prasanta
>>>>>>>>> On 8/28/2015 4:48 PM, prasanta sadhukhan wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 8/26/2015 6:24 PM, Alexander Scherbatiy wrote:
>>>>>>>>>>> On 8/25/2015 1:51 PM, prasanta sadhukhan wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 8/25/2015 3:53 PM, Alexander Scherbatiy wrote:
>>>>>>>>>>>>> On 8/24/2015 2:23 PM, prasanta sadhukhan wrote:
>>>>>>>>>>>>>> Hi All,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8081491
>>>>>>>>>>>>>> webrev:
>>>>>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8081491/webrev.00/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This seems to be a hidden JTable bug in which if the user
>>>>>>>>>>>>>> does not call pack() or set a ScrollPane() for JTable and
>>>>>>>>>>>>>> rather use JFrame.setSize() smaller than table size then it
>>>>>>>>>>>>>> was found that some of the rows which cannot be fitted in
>>>>>>>>>>>>>> 1st page cannot get printed on 2nd and subsequent pages
>>>>>>>>>>>>>> resulting in blank cells to be printed after 1st page.
>>>>>>>>>>>>>> It was found that BasicTableUI checks for table bounds to
>>>>>>>>>>>>>> fall within the clip and if they do not intersect, it bails
>>>>>>>>>>>>>> out from painting the table cells.
>>>>>>>>>>>>>
>>>>>>>>>>>>>      What is the reason that the graphics clip does not
>>>>>>>>>>>>> intersect the table bounds during printing in the provided
>>>>>>>>>>>>> test case?
>>>>>>>>>>>> The testcase does table.setSize(600,800) whereas frame
>>>>>>>>>>>> setSize is 400,600 .
>>>>>>>>>>>> For 1st page, the clip was 0,0,384,752 and bounds was
>>>>>>>>>>>> 0,0,384,562 so they intersect and there's no problem in
>>>>>>>>>>>> printing the rows in 1st page.
>>>>>>>>>>>> After the 1st page is printed, the clip is set to
>>>>>>>>>>>> 0,752,384,48 since we have printed the rows that we can fit
>>>>>>>>>>>> in 1st page and the next set of rows are to be printed while
>>>>>>>>>>>> bounds remains at 0,0,384,562 because JComponent getBounds is
>>>>>>>>>>>> returning the visible frame bounds which did not change.
>>>>>>>>>>>
>>>>>>>>>>>     The !bounds.intersects(clip) check prevents printing of
>>>>>>>>>>> table rows which are not visible on the frame.
>>>>>>>>>>>     It seems that the issue is that extra rows which are not
>>>>>>>>>>> shown in the frame are printed on the first page.
>>>>>>>>>>>     It means that the printed rows and columns should be
>>>>>>>>>>> calculated for the table bounds and clip intersection.
>>>>>>>>>>>     The test can be updated to mention that only visible part
>>>>>>>>>>> of the table should be printed.
>>>>>>>>>>>
>>>>>>>>>> Have modified the code to print only the rows that are
>>>>>>>>>> displayed on console. Also updated the test to mention the
>>>>>>>>>> same. Please review the updated webrev.
>>>>>>>>>>
>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8081491/webrev.01/
>>>>>>>>>>
>>>>>>>>>> Regards
>>>>>>>>>> Prasanta
>>>>>>>>>>> Thanks,
>>>>>>>>>>>    Alexandr.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> Please, also mention in the email title JDK version for
>>>>>>>>>>>>> which the fix is provided.
>>>>>>>>>>>> Done
>>>>>>>>>>>>
>>>>>>>>>>>> Regards
>>>>>>>>>>>> Prasanta
>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>    Alexandr.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I devised a solution whereby it will not bail out till
>>>>>>>>>>>>>> either rows or columns are still left to be printed on
>>>>>>>>>>>>>> subsequent pages . Please review and let me know if it's ok.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>> Prasanta
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
>