Apache OpenOffice (AOO) Bugzilla – Issue 93966
export to xhtml fails, save to html successes
Last modified: 2013-08-07 14:44:35 UTC
What I did: 1. run OOW 2. open odt file 3. export as html 4. -> error on writing (? why?) 5. export as html (again) 6. -> crash 7. run OOW, open odt file, export as html 8. -> error on writing again 9. quit OOW, run it again 10. open odt file 11. this time not export, but save-as html to the same location I tried to export it 12. success
Reassigned to ES.
Cannot reproduce. 1. Which odt doc do you load (please attach here)? 2. There is no "File - Export - HTML" but "XHTML". Do you mean Save As HTML? 3. "error on writing": which error?
ad.1. I cannot attach a copy, I am working on preparing small test file, but since the original has over 500 pages it can take some time ad.2. I mean "export XHTML" (html is mention as extension) ad.3. quote "error saving the document all: write error the file could not be written". So I wish I knew which error, but OOW says only this. Btw. "all" is the filename. It should be possible to trace the message in the sources?
If you don't want to attach the file here because it may contain confidential information, send it to sus @ openenffice.org. He is a SUN Microsystems engineer like me and we are bound by contract to respect the confidentiality of submitters' data. In your e-mail, please, mention the issue ID.
Created attachment 56641 [details] odt file
Well, I can't to it either -- this is confidential file. However, I made up a simple trick which still shows the problems with export. I changed every character to letter 'a'. Now the document looks pretty stupid but it is still good test case.
Your test documents proofs the problem well. I can reproduce your problem and will take a look you. Thank you! Svante
I am sorry. I have to postpone this, due to my work on the ODF 1.2 format and the ODF toolkit.
It is a memory problem. There is an heap overflow even with the new Saxon. The document is valid (http://tools.odftoolkit.org/odfvalidator/) and quite large in XML (content.xml 124MB and styles.xml 5MB). You may see this when doing the XSL transformation on command line or adding the JAVA parameter -DXSLTransformer.statsfile=/tmp/my.log Where /tmp/my.log is an example path to your log file. It did not help to add a bigger heap to the Java process, e.g. -Xms500m -Xmx800m The problem occurs in Saxon during the creation of the styles. Perhaps it might help if not 100 MasterPage styles are being used, where most are the same. I made a quick attemp to fix it by not longer be able to access the flat XML and the package format, neglecting the styles-file element in my globalData context parameter. This improved the performance, but triggered some regression. It makes sense to fix this issue (refactor the sources), when dropping the flat XML file format at all. In any case I have to drop them for 3.1 due to schedule problems.. Svante
As there are no more parental absence months for me, I am pretty confident the patch will make it to the OOo 3.3. Sorry for the delay! Svante
OOo 3.3 is nearly final. I change the target of this issue to OOo 3.x. Please find a solution and set a correct target, if you know when a fix can be integrated.