Created attachment 60934 [details] problem file Problem description: Broken layout of attached RTF file in LibreOffice 3.5.3 Writer. Frames around the parts of the document are missing or misplaced, numbers on the line in the middle of the document are missing. Steps to reproduce: 1. open attached broken.rtf file in Writer Current behavior: broken layout, see http://www.popka.sk/_data/libo35.png Expected behavior: layout like in LibO 3.4, see http://www.popka.sk/_data/libo34.png Platform (if different from the browser): Windows, Linux Browser: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:12.0) Gecko/20100101 Firefox/12.0
Created attachment 60935 [details] screenshot of the correct behavior in LibO 3.4
Created attachment 60936 [details] broken layout in LibO 3.5.3
Reproducible with master (Build ID: f1005e5) and LO 3.5.4 rc0+ under Ubuntu 11.10 Looks like a duplicate of bug 47495 : as in report generated by Oracle Report, a complex set of text areas and frames is not rendered correctly. Miklos : do you agree ? Please, feel free to reassign if you can't handle this bug Best regards. JBF
Set status to NEW, because bug is confirmed now (see comment #3), well-documented with sample file, and reproducible. Hint: Also similar to bug 48442. (It's hard to say if any of these bugs is a real duplicate; this would need good understanding of the RTF format, and is beyond my horizon. We will know if one of them is fixed: if bug B goes away after fixing bug A, it was a duplicate ...)
Regression does appear in oldest version of bibisect-3.5.tar.lzma and must be older.
Created attachment 62413 [details] How the sample file looks in LibO 3.5.4.2 To document the current state of affairs, I attach a new screenshot of our "broken" file, made with LibreOffice 3.5.4 release (on MacOS X 10.6.8). IMHO the screenshot shows that there is some progress: the lines are more like in LibO 3.4.x now; but they are still not completely correct.
*** Bug 54257 has been marked as a duplicate of this bug. ***
Created attachment 66409 [details] How the sample file looks in LibO 3.6.1.2 Good news: if you open the sample file with the current release (LibreOffice 3.6.1.2), you will see that it now looks very closely like in 3.4.x. So, if we consider the behaviour of LibreOffice 3.4 as correct, the behaviour of LibreOffice 3.6.1.2 is correct again. @ ladislav.bonita: Could you please test this yourself with LibreOffice 3.6.1.2 (or better) -- can you confirm that the problem is (near to) fixed? This would be very helpful! Thank you very much!
(In reply to comment #8) > Created attachment 66409 [details] > How the sample file looks in LibO 3.6.1.2 > > > Good news: if you open the sample file with the current release (LibreOffice > 3.6.1.2), you will see that it now looks very closely like in 3.4.x. > > So, if we consider the behaviour of LibreOffice 3.4 as correct, the behaviour > of LibreOffice 3.6.1.2 is correct again. > > > @ ladislav.bonita: > > Could you please test this yourself with LibreOffice 3.6.1.2 (or better) -- can > you confirm that the problem is (near to) fixed? > > This would be very helpful! Thank you very much! Look for the duplicate bug 54257 https://bugs.freedesktop.org/show_bug.cgi?id=54257 in LobO 3.6.1.2 (Example 16 is more evident). Problems still present in Page Preview mode and while printing.
(In reply to comment #9) > Look for the duplicate bug 54257 > https://bugs.freedesktop.org/show_bug.cgi?id=54257 in LobO 3.6.1.2 (Example 16 > is more evident). Problems still present in Page Preview mode and while > printing. You are right -- the document attached to bug 54257 still looks unsatisfactorily. But I was talking just about the present bug report with the attached sample document, which IMHO looks quite good now in LibO 3.6.1.2. Couldn't we * make bug 54257 an independend (not duplicate) bug report again (Status REOPENED) * close the present bug as RESOLVED/WORKSFORME? This would allow our developers to concentrate on the remaining problems, which are IMHO well visible in bug 54257, but not in the present bug report ... But all this is just a suggestion, if you still see severe problems with the sample document attached to *this* bug report I will keep quiet ;-)
Created attachment 72056 [details] rtf files, that were sucessfully opened in 3.6.X, but in 4.0.0.0 beta 2 could not be opened (crash) REGRESSION: Test files from Bug 54257, that were sucessfully opened in 3.6.X, in 4.0.0.0 beta 2 could not be opened at all (crash) with "General Error. General input/output error."
(In reply to comment #11) > Created attachment 72056 [details] > rtf files, that were sucessfully opened in 3.6.X, but in 4.0.0.0 beta 2 > could not be opened (crash) > > REGRESSION: Test files from Bug 54257, that were sucessfully opened in > 3.6.X, in 4.0.0.0 beta 2 could not be opened at all (crash) with "General > Error. General input/output error." Hi Timon, If your file could not be opened, then it is another problem than the one related in this bug report which is about a layout problem. So please, file a new bug report for this crash. Best regards. JBF
(In reply to comment #12) > Hi Timon, > > If your file could not be opened, then it is another problem than the one > related in this bug report which is about a layout problem. So please, file > a new bug report for this crash. > > Best regards. JBF Sorry, already reported Bug 58702 with crash problems in .RTF files
All three files (broken, Example 15, Example 16) work now fine with LOdev 4.0 Beta2+ (2013-01-01), tested under Windows XP and Vista 64.
Fixed in LibO Version 4.0.0.1 (Build ID: 527dba6f6e0cfbbc71bd6e7b88a52699bb48799)
Migrating Whiteboard tags to Keywords: (filter:rtf) Replace rtf_filter -> filter:rtf. [NinjaEdit]
the file is not displaying per attachment 60935 [details] Version: 5.5.0.0.alpha0+ Build ID: 066665644b398a882e6cded98af5bb060af41d76 TinderBox: Android-ARM@24-Bytemark-Hosting, Branch: Master, Time: 2017-06-01 00:30:43
Frames around the parts of the document are missing on 5.4.0.0.alpha0+ [ build id: 3902bb7 ] os: android 5.1 device: lyf flame 3 [ ls-4001 ]