Description: When LibreOffice writer opens and reads RTF files, the \marg left, right, top, bottom commands are ignored when a subsequent \page command is added. The result is that default margins are used instead of the specified margins. If the subsequent \page command is omitted, the specified margins are used. The \page command causing the problem is NOT the first \page command but if it is omitted from the .rtf file, the margins are correctly rendered. I have attached files showing the problem: margin-failure.rtf margin-failure-Screenshot.png showing the RTF input and output failure with a \page command margin-ok.rtf margin-ok-Screenshot.png showing the RTF input and output correctly without the \page command. The two .rtf files are identical except for the \page command which causes the failure. Processing RTF files with unoconv has the same problem! My system is as follows: ads@ADS4:~$ uname -a Linux ADS4 6.9.9-100.fc39.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Jul 11 19:26:10 UTC 2024 x86_64 GNU/Linux ads@ADS4:~$ ads@ADS4:~$ soffice --version LibreOffice 7.6.7.2 60(Build:2) ads@ADS4:~$ unoconv --version unoconv 0.9.0 Written by Dag Wieers <dag@wieers.com> Homepage at http://dag.wieers.com/home-made/unoconv/ platform posix/linux python 3.12.4 (main, Jun 7 2024, 00:00:00) [GCC 13.3.1 20240522 (Red Hat 13.3.1-1)] LibreOffice 7.6.7.2 ads@ADS4:~$ Steps to Reproduce: 1. generate RTF file with \page command 2. open .rtf file with LibreWriter (soffice) or unoconv 3. 2. 3. Actual Results: \marg[lrtb]N commands are ignored and margins are incorrectly set to some default. Expected Results: \marg[lrtb]N commands are honored and margins are correctly set as specified. Reproducible: Always User Profile Reset: No Additional Info: Version: 7.6.7.2 (X86_64) Build ID: 60(Build:2) CPU threads: 6; OS: Linux 6.9; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded If you open the .rtf files with a text editor, you will see they differ only in the \page command. The \page command that causes the problem is NOT the first \page command in the .rtf file. If you open the .rtf files with LibreWriter (soffice) you will see the difference in the margins. I should add that the failing file 'margin-failure.rtf' displays margins correctly using LibreOffice on Windows 10.
Created attachment 195690 [details] RTF file causing normal expected margin behavior
Created attachment 195691 [details] Screenshot showing normal expected margins
Created attachment 195692 [details] RTF file causing incorrect margin behavior with \page command
Created attachment 195693 [details] Screenshot showing incorrect margins due to \page command
Fedora 40 with LibreOffice 24.2.2.1 420(Build:1) exhibits the same rtf margin failure following the 3rd \page command. liveuser@localhost-live:~$ uname -a Linux localhost-live 6.8.5-301.fc40.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Apr 11 20:00:10 UTC 2024 x86_64 GNU/Linux liveuser@localhost-live:~$ liveuser@localhost-live:~$ libreoffice --version LibreOffice 24.2.2.1 420(Build:1)
With help from developers, using bibisect, I was able to determine that the bug was introduced between 7.5.10.0.0 and 7.6.8.0.0. 7.4.8 is good 7.5.10.0.0 is good 7.6.7.2 is bad 7.6.8.0.0 is bad
Confirm with Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: ccdf1096a6103d2ab8690e8e97dcf3496160ecff CPU threads: 4; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US Calc: threaded Works in 7.3.7, regression
This seems to have begun at the below commit in bibisect repository/OS linux-64-7.6$. Adding Cc: to Michael Stahl ; Could you possibly take a look at this one? Thanks b95dfc8c9d34ef6d66206216b258094942102e7f is the first bad commit commit b95dfc8c9d34ef6d66206216b258094942102e7f Author: Jenkins Build User <tdf@lilith.documentfoundation.org> Date: Thu Feb 1 12:51:55 2024 +0100 source e63a75e00dcd797b0bd061add3c72dcb7b353007 162846: tdf#158586 writerfilter: RTF import: fix \page \sect \skbnone | https://gerrit.libreoffice.org/c/core/+/162846