| Summary: | 3.5.1 blorks on RTF files which 3.4.5 opened correctly | ||
|---|---|---|---|
| Product: | LibreOffice | Reporter: | ryan.jendoubi <ryan.jendoubi> |
| Component: | Writer | Assignee: | Miklos Vajna <vmiklos> |
| Status: | VERIFIED FIXED | ||
| Severity: | normal | CC: | jbfaure, ryan.jendoubi, s-joyemusequna |
| Priority: | medium | Keywords: | filter:rtf, regression |
| Version: | 3.5.1 release | ||
| Hardware: | All | ||
| OS: | Linux (All) | ||
| Whiteboard: | target:3.6.0 target:3.5.4 | ||
| Crash report or crash signature: | Regression By: | ||
| Attachments: |
RTF doc opened in LO 3.4.5: success
RTF doc opened in LO 3.5.1: failure RTF document in question |
||
Created attachment 58922 [details]
RTF doc opened in LO 3.5.1: failure
Created attachment 58923 [details]
RTF document in question
Confirmed with LibO 3.5.2 RC1. (Windows XP / Vista 64) Works fine with libO 3.4.5 (and Word 2007) => REGRESSION Indeed :-( Abiword opens this file without complaint, but gedit (text editor) says that it contains invalid characters. Wordpad (Ubuntu/Wine) opens the file but don't show the picture. If I open the file with Abiword, delete the picture and resave the document as RTF file, then LO 3.5.3 rc0+ open the file with only one glitch: the text is on the second page. If I do the same with LO 3.4.5 (delete the picture and resave as RTF), then this new version of the RTF file crashes LO 3.5.3 rc0+ with the following error message: terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc Aborted (core dumped) All my tests have been made under Ubuntu 11.10 x86_64. Miklos: it is one for you I guess. Please, feel free to reassign if you can't handle this bug. Best regards. JBF Confirmed, will have a look. OK, the problem here is that the document contains a \cbpat0 token, where 0 should mean auto, but it's parsed as "black". This wasn't a problem with 3.4.x, which didn't support black paragraph background at all. :) Miklos Vajna committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=e8706d7a110547c04e6db9ed75b2e7f74bd6d0bd fdo#47764 fix RTF import of automatic paragraph background color Fixed in master, will request backport to -3-5 as usual. Note that the other problem was the \bin keyword, which is already on its way to 3.5.4. Fantastic! Thanks a lot. Niggles with Template files & stuff notwithstanding I think I can actually upgrade to 3.5 once this lands :-) Thanks again! Miklos Vajna committed a patch related to this issue. It has been pushed to "libreoffice-3-5": http://cgit.freedesktop.org/libreoffice/core/commit/?id=34d7dc5145013900ac0f7f31f92beb01c858461a&g=libreoffice-3-5 fdo#47764 fix RTF import of automatic paragraph background color It will be available in LibreOffice 3.5.4. Verified with LOdev 3.6 (master - 18-May-2012 02h44 x86@6-fast; Build ID: 8b1d29b) under Windows Vista 64. Migrating Whiteboard tags to Keywords: (filter:rtf) Replace rtf_filter -> filter:rtf. [NinjaEdit] |
Created attachment 58921 [details] RTF doc opened in LO 3.4.5: success Not much more to say. The problem occurs whether opening the file with a double-click or through the File menu. See attachments: * Screenshot of document successfully opened in LO 3.4.5 * Screenshot of document opened incorrectly in LO 3.5.1 * Document in question The document is from a legal journals database, but I have removed the bulk of the text (using vi so as to preserve whatever is causing the issue) and I believe this to be fair use in that the copyright holder's interests are in no way prejudiced.