Bug 148559 - FILESAVE: RTF: Border lost after RT
Summary: FILESAVE: RTF: Border lost after RT
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) alpha0+
Hardware: All All
: medium normal
Assignee: Not Assigned
Keywords: bibisected, bisected, regression
Depends on:
Blocks: RTF Frame
  Show dependency treegraph
Reported: 2022-04-13 11:51 UTC by Xisco Faulí
Modified: 2022-04-15 20:48 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:
Regression By:

Before vs After the RT (283.23 KB, image/png)
2022-04-13 11:51 UTC, Xisco Faulí
Reduced version of attachment 50625 (30.03 KB, application/zip)
2022-04-15 20:48 UTC, Regina Henschel

Note You need to log in before you can comment on or make changes to this bug.
Description Xisco Faulí 2022-04-13 11:51:22 UTC
Created attachment 179516 [details]
Before vs After the RT

Steps to reproduce:
1. Open attachment 50625 [details] from bug 40428
2. Save it to RTF
3. Reopen

-> The border of the first frame is gone. See Comparison

Reproduced in

Version: / LibreOffice Community
Build ID: 9877a0190e43241f4a5102e5d9cc7181f91d5a6f
CPU threads: 8; OS: Linux 5.10; UI render: default; VCL: gtk3
Locale: es-ES (es_ES.UTF-8); UI: en-US
Calc: threaded

[Bug found by office-interoperability-tools]
Comment 1 Xisco Faulí 2022-04-13 11:52:27 UTC
Regression introduced by:

author	Regina Henschel <rb.henschel@t-online.de>	2022-02-01 20:38:07 +0100
committer	Miklos Vajna <vmiklos@collabora.com>	2022-02-02 08:38:11 +0100
commit 9877a0190e43241f4a5102e5d9cc7181f91d5a6f (patch)
tree 187b8c68c6e9bb76d2e5f676cbc672e40781867f
parent ea23f640d3bf06e4035a96ebe8b8c07a59d6f12c (diff)
tdf#107727 disable border in RTF export if not drawn

Bisected with: bibisect-linux64-7.4

Adding Cc: to Regina Henschel
Comment 2 Regina Henschel 2022-04-13 14:58:43 UTC
I think, the reason is not directly my patch. It looks as if somewhere the interpretation of the default value for RTF property "fLine" has changed/is missing.

The border will be drawn, if I explicitly set
m_aFlyProperties.push_back(std::make_pair<OString, OString>("fLine", "1"));

But that should not be necessary because "True" is the default for "fLine".
Comment 3 Regina Henschel 2022-04-13 18:19:39 UTC
I have added that line in https://ci.libreoffice.org/job/gerrit_master/112365/

But I cannot generate a reduced document from scratch which fails without the patch. What is special about the text box in the failing document?
Comment 4 Regina Henschel 2022-04-15 20:48:32 UTC
Created attachment 179599 [details]
Reduced version of attachment 50625 [details]

I have reduced attachment 50625 [details] to the affected object.

The patch will force the object to a default line. But I think, there is a principle problem:

The object is not a text box (as I thought first) but it is a frame. When Word exports docx to RFT, it sets the borders as paragraph borders. For such RTF-document made by Word, LibreOffice renders the borders same as Word. LO converts the paragraph group to a Frame.

But when LO converts the docx document to RTF it generates a shape and enables default "stroke" of the shape. It does not consider border color and border width. So there is a principle shortcoming in exporting such object from docx to rtf.

Should we nevertheless use the patch?