Bug 121493 - RTF rendering of tables with different column width fails
Summary: RTF rendering of tables with different column width fails
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: All All
: medium normal
Assignee: Not Assigned
Keywords: bibisected, bisected, filter:rtf, regression
Depends on:
Blocks: RTF-Tables
  Show dependency treegraph
Reported: 2018-11-18 16:43 UTC by poul.steen
Modified: 2023-10-09 18:28 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:

A simple RTF file to demonstrate the bug (548 bytes, text/rtf)
2018-11-19 20:59 UTC, poul.steen
Another - more real life RTF file demonstrating the bug (178.77 KB, text/rtf)
2018-11-19 21:02 UTC, poul.steen
Picture showing correctly rendered RTF using LO (190.69 KB, image/jpeg)
2018-11-19 21:04 UTC, poul.steen
Picture showing wrongly rendered RTF using LO (144.02 KB, image/png)
2018-11-19 21:06 UTC, poul.steen

Note You need to log in before you can comment on or make changes to this bug.
Description poul.steen 2018-11-18 16:43:35 UTC
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:, 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

Actual Results:
It creates two columns with the same width despite the \cellx8108\cellx9072 keywords.

Expected Results:
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.

Reproducible: Always

User Profile Reset: Yes

Additional Info:
It worked in my LibreOffice that I replaced today with the above version.
Comment 1 Xisco Faulí 2018-11-19 17:58:58 UTC
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.
Comment 2 poul.steen 2018-11-19 20:59:24 UTC
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.
Comment 3 poul.steen 2018-11-19 21:02:55 UTC
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.
Comment 4 poul.steen 2018-11-19 21:04:57 UTC
Created attachment 146804 [details]
Picture showing correctly rendered RTF using LO
Comment 5 poul.steen 2018-11-19 21:06:04 UTC
Created attachment 146805 [details]
Picture showing wrongly rendered RTF using LO
Comment 6 poul.steen 2018-11-19 21:11:04 UTC
I have added four attachments: two RTF files demonstrating the problem, and two pictures, one showing correct rendering using LibreOffice and another showing wrong rendering using LibreOffice
Comment 7 Telesto 2018-11-19 21:30:50 UTC
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
Calc: CL
Comment 8 raal 2018-11-21 19:18:40 UTC
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
commit 464fc602746564b79d530c576354fbe148dd66ae
Author: Jenkins Build User <tdf@pollux.tdf>
Date:   Mon Dec 11 12:44:00 2017 +0100

    source 0f9a596aa853b4f2beeff25c131246a7b31492a4

author	Mike Kaganski <mike.kaganski@collabora.com>	2017-12-08 17:52:56 +0300
committer	Mike Kaganski <mike.kaganski@collabora.com>	2017-12-11 11:58:24 +0100
commit 0f9a596aa853b4f2beeff25c131246a7b31492a4 (patch)
tree 1145ce12578a21c151510dee03a5aefae9844276
parent 12efb01e38f94992ce746d20d40410229c431225 (diff)
tdf#114333: consider trleft for 1st cell width on import; don't...
Comment 9 Mike Kaganski 2018-11-22 07:55:47 UTC
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).
Comment 10 Mike Kaganski 2018-11-22 08:11:48 UTC
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).
Comment 11 Mike Kaganski 2018-11-22 08:14:38 UTC
An rtf to test when fixing this: