Bug Hunting Session
Bug 44986 - FILEOPEN: Imported RTF - table cell/row widths wrongly imported
Summary: FILEOPEN: Imported RTF - table cell/row widths wrongly imported
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.5.0 RC1
Hardware: Other All
: medium normal
Assignee: Miklos Vajna
URL:
Whiteboard: target:5.3.0 target:5.2.2 target:5.2....
Keywords: filter:rtf
Depends on:
Blocks: RTF-Tables
  Show dependency treegraph
 
Reported: 2012-01-20 05:30 UTC by Tobias Burnus
Modified: 2019-12-09 13:24 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tobias Burnus 2012-01-20 05:30:06 UTC
The RTF file http://www.dfg.de/formulare/10_03/10_03_rtf.rtf contains many tables.

In Word (Office 2003), the first two cells (one cell per row) does not extend the whole page width but only ~5.75 cm. That's the cell "DFG-Geschäftszeichen" and the cell below it.
In LO 3.5.0rc1, the first two cells/rows extend over the whole page width.

A similar issue exists for item "5.". In Word, the "5." is at the same margin position as the "1." to "4.". In the same line, the first row of the table follows, while the first two rows nicely match in width and position of the vertical border between the two cells in each row.
By contrast, in LO the "5." is further to right (where the first cell should have been) - while the first row starts even later and thus only covers half the table width of the succeeding table rows.


Additionally, the width of the border looks rather different (in all zoom levels). In Word it looks about 3/4 as thin as in LO. Word claims a border width of "3/4 pt" while LO claims "0.75 pt" - thus, the width should be the same ...
Comment 1 s-joyemusequna 2012-01-20 11:06:54 UTC
Confirmed with LibO 3.5 Beta3 and Windows Vista.

But a *giant* amelioration compared with LibO 3.4.4, where the result is totally unusable.
Comment 2 Jean-Baptiste Faure 2012-03-20 23:22:28 UTC
WordPad under Ubuntu/Wine shows the 5. at the same position as LO 3.5, that is in the first cell of Table6. Numbers 1 to 4 are normal paragraphs. So where is the bug ? In MS-Word or LO ? ;-)

That said, Wordpad confirms the problem with the size of the two first cells. But I do not know if it possible to have a non rectangular table in LibreOffice.

@Miklos : what do you think about that ?

Best regards. JBF
Comment 3 Teo91 2013-09-29 13:29:53 UTC
Cell/Rows width is imported correctly with LO 4.1.1. on Windows 7 SP1 and the whole document appears quite good, but:
- the "5." is still further to right
- the "6." does the same
- there are mistakes like checkboxes not visible and incorrect fonts bold
Comment 4 Teo91 2013-09-29 13:36:44 UTC
Notice: the "5." and "6." items are shown correctly on AOO 4.0
Comment 5 Alexandr 2014-08-07 12:56:31 UTC
Reproducible with LibreOffice 4.2.5 and 4.3.0 on Debian. I see 3 issues:
1) incorrect width of the first 2 cells;
2) incorrect position of 5. and 6. ;
3) no checkboxes in 6. and 8.
Comment 6 Alexandr 2014-08-07 14:13:39 UTC
> 3) no checkboxes in 6. and 8.
The issue with checkboxes is reported as bug 44984.
Comment 7 tommy27 2014-12-12 10:28:29 UTC
(In reply to Alexandr from comment #5)
> Reproducible with LibreOffice 4.2.5 and 4.3.0 on Debian. I see 3 issues:
> 1) incorrect width of the first 2 cells;
> 2) incorrect position of 5. and 6. ;

still reproducible with LO 4.3.4.1 under Win7x64
Comment 8 Robinson Tryon (qubit) 2015-12-10 01:08:25 UTC Comment hidden (obsolete)
Comment 9 Miklos Vajna 2015-12-22 22:08:50 UTC
Reset Assignee to default till I actually start looking into this.
Comment 10 Miklos Vajna 2016-08-19 22:09:38 UTC
I had a look at this again, this is still a problem even for docx, so probably better to fix that first. In docx this is about the gridBefore/gridAfter elements, gridBefore is handled by cf33af732ed0d3d553bb74636e3b14c55d44c153. I'll look at extending that to also handle gridAfter. Once that's done, something similar can be done in the rtf tokenizer.
Comment 11 Commit Notification 2016-08-30 08:41:18 UTC
Miklos Vajna committed a patch related to this issue.
It has been pushed to "master":

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

Related: tdf#44986 DOCX import: handle w:gridAfter by faking cells

It will be available in 5.3.0.

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.
Comment 12 Cor Nouws 2016-08-30 12:36:11 UTC
@Miklos: linked to two possible duplicates - will test soon
Comment 13 Cor Nouws 2016-09-01 09:57:56 UTC
I don't see a difference in build  c780c6726dca5e2fe33297e44f25ae3e00703294
compared to 5.2.1.2
Comment 14 Cor Nouws 2016-09-01 10:00:23 UTC
(In reply to Cor Nouws from comment #13)
> I don't see a difference in build  c780c6726dca5e2fe33297e44f25ae3e00703294
> compared to 5.2.1.2

but I'm too fast with looking at rtf, since the fix referred in comment #11 is for docx.
Comment 15 Cor Nouws 2016-09-01 10:07:18 UTC
a ~similar issue for docx does show a much better result with this build.
See https://bugs.documentfoundation.org/show_bug.cgi?id=41468#c23
Comment 16 Commit Notification 2016-09-06 12:15:12 UTC
Miklos Vajna committed a patch related to this issue.
It has been pushed to "master":

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

tdf#44986 RTF import: handle \trwWidthA by faking cells

It will be available in 5.3.0.

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.
Comment 17 Commit Notification 2016-09-06 19:48:00 UTC
Miklos Vajna committed a patch related to this issue.
It has been pushed to "libreoffice-5-2":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=0ba2229a57527e78f237119efa413f122c9ca74b&h=libreoffice-5-2

Related: tdf#44986 DOCX import: handle w:gridAfter by faking cells

It will be available in 5.2.2.

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.
Comment 18 Commit Notification 2016-09-09 10:52:58 UTC
Miklos Vajna committed a patch related to this issue.
It has been pushed to "libreoffice-5-2":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=246df61b34e1ff5b5d7ecf7e46f04bb677548c9a&h=libreoffice-5-2

tdf#44986 RTF import: handle \trwWidthA by faking cells

It will be available in 5.2.3.

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.
Comment 19 Commit Notification 2019-12-08 14:55:21 UTC
László Németh committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/b2c6d2d961a6113d0f111fab45ae12a40d389a23

fdo#38414 tdf#44986: DOCX table import: handle gridBefore/After

It will be available in 6.5.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 20 Commit Notification 2019-12-09 07:26:56 UTC
László Németh committed a patch related to this issue.
It has been pushed to "libreoffice-6-4":

https://git.libreoffice.org/core/commit/25240856843444f1dac489f73ad058fad1b1d456

fdo#38414 tdf#44986: DOCX table import: handle gridBefore/After

It will be available in 6.4.0.1.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 21 Tobias Burnus 2019-12-09 08:27:27 UTC
(In reply to Tobias Burnus from comment #0)
> The RTF file http://www.dfg.de/formulare/10_03/10_03_rtf.rtf contains many
> tables.

I just saw that this is no longer available there, however, it is at
https://web.archive.org/web/20170628024552/http://www.dfg.de/formulare/10_03/10_03_rtf.rtf – thanks to the Wayback machine.

(In reply to Commit Notification from comment #20)
> László Németh committed a patch related to this issue.
> fdo#38414 tdf#44986: DOCX table import: handle gridBefore/After
> It will be available in 6.4.0.1.

Thanks  (although, I did not have the change to test it, yet)
Comment 22 Timur 2019-12-09 13:24:08 UTC
I tested again with this fix and it's still OK.

There are some differences in details but that doesn't affect bug status.
Like, "DFG-Geschäftszeichen" row is not full table size, I guess there's another bug for that. 
Or, numbers 5., 6., 10. are differently positioned because of additional cell in MSO.