GNOME Bugzilla – Bug 625332
ODS import of named expressions
Last modified: 2010-07-27 20:07:16 UTC
Created attachment 166595 [details] O-O spreadsh. failed to import to Gnumeric correctly Use of "NAME" to identify database range (e.g. b3:q2003) does not convert from ods file. Editing (by search and replace) to re-name database "NAME" to range in gnumeric (e.g. as b3:q2003) is only partially effective and results in many errors e.g. whilst dsum() and other functions work in gnumeric after above editing, dmax() produces errors. I am disappointed that Gnumeric falls far below claims of compatibility. I have found Gnumeric only adequate for very basic spreadsheet designs, and needs major editing of more powerful existing spreadsheets generated by other software. Conversion MS - O_O - MS file (seems to work perfectly. When Gnumeric approaches the very polished performance of Open_Office, I will reconsider. It would be very useful to have a fully working spreadsheet which can stand alone (unlike Open_Office) Inmusx (Graph on first sheet also failed to import)
The DATA name doesn't seem to get imported. ("<table:database-ranges>" in the file. We parse it, but do not act on it.) ODS is not a high priority for us since it still -- after years and years -- is incompletely defined for spreadsheets. To transfer that file to Gnumeric, it would make more sense to go via .xls which is a crummy, but well understood, format. Note, that the file is not a valid ODS file. It contains junk like "#ref!.[.$C$2]:#ref!.[.$Q$999]"
First of all some general comments: There is no ODF standard that describes the behaviour of any functions such as dsum, dmax etc. (There is a committee draft ODF 1.2 that would recommend certain functions but that draft is currently in public review and as a result of that review is surely going to change.) Your attached file claims to be ODF 1.2 (office:version="1.2"). That ODF version does not exist yet and really nobody can forecast the details of the specifications. Looking at ODF 1.2 Committee Draft 5 (the most recent version), the first argument in DSUM, DMAX, etc is a database which is either a "range" of a "named range" (part 2 4.11.8). Named ranges are defined by (part 1 19.595.7)<table:named-range>. Specifications by <table:database-ranges> have no bearing on the evaluation of OpenFormula formulas. [Note that you can have a name that is used for a database, and a named range, and also for others things, eg. the name of a table, so it is important to consider which type of object can be referred too.] The file in question does not contain any table:named-ranges elements so there is no way for Gnumeric to interpret what DATA is supposed to mean. Note that we do import <table:named-range> correctly. What you are looking at is an OpenOffice bug, They are apparently not saving the file correctly, at least not according to any current ODF version or draft.
Andreas: should we do something about these warnings? WARNING **: Unknown namespace uri = 'http://www.w3.org/2003/g/data-view#' WARNING **: Unknown namespace uri = 'http://www.w3.org/1999/xhtml'
Morten: If we could tell libgsf (or whoever creates them) by default not to print such warning (ie. to print them only if some environment variable is set), that would be great. In every point release OOo adds or changes some namespace uri's. So we basically always get warnings....
I have committed a change that (contrary to the ODF standard) defines a range to match any named filter given in the file. Most users are likely to blame us for not correctly opening an ods file created by OOo rather than OOo for creating invalid files.