I have been using LibreOffice to open rtf files with tables, e.g. defined as follows:
\trowd\trql\trkeep\intbl\cellx8108\cellx9072\trleft0\fs20, specifying a row with two cells, the first starting 0 twips from left marging and ending 8108 twips from same margin, the second ending at 9072 twips (happened to be right margin).
This worked neatly with version 5, but with the newly downloaded Version: 220.127.116.11, LibreOffice ignores the measures and creates two equally wide cell in stead.
Steps to Reproduce:
1.Type this code in an RTF file:
Text in first cell
Text in the second cell
2.Open the file with LibreOffice
It creates two columns with the same width despite the \cellx8108\cellx9072 keywords.
The \trowd\trql\intbl\cellx8108\cellx9072\trleft0 sequence should create a table with a very wide first column (8108 twips wide) and a narrow second column (966 twips wide) as defined in the two \cellx keywords.
User Profile Reset: Yes
It worked in my LibreOffice 18.104.22.168 that I replaced today with the above version.
Thank you for reporting the bug. Please attach a sample document, as this makes it easier for us to verify the bug.
(Please note that the attachment will be public, remove any sensitive information before attaching it.
See https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F for help on how to do so.)
I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided.
Created attachment 146802 [details]
A simple RTF file to demonstrate the bug
Apart from the text in the cells, this RTF file is containing the minimum RTF control words to demonstrate the bug - as written in my original report.
Created attachment 146803 [details]
Another - more real life RTF file demonstrating the bug
This is the type of RTF file in which I originally realized the problem. The text content is already public and available on the net.
Created attachment 146804 [details]
Picture showing correctly rendered RTF using LO 22.214.171.124
Created attachment 146805 [details]
Picture showing wrongly rendered RTF using LO 126.96.36.199
I have added four attachments: two RTF files demonstrating the problem, and two pictures, one showing correct rendering using LibreOffice 188.8.131.52 and another showing wrong rendering using LibreOffice 184.108.40.206
Build ID: d71ea82055a6a304493c7eaa90809a348e23784d
CPU threads: 4; OS: Windows 6.3; UI render: GL; VCL: win;
TinderBox: Win-x86@42, Branch:master, Time: 2018-11-19_03:25:07
Locale: nl-NL (nl_NL); UI-Language: en-US
This seems to have begun at the below commit.
Adding Cc: to Mike Kaganski ; Could you possibly take a look at this one?
464fc602746564b79d530c576354fbe148dd66ae is the first bad commit
Author: Jenkins Build User <email@example.com>
Date: Mon Dec 11 12:44:00 2017 +0100
author Mike Kaganski <firstname.lastname@example.org> 2017-12-08 17:52:56 +0300
committer Mike Kaganski <email@example.com> 2017-12-11 11:58:24 +0100
commit 0f9a596aa853b4f2beeff25c131246a7b31492a4 (patch)
parent 12efb01e38f94992ce746d20d40410229c431225 (diff)
tdf#114333: consider trleft for 1st cell width on import; don't...
A note for myself or for anyone who wants to jump in:
the code (both current, and before https://git.libreoffice.org/core/+/0f9a596aa853b4f2beeff25c131246a7b31492a4) assumes that \trleftN goes before all \cellxN. That is, of course, false. So the processing of cellx, trleft, and row control words (in writerfilter/source/rtftok/rtfdispatchvalue.cxx and writerfilter/source/rtftok/rtfdispatchsymbol.cxx) needed to first collect all cell border positions, and only then calculate cell widths (which is now done right upon arrival of cellx, which leads to incorrect results after non-0 trleft arrives last).
I abandoned an early experiment at https://gerrit.libreoffice.org/63774. Anyone interested - please feel free to jump in (I am unlikely to be able to handle this this year).
An rtf to test when fixing this: