Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 315181

Summary: [Automation][Regression]Grid border was messed in PDF
Product: z_Archived Reporter: Wen Lin <wlin>
Component: BIRTAssignee: Yu Chen <yChen>
Status: CLOSED FIXED QA Contact: mindan xu <mindan.xu>
Severity: normal    
Priority: P3 CC: hustlg, Lina.Kemmel
Version: 2.6.0Flags: Lina.Kemmel: review?
Target Milestone: 2.6.0 RC4   
Hardware: PC   
OS: Windows XP   
Whiteboard: Obsolete
Attachments:
Description Flags
report design
none
Patch none

Description Wen Lin CLA 2010-06-01 04:56:15 EDT
Created attachment 170619 [details]
report design

Description:
  Set report direction to RTL, grid border was messed while previewing report in PDF.

Step to reproduce:

1. Use the report attached
2. Preview it in PDF

Expect result:
The border display as report design.

Actual result:
The border was totally messed.
Comment 1 Lina Kemmel CLA 2010-06-01 19:25:54 EDT
Created attachment 170724 [details]
Patch

The main problem was that RowArea#reorderCellsForRTL() manipulated cell as distinct elements, however, there can be dummy duplicate cells.
I also moved the logic to add/update( AbstractArea ) obtaining original X position not from the cell element itself but from the TableLayoutInfo.

Another problem was that in presence of colspan, column ID used to be "flipped" although there is no need to do so as TableLayoutInfo is no longer storing mirrored X positions.

In addition, I hope that TableLayout#getLeftCellContentStyle issue of the next cell not yet being initialized in RTL (marked with "FIXME") was fixed. Instead, for each cell area TableLayout#resolveBorderConflict calculates left border as usual. However, this border stands for the left border of the logically preceding (= visually next) cell and the right border for the current cell.
Comment 2 Lina Kemmel CLA 2010-06-01 19:35:34 EDT
(In reply to comment #1)

> In addition, I hope that TableLayout#getLeftCellContentStyle issue of the next
> cell not yet being initialized in RTL (marked with "FIXME") was fixed. 
> Instead, for each cell area TableLayout#resolveBorderConflict calculates left 
> border as usual. However, this border stands for the left border of the 
> logically preceding (= visually next) cell and the right border for the 
> current cell.

Actually, this happens not really for "each cell area" but only for cells that satisfy the appropriate criteria .. I.e. 
if ( columnID > startCol && ( leftCellContentStyle != null || cellContentStyle != null ) )
where 'leftCellContentStyle' belongs to the logically previous cell (in other words, it's "LEADCellContentStyle").
Comment 3 Yu Chen CLA 2010-06-06 23:00:08 EDT
The patch is applied.
Comment 4 mindan xu CLA 2010-06-07 04:43:00 EDT
Build <2.6.0.v20100607-0630>
Comment 5 Wen Lin CLA 2010-06-13 04:05:15 EDT
Closed