Bug 121642 - RTF rendering fails to neutralize indention using \li0 in a table with a shape
Summary: RTF rendering fails to neutralize indention using \li0 in a table with a shape
Status: RESOLVED INVALID
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.1.2.1 release
Hardware: All All
: high major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: filter:rtf
Depends on:
Blocks: RTF-Tables
  Show dependency treegraph
 
Reported: 2018-11-22 21:14 UTC by poul.steen
Modified: 2018-12-05 14:25 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
RTF file demonstrating the lack of neutralizing indention using \li0 (17.99 KB, text/rtf)
2018-11-22 21:24 UTC, poul.steen
Details
Picture showing how the RTF rendering was expected (119.53 KB, image/png)
2018-11-22 21:26 UTC, poul.steen
Details
Picture showing how the RTF rendering works in version 6.1.3.2 (120.52 KB, image/png)
2018-11-22 21:29 UTC, poul.steen
Details

Note You need to log in before you can comment on or make changes to this bug.
Description poul.steen 2018-11-22 21:14:19 UTC
Description:
In a row with two cells the text in the first cell is indented using th \li control word - works fine. In the second cell a shape (with a picture) is to be shown with no indention using \li0. This works fine in version 5.3.7.2, while the neutralization of the indention appears to be ignored in version 6.1.3.2.

Steps to Reproduce:
1.Create a table with two cells using \trowd\trql\trkeep\intbl\trleft0\cellx8108\cellx9072
2.Indent the text in the first cell using \li567
3.Remove the indention in the second cell using \li0 and include a shape with a picture in the second cell

Actual Results:
The shape is indented despite the \li0 - a text in second cell will NOT be indented, so apparently the problem is only for shapes.

Expected Results:
The text in the first cell should be indented while the shape with the picture in the second cell should NOT be indented as the indention should have been neutralized by the  \li0 control word


Reproducible: Always


User Profile Reset: Yes



Additional Info:
The RTF rendering is working as expected in version 5.3.7.2 (my previous version), while the new version 6.1.3.2. shows the problem.
Comment 1 poul.steen 2018-11-22 21:24:31 UTC
Created attachment 146923 [details]
RTF file demonstrating the lack of neutralizing indention using \li0

This RTF file contains a table with two rows with some indented text in the left column (indented 567 twips using the control word "\\li567"). At the end of the cell, 
this indention is neutralized both using  the "\\li0" control word, which should be enough, and in addition using the control word sequence "\\par\\pard" to ensure the picture in the next cell is NOT indented. 
This works perfectly in version 5.3.7.2, while the neutralization of the indention appears to be ignored in version 6.1.3.2. See the two pictures in the next two attachments
Comment 2 poul.steen 2018-11-22 21:26:42 UTC
Created attachment 146924 [details]
Picture showing how the RTF rendering was expected

Picture of the correct rendering of the attached RTF file using LibreOffice Write version 5.3.7.2
Comment 3 poul.steen 2018-11-22 21:29:06 UTC
Created attachment 146925 [details]
Picture showing how the RTF rendering works in version 6.1.3.2

Picture of the incorrect rendering of the attached RTF file using LibreOffice Write version 6.1.3.2
Comment 4 Alex Thurgood 2018-11-28 09:23:31 UTC
Correct image placement in 
Version: 6.0.6.2
Build ID: 0c292870b25a325b5ed35f6b45599d2ea4458e77
Threads CPU : 4; OS : Mac OS X 10.14.1; UI Render : par défaut; 
Locale : fr-FR (fr_FR.UTF-8); Calc: group

Incorrect placement in

Version: 6.1.2.1
Build ID: 65905a128db06ba48db947242809d14d3f9a93fe
Threads CPU : 4; OS : Mac OS X 10.14.1; UI Render : par défaut; 
Locale : fr-FR (fr_FR.UTF-8); Calc: group threaded

CONFIRMING ===> regression
Comment 5 Aron Budea 2018-12-03 10:00:05 UTC
This is actually OS-independent, and can be reproduced on Win and Linux as well (in MS Word the picture isn't shown, though). Bibisected to the following commit using repo bibisect-mac64-6.2. Adding Cc: to Miklos Vajna, please take a look.

https://cgit.freedesktop.org/libreoffice/core/commit/?id=0c91f8f839d36c8b5af272b1d3c835d2f4af6b65
author		Miklos Vajna <vmiklos@collabora.co.uk>	2018-07-16 22:04:02 +0200
committer	Miklos Vajna <vmiklos@collabora.co.uk>	2018-07-17 09:03:42 +0200

tdf#81943 sw RTF import: fix missing wrap in background for in-table shape
Comment 6 Miklos Vajna 2018-12-04 14:39:24 UTC
Opening the sample in Word, there is no image at all. Can you please attach a sample which is a valid RTF (Word accepts it) and reproduces the problem?
Comment 7 Miklos Vajna 2018-12-04 14:46:52 UTC
Additionally, it seems to me that \shpleft567 explicitly asks positioning from the left edge of the paragraph area (567 twips). This was indeed ignored in the past, but that was a bug. So I would say unless it's possible to came up with a document where Word rendering matches your wish, this is not even a bug. Just set \shpleft to 0 if you want no left indent for your shape.

For now I leave this bug open, but I remove the regression keyword: feel free to add it back if the request turns out to match Word's behavior.
Comment 8 poul.steen 2018-12-05 11:20:44 UTC
@ comment from Miklos Vajna 2018-12-04 14:39:24 UTC ("Can you please attach a sample which is a valid RTF (Word accepts it) and reproduces the problem?"):
I used to code RTF to be rendered using MS word, but unfortunately, I do not have MS Word any more, so I cannot test it there. That is why I use LibreOffice.
Comment 9 poul.steen 2018-12-05 11:30:34 UTC
@ comment from Miklos Vajna 2018-12-04 14:46:52 UTC:
I accept that it must have been a bug in my previous version of LibreOffice (5.3.7.2) that the \in0 did neutralize the indention for the shape, even though I explicitly specified \shpleft567 related to the paragraph.
Therefore, that previous bug have now been solved in version 6.1.3.2, which is fine.
So, I hereby withdraw this bug (121642), realizing I was wrong. I apologize for the confusion!
Comment 10 Miklos Vajna 2018-12-05 14:25:32 UTC
No problem, I'm glad that we agree here. :-)