Bug 87218 - FILEOPEN: table displayed in wrong position in .rtf
Summary: FILEOPEN: table displayed in wrong position in .rtf
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
3.5.0 release
Hardware: All All
: medium normal
Assignee: Not Assigned
Whiteboard: interoperability
Keywords: filter:rtf, preBibisect, regression
Depends on:
Blocks: RTF-Tables RTF-New-Import
  Show dependency treegraph
Reported: 2014-12-11 06:30 UTC by tommy27
Modified: 2023-03-06 04:23 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description tommy27 2014-12-11 06:30:09 UTC
donwload this .rtf ( attachment 110638 [details] ) from Bug 87165
and compare with .pdf version ( attachement 110639 ) 

let's focus on the green arrow in the screenshot ( attachment 110714 [details] )
the table on the bottom right displayed at bottom left

maybe it's a similar issue as the one described here at:
Bug 69782 - FILEOPEN RTF Table in frame displayed in wrong place
Comment 1 Joel Madero 2014-12-12 05:32:42 UTC

Libreoffice release

Setting to:
Normal - prevents high quality work
Low - Lowering as rtf isn't incredibly popular as this is a very specific test case. Unclear if this will impact many users at all.
Comment 2 Ivan 2014-12-12 06:50:48 UTC
hi Joel Madero

In this case you aren't right.
Impossibility it is correct to work with bank documents I led to that LO was necessary to remove and install MO.
In Russia, many banking systems use the rtf format for export. Impossibility of LO to work with it, do LO unnecessary for business.
(Personally it very much disturbs me and upsets).

Невозможность корректно отобразить банковский документ (3 ошибки в нём), привела к тому, что пришлось удалить LO и установить MO.
В России, многие банковские системы используют для экспорта формат rtf. Невозможность LO с ним работать, делают LO ненужным для бизнеса.
(Лично меня это очень беспокоит и расстраивает).
Comment 3 tommy27 2014-12-12 10:32:07 UTC
I agree with Ivan.

IMHO the .rtf format really sucks, however it is still very used in many countries (not only Russia but also Italy) and bad interoperability can prevent LibO diffusion.

I added this bug and it's fellow bugs to " Bug 81234 - [META] RTF filter issues " to give them more visibility
Comment 4 A (Andy) 2015-04-06 19:46:28 UTC
Reproducible with LO, Win 8.1: subtable shown at the wrong position
Comment 5 tommy27 2015-06-16 21:07:28 UTC
still present in and recent
Comment 6 Robinson Tryon (qubit) 2015-12-10 01:08:29 UTC Comment hidden (obsolete)
Comment 7 tommy27 2016-10-05 07:55:56 UTC
still present in
Build ID: 4c70a1a6666a079872b8f1966bd398e924dc1d1a
CPU Threads: 8; OS Version: Windows 6.1; UI Render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2016-09-22_06:54:24
Locale: it-IT (it_IT); Calc: CL
Comment 8 Xisco Faulí 2016-10-08 15:24:27 UTC
I can already reproduce it in Version (Build ID: efca6f15609322f62a35619619a6d5fe5c9bd5a). However, I can't reproduce it in Libreoffice 3.3, thus, this is a regression.
Comment 9 Aron Budea 2017-01-04 20:54:09 UTC
Table already appears on the left side in / Ubuntu 16.04.
Comment 10 tommy27 2018-01-09 05:23:30 UTC
still repro with and
Build ID: acb43c0b8efbfb841e7b40603d75a8432eb21f21
CPU threads: 4; OS: Windows 6.3; UI render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2018-01-08_23:05:27
Locale: it-IT (it_IT); Calc: group threaded
Comment 11 Buovjaga 2018-06-27 17:41:06 UTC
(In reply to Aron Budea from comment #9)
> Table already appears on the left side in / Ubuntu 16.04.

The text
 БИК 044585777 
к/с 30101810800000000777

is not inside a table cell in the oldest of 43all bibisect repo. In 3.3 it is still inside a cell.
Comment 12 QA Administrators 2019-06-28 02:58:49 UTC Comment hidden (obsolete)
Comment 13 Svatopluk Vít 2021-03-01 11:13:40 UTC
The bug is still present

Version: / LibreOffice Community
Build ID: 575c5867c4cc13d7ae78f9ce39a54a52ed38c769
CPU threads: 8; OS: Linux 5.10; UI render: default; VCL: kf5
Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US
Calc: threaded
Comment 14 QA Administrators 2023-03-06 04:23:27 UTC
Dear tommy27,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)

If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword

Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team