The attached ODT file cannot be saved as a RTF file.
Steps to reproduce:
1. Load the attached file in LibreOffice
2. Save it as RTF
LibreOffice displays an error box with this message:
Error saving the document
The file could not be written.
LibreOffice manages to save the file.
Platform (if different from the browser):
Browser: Mozilla/5.0 (X11; Linux i686; rv:18.0) Gecko/18.0 Firefox/18.0
This is with Version 18.104.22.168 (Build ID: da8c1e6)
PS: I could not select the correct version in the bug reporting Web interface.
Created attachment 68118 [details]
File to reproduce the bug
Confirmed on Windows Vista 32 bit on LO 22.214.171.124.
Furthermore, saving the same .odt file as a ".doc (97/XP/2003)" or as a ".doc (Word 95)" crashes LibreOffice completely.
I *could* save the attached .odt as .docx, .html and export as pdf.
@Laurent Did this work in previous versions of OpenOffice?
I wonder if this has anything to do with Bug 51262 - "big rtf file from little odt file"
* This document is quite big to start with (777 pages; 2,923,499 bytes)
* It contains a lot of images, and that bug is apparently caused by images in the document.
I don't know if previous LO crashed or failed.
Saving this file to MS Word "DOC" format also crashes on Linux.
I tried with the LibreOffice binary provided in Ubuntu 12.10 and the resulting debugging info can be found there:
With the binary I downloaded from libreoffice.org there is no crash information displayed. The LO window just disappears.
LO 126.96.36.199 under Win7Pro_x64:
Save as RTF -> Error saving the document
Save as DOC (97/XP/2003) -> Crash
Save as DOC (95) -> OK
Excuse me, the previous comment is partially incorrect.
If I open the file and immediately try to save as DOC (either 95 or 97+), LO crashes.
But if I open the file, then try to save as RTF, get the error message, then try to save as DOC (either 95 or 97+), then the operation succeedes.
In Version 188.8.131.52 (Build ID: 58f22d5) on Ubuntu 10.04 was able to re-create the RTF file save error but it did not crash when saved as .doc (97-2003).
Running 184.108.40.206 and it crashes every time I try to save a file with tables, pictures, different field types, footnotes, and comments, etc., to .rtf. I don't try to save to .rtf often, so I'm just noticing this behaviour now. Saving to .pdf, .doc, .docx all work fine.
I think it's "inherited from LibO" I was able to reproduce both RTF and DOC crashes with multiple LibO release up to 3.3.3 (I don't have 3.3.0) and the bug is present in AOO 4.0.0 too.
edited summary. changed version and component fields.
added expert devs to CC list
P.S. tested under Win7 64bit
The test document seems to be broken.
1. If I open the file using any version starting from 220.127.116.11 and up to 18.104.22.168 under Win7x64, it opens with first page empty. When I scroll it down (so that I see some graphics on some pages), and then return to the first page, there are "ghost" graphics in the top left corner of the first page. They may be selected and moved, but if I scroll the document down and up again, they disappear and other graphics appear.
2. The 22.214.171.124 opens the document (with empty first page), and then crashes after a couple of seconds (looks like it continues to process the document after initial display, and the crash happens on some stage of this delayed processing). So, the problem is worse in 126.96.36.199.
Despite the document itself is broken, I think the bug should be fixed, because the crash indicates some flaw in the code that doesn't expect something wrong in the input data. Fixing it will make the software more robust.
I reproduce behavior described in comment 9 with LibreOffice 4.2.5 and 188.8.131.52 on Debian x86_64, but the file is saved as rtf with LibreOffice 184.108.40.206 without errors.
I tested again in Ubuntu 14.10 with LO 1:4.3.2-0ubuntu1:
- saving as RTF works
- saving as DOC crashes
I opened a new bug with updated information:
This odt file has been created by conversion from a .doc file. You can verify this point by checking the names of numbering styles, you will find style names like WW8Num1 which are WinWord8 style names.
If you open the Navigator to examine the objects of this document, you will see that there is 10 hidden tables. AFAIK LibreOffice does not have the ability to hide a table.
I suggest 2 ways to try to fix the problem:
1/ unzip the .odt and remove the hidden tables from the content.xml and compress the file again.
2/ come back to the original .doc file with MS-Word, make sure that all objects included in the document are not hidden, save the file under another name in both formats doc and docx. Convert these new files to .odt using the current stable "Fresh' version of LibreOffice.
Best regards. JBF
Thank you for the analysis of this crash! I will update the bug title...
Thanks again for the workaround! However LO needs a fix anyway.
(In reply to Laurent Bonnaud from comment #18)
> Thank you for the analysis of this crash! I will update the bug title...
> Thanks again for the workaround! However LO needs a fix anyway.
It worked ? which one ? ;-)
Best regards. JBF
> It worked ? which one ? ;-)
I did not even try because I do not care about this document (it is not even mine).
Created attachment 115415 [details]
Minimal test case for bug 55665
(In reply to Jean-Baptiste Faure from comment #17)
> If you open the Navigator to examine the objects of this document, you will
> see that there is 10 hidden tables. AFAIK LibreOffice does not have the
> ability to hide a table.
These hidden tables are parts of custom page styles that are defined in the document, but not used. LO can easily create these. To get rid of the tables, simply remove all custom page styles, or aply each style and remove tables from its header/footer, or just remove headers/footers altogether.
Actually, the problem is not the tables. There is a bug processing one of OLE objects in the file, namely Object 65. It is a formula on page 525 ((1) of C.220.127.116.11.1 SIGMOID descriptor). Removing it, the problem disappears. Besides, scrolling so that it gets displayed on screen removes the crash, too.
Here is the minimal test file that is enough to show the problem. It contains the following required items:
1. Some paragraphs to move OLE objects to second page (manual page break doesn't do the trick)
2. The problematic OLE itself
3. Another OLE just next to problematic one
Submitted patch to gerrit - https://gerrit.libreoffice.org/15667
Mike Kaganski committed a patch related to this issue.
It has been pushed to "master":
tdf#55665: Fix a corner case OLE processing
It will be available in 5.0.0.
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:
Affected users are encouraged to test the fix and report feedback.
Migrating Whiteboard tags to Keywords: (filter:doc, filter:rtf)