Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 315181 - [Automation][Regression]Grid border was messed in PDF
Summary: [Automation][Regression]Grid border was messed in PDF
Status: CLOSED FIXED
Alias: None
Product: z_Archived
Classification: Eclipse Foundation
Component: BIRT (show other bugs)
Version: 2.6.0   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 2.6.0 RC4   Edit
Assignee: Yu Chen CLA
QA Contact: mindan xu CLA
URL:
Whiteboard: Obsolete
Keywords:
Depends on:
Blocks:
 
Reported: 2010-06-01 04:56 EDT by Wen Lin CLA
Modified: 2010-06-13 04:05 EDT (History)
2 users (show)

See Also:
Lina.Kemmel: review?


Attachments
report design (34.12 KB, application/octet-stream)
2010-06-01 04:56 EDT, Wen Lin CLA
no flags Details
Patch (6.56 KB, patch)
2010-06-01 19:25 EDT, Lina Kemmel CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
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