Bug 48245

Summary: [PATCH] TableCell.text() returns the texts in itself and the next cell
Product: POI Reporter: jerry_soung
Component: HWPFAssignee: POI Developers List <dev>
Severity: normal    
Priority: P2    
Version: 3.5-FINAL   
Target Milestone: ---   
Hardware: All   
OS: All   
Attachments: The test document which contains a test table
Proposed patch

Description jerry_soung 2009-11-19 16:43:12 UTC
Created attachment 24569 [details]
The test document which contains a test table

Steps to Reproduce:

With the attached Word document, use the TableIterator to build the table.  Then walk through the table to print out the cell content (TableCell.text), yields the following result:

Actual Results:

0,0: Row 1/Cell 1Row 1/Cell 2
0,1: Row 1/Cell 2Row 1/Cell 3
0,2: Row 1/Cell 3

1,0: Row 2/Cell 1Row 2/Cell 2
1,1: Row 2/Cell 2Row 2/Cell 3
1,2: Row 2/Cell 3

2,0: Row 3/Cell 1Row 3/Cell 2
2,1: Row 3/Cell 2Row 3/Cell 3
2,2: Row 3/Cell 3

Expected Results:

0,0: Row 1/Cell 1
0,1: Row 1/Cell 2
0,2: Row 1/Cell 3

1,0: Row 2/Cell 1
1,1: Row 2/Cell 2
1,2: Row 2/Cell 3

2,0: Row 3/Cell 1
2,1: Row 3/Cell 2
2,2: Row 3/Cell 3
Comment 1 jerry_soung 2009-11-19 16:47:41 UTC
Created attachment 24570 [details]
Proposed patch
Comment 2 Nick Burch 2010-06-11 09:31:40 UTC
Alas your patch broke lots of other unit tests :(

Having looked through it in great detail, I can confirm that there was something wrong with the cell detection, which was worse on some files than others

The fix that seems to work best, even though it shouldn't be needed, is to create the cell from start->end paragraphs, then increment the end paragraph count on the cell later on. This seems to give the right text and offsets, along with the right counts

Fix applied to svn in r953694, along with some fairly exhaustive unit tests of the issue, which seems to show it now behaves better