Compare the following three rtf documents: {\rtf\ansi\deff0{\pard before \par\trowd\trautofit1\trgaph108 \cellx \cellx \pard \intbl 1 \cell \pard \intbl 2 \cell \row \pard after}} {\rtf\ansi\deff0{\pard before \par\trowd\trautofit1\trgaph108 \cellx0 \cellx0 \pard \intbl 1 \cell \pard \intbl 2 \cell \row \pard after}} {\rtf\ansi\deff0{\pard before \par\trowd\trautofit1\trgaph108 \cellx500 \cellx1000 \pard \intbl 1 \cell \pard \intbl 2 \cell \row \pard after}} Only in the final one is the text in the table visible in Libreoffice (the dev version 5.2.4.0.0+ and also version 5.0.6.2). In Word Viewer, the text is visible in all three tables.
Created attachment 128788 [details] First test case
Created attachment 128789 [details] Second test case
Created attachment 128790 [details] Third test case
Created attachment 128791 [details] Expected behaviour (Word Viewer)
Created attachment 128792 [details] Actual behaviour (LibreOfficeDev)
Confirmed. 3.5 froze when trying to open case1. 4.1.6.2 showed a table in case2, but it was so wide it went outside the page and only the cell with "1" was shown. Case1 was shown with "1" and "2" simply as paragraphs. Win 7 Pro 64-bit Version: 5.3.0.0.alpha1+ Build ID: 172325bedf69bbc162f3c1948264451c90c105a3 CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; Layout Engine: new; TinderBox: Win-x86@39, Branch:master, Time: 2016-11-21_05:26:40 Locale: fi-FI (fi_FI); Calc: group
** Please read this message in its entirety before responding ** 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 http://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://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
till repro in Version: 6.2.0.0.alpha0+ Build ID: 1aa37aa6bee19099b57555a6d839992b054aa405 CPU threads: 4; OS: Windows 10.0; UI render: GL; TinderBox: Win-x86@42, Branch:master, Time: 2018-09-23_10:17:54 Locale: ru-RU (ru_RU); Calc: threaded
Dear rupert.levene, 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 http://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://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
(In reply to QA Administrators from comment #9) Yes, the bug is still present: Version: 6.4.3.2 Build ID: 747b5d0ebf89f41c860ec2a39efd7cb15b54f2d8 CPU threads: 4; OS: Mac OS X 10.11.6; UI render: default; VCL: osx; Locale: en-IE (en.UTF-8); UI-Language: en-US Calc: threaded
Still reproducible in 7.0.6.2, with slightly altered behaviour: both case1.rtf and case2.rtf appear as in the middle window in the "Actual behaviour" screenshot of the original bug report. That is, case1.rtf does now correctly import with a table, but as in case2.rtf, the cell widths are chosen absurdly small and their content cannot be seen. I exported the files from Writer as odt files and unzipped them. content.xml is identical for case1 and case2 content.xml is different for case2 and case3. After pretty-printing and diffing, I get this: ==== $ diff -uw case{2,3}.xml --- case2.xml 2021-07-05 09:57:31.000000000 +0100 +++ case3.xml 2021-07-05 09:57:43.000000000 +0100 @@ -11,13 +11,13 @@ </office:font-face-decls> <office:automatic-styles> <style:style style:name="Table1" style:family="table"> - <style:table-properties style:width="0.145cm" fo:margin-left="-0.191cm" fo:margin-top="0cm" fo:margin-bottom="0cm" table:align="left"/> + <style:table-properties style:width="3.528cm" fo:margin-left="-0.191cm" fo:margin-top="0cm" fo:margin-bottom="0cm" table:align="left"/> </style:style> <style:style style:name="Table1.A" style:family="table-column"> - <style:table-column-properties style:column-width="0.072cm"/> + <style:table-column-properties style:column-width="1.764cm"/> </style:style> <style:style style:name="Table1.B" style:family="table-column"> - <style:table-column-properties style:column-width="0.071cm"/> + <style:table-column-properties style:column-width="1.762cm"/> </style:style> <style:style style:name="Table1.1" style:family="table-row"> <style:table-row-properties fo:keep-together="auto"/> ==== Version: 7.0.6.2 Build ID: 144abb84a525d8e30c9dbbefa69cbbf2d8d4ae3b CPU threads: 4; OS: Mac OS X 10.13.6; UI render: default; VCL: osx Locale: en-IE (en_IE.UTF-8); UI: en-US Calc: threaded
Vasily Melenchuk committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/26d74a57d54327b9fd562065d04d867852ce8e8a tdf#103956: RTF import: fix for \cellx0 or no params. It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Provided patch does not resolve given testcases completely: support for \trautofit1 and autofitting for RTF is still missing. However table columns with width 0 or not given width should be displayed better: not minimal width of 41, but some visible value. So tables are finally visible but too wide comparing to MS Word.
Vasily Melenchuk committed a patch related to this issue. It has been pushed to "libreoffice-7-5": https://git.libreoffice.org/core/commit/84aea0a29962cf11a63bdb550f522b3d5574cf64 tdf#103956: RTF import: fix for \cellx0 or no params. It will be available in 7.5.0.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.