| Summary: | FILESAVE RTF export faulty file when text has footnotes | ||
|---|---|---|---|
| Product: | LibreOffice | Reporter: | Silvain Dupertuis <silvain-dupertuis> |
| Component: | Writer | Assignee: | Miklos Vajna <vmiklos> |
| Status: | VERIFIED FIXED | ||
| Severity: | normal | CC: | bugs, fwintzenri, vmiklos |
| Priority: | medium | Keywords: | filter:rtf, regression |
| Version: | 3.5.6.1 rc | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | All | ||
| Whiteboard: | target:3.7.0 target:3.6.4 | ||
| Crash report or crash signature: | Regression By: | ||
| Bug Depends on: | |||
| Bug Blocks: | 44446 | ||
| Attachments: |
ZIP file containing test files (ODT => faulty RTF => corrected RTF)
Simple sample file for bug 55939 |
||
Confirmed in 3.6.2.2. REPRODUCIBLE also on Mac OS X (10.6.8, Intel) with the reporter’s sample file and LibO 3.6.3.1, therefore changed the platform to “All”. @ Miklós Vanja: Hi Miklós, one for you?! ;-) Interesting enough, I can reproduce this issue with LibO 3.5.7.1 and 3.6.0.4, but NOT with LibO 3.3.0, 3.4.0, and 3.5.0 (!). So this bug is a regression, and was probably introduced somewhere in the 3.6 development process and then backported to some 3.5.x version after 3.5.0. Some further testing shows that this problem was *not* present until 3.5.5.3, but appears first in 3.5.6.1. I hope this will fairly limit the count of commits to check ;-) (In reply to comment #0) > The footnotes are encoded {{\super \chftn{\*\footnote > The double opening brace is an error > It should be {\super \chftn{\*\footnote Or the other way around ;-) If you take the complete context of the footnote in 3.5.5.3 (syntax OK): This is a normal text. Adding a footnote and saving as generates an error in the RTF}{{\super \chftn{\*\footnote \chftn\pard\plain \s26\li339\ri0\lin339\rin0\fi-339\sb0\sa0\noline\afs20\fs20\lang1033{\rtlch \ltrch\loch\rtlch \ltrch\loch \tab Rich Text Format} \par }} }{\rtlch \ltrch\loch file.} to the same lines in the 3.5.6.1 file (syntax error): This is a normal text. Adding a footnote and saving as generates an error in the RTF}{{\super \chftn{\*\footnote \chftn\pard\plain \s26\li339\ri0\lin339\rin0\fi-339\sb0\sa0\noline\afs20\fs20\lang1033{\rtlch \ltrch\loch\rtlch \ltrch\loch \tab Rich Text Format} \par }} {\rtlch \ltrch\loch file.} you will notice that 3.5.6.1 has not *added* the superfluous second { before \super (the double {{ was already in 3.5.5.3), but rather *removed* the corresponding closing } in the line before the last line: }{\rtlch \ltrch\loch ^ this } was removed by 3.5.6.1 So one can fix the error either by removing one of the two { before \super, or by adding back the corresponding closing } at the end. Which solution is the better one, will be decided by our RTF expert ;-) Created attachment 69052 [details] Simple sample file for bug 55939 This bug is reproducible even with the simplest possible file containing a single footnote and only default settings for formatting etc. (see attachment, created with LibO 3.6.3.1). Therefore this bug will probably affect *any* file containing footnotes. Therefore this is a very important regression, and I will nominate it as a “Most annyoing bug”. I forgot to mention the obvious: the attachment added in the previous comment is in ODF format; open it with LibreOffice > 3.5.6.1 and save it in RTF format; then try to open that new RTF file again, and you will notive the error. When you inspect the RTF file with a text editor, you will see that it shows the same problem as described in comment #0 and comment #5 (non-matching braces; either a brace too much or a missing brace). Confirmed, the test odt from comment 6 is exported as an invalid RTF. I'll look into this. Miklos Vajna committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=411f9007e20f8035bd2ab7bbc807c61892a5c64c fdo#55939 fix RTF export of footnotes The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback. @ Miklós: Thank you very very much for fixing this issue so fast! I will verify the fix when I get a new master (daily) build ... Fixed in master, -3-6 review: https://gerrit.libreoffice.org/913 Romain: You're welcome. :-) Miklos Vajna committed a patch related to this issue. It has been pushed to "libreoffice-3-6": http://cgit.freedesktop.org/libreoffice/core/commit/?id=eee2704a66075793d49a6972babe9444c3df7a87&g=libreoffice-3-6 fdo#55939 fix RTF export of footnotes It will be available in LibreOffice 3.6.4. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback. VERIFIED as FIXED: While I can still reproduce this bug on Mac OS X 10.6.8 (Intel) with the Master build LOdev 3.7.0.0.alpha0+ (Build ID: 370m0(Build:0); pull time: 2012-10-21 10:01:47) I can no longer reproduce it with the newest Master build LOdev 3.7.0.0.alpha0+ (Build ID: 370m0(Build:0); pull time: 2012-10-27 09:48:34). Tested both with the original reporter’s sample file (attachment 68503 [details]) and with my own minimal sample (attachment 69052 [details]). The RTF syntax of the exported RTF file is now valid again: the missing closing } after the footnote data is present, like in 3.5.5.3 and before. There are no other differences between the RTF output of the master build dated 2012-10-21 and of the one dated 2012-10-27, so there are no signs of any unwanted side-effects of the patch. The exported RTF file opens correctly again in any RTF editor. @ Miklós: thank you again for fixing this nasty issue! An additional ask: Could you please -- only in this special case! -- also request backporting of the patch to the 3.5 branch? I know that officially there are no more 3.5.x releases, but nevertheless Michael Meeks has encouraged us to backport important (and simple) fixes to the 3.5 branch; and this is actually done: e.g., there is right now a 3.5 backporting request by Caolán: https://gerrit.libreoffice.org/#/c/921/ And your fix for the present bug is IMHO one of the most important candidates for backporting to 3.5.x, therefore please request it. Thank you very much! *** Bug 49502 has been marked as a duplicate of this bug. *** Migrating Whiteboard tags to Keywords: (filter:rtf) Replace rtf_filter -> filter:rtf. [NinjaEdit] |
Created attachment 68503 [details] ZIP file containing test files (ODT => faulty RTF => corrected RTF) Saving RTF generates an error in the RTF1 file if there are footnotes. The footnotes are encoded {{\super \chftn{\*\footnote The double opening brace is an error It should be {\super \chftn{\*\footnote The faulty RTF file cannot be opened. It displays a general error message The faulty file can be repaired with a text editor like Notepad++ and applying the replacement {{\super => {\super