GNOME Bugzilla – Bug 316234
Support to OpenDocument v1.0 format
Last modified: 2008-03-02 19:09:22 UTC
Implement a filter to import/export OpenDocument files.
Created attachment 52184 [details] [review] libgsf proposed patch
Created attachment 52185 [details] [review] gnumeric proposed patch
These proposed patches imports meta.xml file inside a Gsf-meta struct and handle copy/paste to call the correct filter OOo1 or OOo2.
Created attachment 52787 [details] [review] new patch including proposed modifications Rework to rename some files and to move some functions to the correct ".h" files.
Created attachment 52788 [details] [review] gnumeric reworked patch Added g_object_set_data function, to keep meta information.
Created attachment 52878 [details] [review] patch to import content.xml (depends on other two patches) This patch imports data from OpenDocument documents (data from cells: numbers, formulas, dates, text)
I've got an updated version of the meta parser in libgsf cvs. It's untested but is logical progression from your proposal. Your gnumeric patches will need some updating to cope with libgsf changes.
Created attachment 54131 [details] [review] small correction to metadata parser function small correction to metadata parser function
Created attachment 54132 [details] [review] OpenDocument importer, using new libgsf OpenDocument importer, using new libgsf. This patch imports meta.xml and data from content.xml (numbers, text, colors, borders and formulas).
gsf patch has been applied.
There are a few logic errors in the opendoc patch, but nothing that can not be fixed.
Created attachment 55703 [details] [review] support to images, graphics and improved border/styles support Now the filter can import images and graphics. Also included better support to borders and styles (merged cells, for example). Sorry for this patch's size ;)
Reopening for the new patch.
Created attachment 56314 [details] [review] libgsf suport for OASIS metadata export.
Created attachment 56315 [details] [review] Functions to save metadata information and contents Implements functions to save metadata information and contents like numbers and text. Don't support formulas by now.
Comment on attachment 56314 [details] [review] libgsf suport for OASIS metadata export. It's a start, but needs quite a bit of work. 1) It leaks. 2) There is no need to dup the value or the name 3) We should compare the name to a fixed set of names using the GSF_ #defines rather than hard coding. 4) It needs to handle more value types. 5) it needs to handle arrays
Created attachment 58152 [details] [review] Its a new and more complete version of anterior importer patch. This one is based on the last cvs code and offers a better render of columns and rows styles.
Comment on attachment 58152 [details] [review] Its a new and more complete version of anterior importer patch. This one is based on the last cvs code and offers a better render of columns and rows styles. 1. No // comments. 2. Please make all utility functions static. 3. Avoid casts when you can; make od_draw_image's "file" const.
Created attachment 59408 [details] [review] Revised patch, including modifications sugested by Morten Welinder.
Can you attach a suitable test file, please?
Created attachment 59426 [details] A test file, based on cellstyle_import_biff8.xls from Jody, with 2 graphics.
Comment on attachment 59408 [details] [review] Revised patch, including modifications sugested by Morten Welinder. Committed with fixes. (Leak fixes in this code and in libgsf, for example.) Note, that you were assuming a "Pictures/" prefix that wasn't always present in your test file.
There's still work to be done, though. The walking over lists should not involve calculating the list's length and repeatedly called _nth_.
I know, that this isn't the best place to ask, but it would be nice if you tell me from which version Gnumeric has OpenDocument format (which now is ISO standard) support.
reverted the col style portion of the patch which was a performance problem and wrong. There is a simpler way. ODF uses a different model. Rather than specifying a default style for an entire col/row it specifies a default style for all cells in a col/row. The difference is that if there is no content the style is not applied. There are documents that have col styles, but expect the style to apply only for the first few rows. A cleaner solution is to keep track of the extent of data and clear the styles afterwards. That way we do not need to keep track of which default style to use for spans.
I have committed some of the content export. We still need to handle functions and array's.
Functions can apparently be read by OOo although we don't export them correctly yet. Arrays ought to be next. See also bug 347447
Function export, including array/matrix functions, work.
Sorry if I'm intruding to ask these questions but I could not find the answers anywhere else: - is this the right place to track gnumeric's ODF support? or is there some chart that lists the features that are currently supported and those that are under work? - is gnumeric planning on using ODF as its default file format sometime in the future?
> is this the right place to track gnumeric's ODF support? Here, or in the ChangeLog for the openoffice plugin. > is gnumeric planning on using ODF as its default file format sometime in the > future? Not if I can help it. ODF is not suitable for spreadsheets.
Morten, I am hesitant to ask, but why isn't ODF suitable for spreadsheets? (could not find archives of a discussion on that, but maybe my googlefu is lacking) again, I don't want to turn this into some big debate as I presume you have your reasons, I'm just curious to know what they are.
I have an old rant here: http://blogs.gnome.org/view/mortenw/2005/06/16/0 Add to that... * There is no ODF, or rather "ODF is whatever OpenOffice outputs and accepts". There are piles of documents that fit the ODF description but won't load with OpenOffice. Like with Excel, I don't think we realistically have a lot of chances of getting OO fixed. * Shared expressions are not covered.
This bug is rather nebulous. We've got reasonable import and basic export. Let's close this and split into distinct enhancements (eg export styles).