Error saving openoffice document as .fodt (flat XML) - requires JRE

Bug #412366 reported by strank on 2009-08-12
36
This bug affects 7 people
Affects Status Importance Assigned to Milestone
openoffice.org (Ubuntu)
Undecided
Unassigned

Bug Description

Binary package hint: openoffice.org

Trying to save a writer document in Flat XML (fodt) results in an error message:

Error saving the document ... Write Error

There is an old similar bug report for OOCalc which has been marked as fixed, however, the same error happens for .fods!

ProblemType: Bug
Architecture: amd64
DistroRelease: Ubuntu 9.04
Package: openoffice.org-core 1:3.0.1-9ubuntu3
ProcEnviron:
 LANGUAGE=en_GB:en
 PATH=(custom, no user)
 LANG=en_GB.UTF-8
 SHELL=/bin/bash
SourcePackage: openoffice.org
Uname: Linux 2.6.28-14-generic x86_64

strank (strank) wrote :
strank (strank) wrote :

Just found out: The reason is that the respective filter is not complete in the standard openoffice package.

The filter works after installing the openoffice-dev package.

So, AFAICS, make sure that the File Format does not show up in the standard package, or extract the relevant parts from the -dev package.

cheers

Chris Cheney (ccheney) wrote :

Do you still have this issue with the new version in the ppa at https://launchpad.net/~openoffice-pkgs/+archive/ppa ?

Changed in openoffice.org (Ubuntu):
status: New → Incomplete
Chris Cheney (ccheney) wrote :

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!

Changed in openoffice.org (Ubuntu):
status: Incomplete → Invalid
Cristian Klein (cristiklein) wrote :

Also happens with .fodp too in Karmic.

Changed in openoffice.org (Ubuntu):
status: Invalid → Confirmed
NoOp (glgxg) wrote :

I've just opened a 15.7Mb .odp, saved as .fodp with out issue. I can open the resulting 21.2 Mb file in an xml editor and/or OOo 3.1.1 Impress.

$ cat /usr/lib/openoffice/program/versionrc
[Version]
AllLanguages=en-US
BuildVersion=openoffice.org-core 1:3.1.1-5ubuntu1, Thu Oct 22 20:13:41 UTC 2009
buildid=310m19(Build:9420)
ExtensionUpdateURL=http://updateext.services.openoffice.org/ProductUpdateService/check.Update
OOOBaseVersion=3.1
ProductBuildid=9420
ProductMajor=310
ProductMinor=19
ProductSource=OOO310
UpdateID=OpenOffice.org_3_en-US
UpdateURL=
UpdateUserAgent=<PRODUCT> (${buildid}; ${_OS}; ${_ARCH}; BundledLanguages=${AllLanguages})
Vendor=Debian and Ubuntu

MichaelTill (debianguru) wrote :

Hi,

I get the same error message when trying to save a document as DocBook.

best regards
Michael

MichaelTill (debianguru) wrote :

(I've karmic)

Olle Kullberg (olle-kullberg) wrote :

I have the same problem when saving DocBook on Ubuntu.

olle@olle-laptop:~$ cat /etc/issue
Ubuntu 9.10 \n \l

olle@olle-laptop:~$ cat /usr/lib/openoffice/program/versionrc
[Version]
AllLanguages=en-US
BuildVersion=openoffice.org-core 1:3.1.1-5ubuntu1, Thu Oct 22 20:13:41 UTC 2009
buildid=310m19(Build:9420)
ExtensionUpdateURL=http://updateext.services.openoffice.org/ProductUpdateService/check.Update
OOOBaseVersion=3.1
ProductBuildid=9420
ProductMajor=310
ProductMinor=19
ProductSource=OOO310
UpdateID=OpenOffice.org_3_en-US
UpdateURL=
UpdateUserAgent=<PRODUCT> (${buildid}; ${_OS}; ${_ARCH}; BundledLanguages=${AllLanguages})
Vendor=Debian and Ubuntu

Will upgrading to OO 3.2 help me?

Running karmic here on a 64bit intel machine. Can confirm the same bug. Trying to read or write a fodt file gives a "generic" read error.

Installing openoffice.org-dev solved this problem!

This warning message given by openoffice (after installing openoffice.org-dev) might be relevant

" Warning: at xsl:stylesheet on line 2 of file:///usr/lib/openoffice/basis3.1/share/xslt/odfflatxml/odfflatxmlimport.xsl:
  Running an XSLT 1.0 stylesheet with an XSLT 2.0 processor"

I suspect that openoffice.org-dev pulls in some external software tools (eg. for XML stylesheets) that are required for the flat XML based documents.

Scrolling back in my history, these are the packages that where pulled in when i installed openoffice.org-dev

$ sudo aptitude install openoffice.org-dev

The following NEW packages will be installed:
  dmake{a} ecj{a} ecj-gcj{a} fastjar{a} gcj-4.4-base{a} gcj-4.4-jdk{a} gcj-4.4-jre{a} gcj-4.4-jre-headless{a} gcj-4.4-jre-lib{a} gcj-jdk{a} gcj-jre{a} gcj-jre-headless{a} libantlr-java{a} libecj-java{a} libecj-java-gcj{a}
  libgcj-bc{a} libgcj-common{a} libgcj10{a} libgcj10-awt{a} libgcj10-dev{a} openoffice.org-dev openoffice.org-java-common{a}
0 packages upgraded, 22 newly installed, 0 to remove and 181 not upgraded.

John Pugh (jpugh) wrote :

This bug continues in the current Lucid betas.

Chris Cheney (ccheney) wrote :

Yes, it appears you need openoffice.org-java-common installed to use those. Every startup of OOo without it installed tells you to install that package for a reason. I will be looking into a way to make it install on first run for Maverick.

Changed in openoffice.org (Ubuntu):
assignee: nobody → Chris Cheney (ccheney)
milestone: none → later
status: Confirmed → Triaged
Chris Cheney (ccheney) on 2010-05-13
tags: added: jaunty
Chris Cheney (ccheney) on 2010-05-23
summary: - Error saving openoffice document as .fodt (flat XML)
+ Error saving openoffice document as .fodt (flat XML) - requires JRE

Also affects me on lastest lucid

Copelnug (copelnug) wrote :

I confirm that the bug is present on Lucid 64-bits. I also confirm that installing the package openoffice.org-java-common resolve the problem.

Chris Cheney (ccheney) on 2010-08-23
Changed in openoffice.org (Ubuntu):
assignee: Chris Cheney (ccheney) → nobody

This seems a backwards feature - the default export filter (aka "save") (to ODT) is zipping up the stream, so why does the application need to unzip it again to make a flat XML file - surely it would just be easier to just remove the zip stage?

I'm presuming it's implemented in the usual C type stream-y way

 DocumentSerializer > RawXmlStream > DeflateStream > FileOutputStream

.. So why not just remove the "DeflateStream", and avoid the requirement to tack a Java unzipper onto the end of the chain?

Is it just that the ODT output is a special case and everything else is a filter? Why not make EVERYTHING a output filter, including the default ODT output?

Just sayin..

LibreOffice 3.4 changelog states that flat ODF filters have been rewritten in C++ and no longer require the Java components.

Changed in openoffice.org (Ubuntu):
status: Triaged → Won't Fix

[This is an automated message.]
There are no new official OpenOffice.org releases in Ubuntu packaging anymore => Won't Fix

If the problem persists, please mark this bug as "also affects project Libreoffice" or "also affects distribution Libreoffice (Ubuntu)" if that has not happened already.

Please leave references to upstream OpenOffice.org bugs in place to allow cross pollination.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers