Bug 117268 - FILEOPEN: RTF: parser dont draw tables correctly
Summary: FILEOPEN: RTF: parser dont draw tables correctly
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.2 all versions
Hardware: All All
: medium normal
Assignee: Mike Kaganski
URL:
Whiteboard: target:6.1.0 target:5.4.7 target:6.0.5
Keywords: bibisected, bisected, filter:rtf, regression
Depends on:
Blocks: RTF-Tables
  Show dependency treegraph
 
Reported: 2018-04-27 07:42 UTC by Anton Shevtsov
Modified: 2018-05-10 01:42 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
original rtf file (288.88 KB, application/rtf)
2018-04-27 07:42 UTC, Anton Shevtsov
Details
LO 4.1.1 all work fine (198.19 KB, image/png)
2018-04-27 07:43 UTC, Anton Shevtsov
Details
LO 5 - tables damaged (190.40 KB, image/png)
2018-04-27 07:43 UTC, Anton Shevtsov
Details
LO 6 - tables damaged (214.60 KB, image/png)
2018-04-27 07:44 UTC, Anton Shevtsov
Details
wordpad in wine - ok (131.96 KB, image/png)
2018-04-27 07:45 UTC, Anton Shevtsov
Details
Minimal test case (316 bytes, application/msword)
2018-05-03 07:24 UTC, Mike Kaganski
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Anton Shevtsov 2018-04-27 07:42:01 UTC
Description:
RTF file with tables.
LibreOffice 4 - work fine, table draw correctly
LibreOffice 5,6 - all words mixed, tables not drawing.

Steps to Reproduce:
1. Opened rtf file, go to page 10 


Actual Results:  
tables are damaged

Expected Results:
i want valid tables


Reproducible: Always


User Profile Reset: No



Additional Info:
see attachments below


User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:59.0) Gecko/20100101 Firefox/59.0
Comment 1 Anton Shevtsov 2018-04-27 07:42:39 UTC
Created attachment 141671 [details]
original rtf file
Comment 2 Anton Shevtsov 2018-04-27 07:43:11 UTC
Created attachment 141672 [details]
LO 4.1.1 all work fine
Comment 3 Anton Shevtsov 2018-04-27 07:43:52 UTC
Created attachment 141673 [details]
LO 5 - tables damaged
Comment 4 Anton Shevtsov 2018-04-27 07:44:09 UTC
Created attachment 141674 [details]
LO 6 - tables damaged
Comment 5 Anton Shevtsov 2018-04-27 07:45:36 UTC
Created attachment 141675 [details]
wordpad in wine - ok
Comment 6 Xisco Faulí 2018-04-27 08:18:53 UTC
Regression introduced by:

author	Miklos Vajna <vmiklos@suse.cz>	2013-08-17 11:38:45 +0200
committer	Miklos Vajna <vmiklos@suse.cz>	2013-08-17 12:30:56 +0200
commit	b9c1a9b9aa41dbbb6bed0c77f4370ab6105c7fb1 (patch)
tree	68c3a70a739bb3ba0abeec191894140c02956ef4
parent	4f20c9f6f95c117bcdb520682df4fa1429a56477 (diff)
fdo#44715 RTF import: reset styles in tables on RTF_PARD
Commit 4a507f732d82c188ad81b022cbe3037951e58ac3 added an exception to
RTF_PARD (reset paragraph properties) handling: when we're inside a
table, it should not reset the fact that we're inside a table (which is
a paragraph property).

However, instead of just re-adding that property, it disabled resetting
for all properties, and we had a growing list of exceptions since then.
The next thing to add there would be the paragraph attributes, which
contains the style information. Instead of growing that ad-hoc list,
reset everything again and just re-add the "in table" SPRM.

This makes the second and later paragraphs in the A1 cell of the bugdoc
have proper font size.

Bisected with: bibisect-42max

Adding Cc: to Miklos Vajna
Comment 7 Anton Shevtsov 2018-05-03 04:41:58 UTC Comment hidden (no-value)
Comment 8 Mike Kaganski 2018-05-03 07:24:33 UTC
Created attachment 141855 [details]
Minimal test case

It's the minimal reproducing example. We have two tables here, first of which imports as text even in older (4.1) versions.

The problem here is that the generating software (Consultant+) puts \itap0 control word into every paragraph, even into those that are inside tables.

[RTF 1.9.1] tells about this control word:

> \itapN    Paragraph nesting level, where 0 is the main document, 1 is a
>           table cell, 2 is a nested table cell, 3 is a doubly nested table
>           cell, and so forth (default is 1).

Well, Consultant+ explicitly tells that the paragraph is *not* inside a table. This contradicts with the fact that the paragraph is inside \trowd...\cellx...\cell; and Word chooses to ignore \itap value in this contradicting case, while we choose to honor it. I am not sure it's a bug (the file is ill-formed, since it contains inconsistent information); nor that it's a regression. And I'm not sure that we should try to mimic Word's way of dealing with errors.

The Consultant+ developers seem to ignore the format specifications, but produce garbage that only test with Word to see it happens to render as they want. I believe that the proper way of dealing with this is to file the bug against Consultant+, and choose to not support creating more ill-formed documents in the wild.
Comment 9 Mike Kaganski 2018-05-03 12:15:40 UTC
https://gerrit.libreoffice.org/53790
Comment 10 Commit Notification 2018-05-03 17:30:33 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "master":

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

tdf#117268: treat erroneous \itap0 the same way as Word does

It will be available in 6.1.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 11 Anton Shevtsov 2018-05-04 04:53:59 UTC
i downloaded 6.1alpha from https://dev-builds.libreoffice.org/daily/master/Linux-rpm_deb-x86_64@70-TDF/2018-05-04_01.13.51/

all working fine!
Comment 12 Mike Kaganski 2018-05-04 06:05:55 UTC
Pending:

- backport to 6-0: https://gerrit.libreoffice.org/53813
- backport to 5-4: https://gerrit.libreoffice.org/53834
Comment 13 Xisco Faulí 2018-05-04 08:55:29 UTC
Verified in

Version: 6.1.0.0.alpha1+
Build ID: 213f12be2cab2106dde4a0e859faaa8259627c1a
CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); Calc: group

@Mike, Thanks for fixing this!!
Comment 14 Commit Notification 2018-05-04 09:42:09 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "libreoffice-5-4":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=aa51623f7a8a11e0701913a34eab8c0a11316733&h=libreoffice-5-4

tdf#117268: treat erroneous \itap0 the same way as Word does

It will be available in 5.4.8.

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 15 Commit Notification 2018-05-04 15:29:38 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "libreoffice-6-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=fe3ddff71af9298cc389ce05f6c1474bc0aeb715&h=libreoffice-6-0

tdf#117268: treat erroneous \itap0 the same way as Word does

It will be available in 6.0.5.

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 16 Commit Notification 2018-05-09 08:26:22 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "libreoffice-5-4-7":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=6f1781cb1e0209aa2d2fcaaf4f1adbd4c36d7f54&h=libreoffice-5-4-7

tdf#117268: treat erroneous \itap0 the same way as Word does

It will be available in 5.4.7.

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.