Bug 44053 - some columns are misplaced in table
Summary: some columns are misplaced in table
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.5.0 Beta1
Hardware: Other All
: medium normal
Assignee: Miklos Vajna
URL:
Whiteboard: target:4.1.0
Keywords:
Depends on:
Blocks:
 
Reported: 2011-12-22 05:45 UTC by Markus Mohrhard
Modified: 2013-02-05 21:22 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
file showing the bug (37.40 KB, application/rtf)
2011-12-22 05:45 UTC, Markus Mohrhard
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Markus Mohrhard 2011-12-22 05:45:07 UTC
Created attachment 54694 [details]
file showing the bug

In the attached document the column entry Cell1 should be directly below Name.

Word shows this document correctly.
Comment 1 Miklos Vajna 2011-12-28 12:11:14 UTC
Confirmed - here is my analysis so far:

The problem is that the first row has two columns, while the second has four, but the document contains no merge control words (\clmrg). It seems that Word writes tables like this when the horizontal span of a cell is grather than 1.

The docx version of this document is imported properly, as there the docx has a table with 4 columns and has the proper span declarations, so the number of cols does not differ in the two rows.

Now what we support is different number of cells in rows, but the width of such cells is parsed only in the first row by dmapper. Given this fact, the tokenizer doesn't even send the width of cells in non-first rows, that's what RTFDocumentImpl::m_bFirstRow does. So sending the info that is not shown, but should be shown is a oneliner change in the tokenizer, but then the dmapper part is harder, since docx doesn't need this feature.

BTW, of course it's possible to add heuristics in the tokenizer to reconstruct the spans when it makes sense, but that would mean keeping the whole table in the memory at the tokenizer level. (Right now we keep a row in the memory, but Cedric has plans to remove even that to have nothing table-related buffered at a tokenizer level.)
Comment 2 Miklos Vajna 2012-01-05 07:59:21 UTC
Minimal reproducer:

{\rtf1
\trowd \cellx1000\cellx4000
\pard\plain\intbl
A1\cell B1-C1\cell\row 
\trowd \cellx1000\cellx2500\cellx4000
\pard\plain\intbl  
A2\cell B2\cell C2\cell\row
\pard\plain\par
}

The bug is that the A2 cell is wider than A1, while they should have the same width.
Comment 4 Not Assigned 2013-01-14 16:56:41 UTC
Miklos Vajna committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=d276d3f3ae112a11c8cb5768650d147cbb94275e

fdo#44053 fix this again and this time add a testcase as well



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.