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)
Version:
(earliest affected)
7.4.0.0 alpha0+
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Frame RTF-Frame
  Show dependency treegraph
 
Reported: 2022-04-13 11:51 UTC by Xisco Faulí
Modified: 2025-04-09 10:47 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


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

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: 7.4.0.0.alpha0+ / 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?
Comment 5 QA Administrators 2024-04-15 03:15:28 UTC Comment hidden (obsolete)
Comment 6 Gabor Kelemen (allotropia) 2025-04-09 10:47:34 UTC
Still valid in

Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 22ef238e820955f6f8ac84781289b8a1d8e477b9
CPU threads: 14; OS: Windows 10 X86_64 (build 19045); UI render: Skia/Raster; VCL: win
Locale: hu-HU (hu_HU); UI: en-US
Calc: threaded