GNOME Bugzilla – Bug 672716
.gnumeric round-trip issues
Last modified: 2012-04-02 16:54:59 UTC
../src/ssconvert -T Gnumeric_XmlIO:sax ../samples/excel/objs.xls /tmp/obj.xml ../src/ssconvert -T Gnumeric_XmlIO:sax /tmp/obj.xml /tmp/obj2.xml diff -u /tmp/obj{,2}.xml | less 1. We seem to have a minor type issue: - <meta:user-defined meta:name="gsf:document-parts"/> - <meta:user-defined meta:name="gsf:heading-pairs"/> + <meta:user-defined meta:name="gsf:document-parts" meta:value-type="string"></meta:user-defined> + <meta:user-defined meta:name="gsf:heading-pairs" meta:value-type="string"></meta:user-defined> 2. Something messes with "Inc" for scroll bars and spin buttons: - <gnm:SheetWidgetScrollbar Name="SCROLL" ... Inc="1" .../> - <gnm:SheetWidgetSpinbutton Name="SPIN" ... Inc="1" .../> + <gnm:SheetWidgetScrollbar Name="SCROLL" ... Inc="10" .../> + <gnm:SheetWidgetSpinbutton Name="SPIN" ... Inc="10" .../> 3. Something is up with images. (too big) 4. Something changes the background colour in GogStyle land. <property name="style" type="GogStyle"> <outline dash="solid" auto-dash="1" width="0" color="0:0:0:FF" auto-color="1"/> <fill type="pattern" auto-type="1" is-auto="1" auto-fore="1"> - <pattern type="solid" fore="0:0:0:FF" back="9C:9C:FF:FF"/> + <pattern type="solid" fore="0:0:0:FF" back="0:0:0:FF"/> </fill> </property>
#2 fixed.
Jean, something is wrong over in GOImage land. We load an image with go_image_new_from_data, but go_pixbuf_save (via go_image_save) is unable to save it. (->data is null.)
Seen that. /tmp/obj.xml has the image saved the ancient way. These days, it should be saved at the GODoc level. This is on the top of my TODO list.
/tmp/obj.xml uses the old way, but notice that somewhere between reading the old format and writing the new one, the image is lost! Actually, since the image shows when you do "gnumeric /tmp/obj.xml" it must be a writing issue.
The non-black colour is coming from map_area_series_solid_default in gog-theme.c
#3 fixed. I can't reproduce #4 anymore, Morten, did you fix it?.
> I can't reproduce #4 anymore, Morten, did you fix it?. No, you did. The xls importer changes now makes the background be saved as 9C:9C:FF:FF in both cases. For better or worse. However the only reason #3 appears fixed is that the image now isn't saved the first time around either: <gnm:SheetObjectImage Name="IMAGE" ObjectBound="F24:L47" ObjectOffset="0.208 0.422 0.598 0.211" Direction="17" Print="1" crop-top="0" crop-bottom="0" crop-left="0" crop-right="0"> <Content image-type="png" name="Image"/> </gnm:SheetObjectImage> ... <GODoc> <GOImage name="Image" type="GOPixbuf" width="320" height="301" rowstride="1280"/> </GODoc> Also, when loading objs.xml with gnumeric I get... ** (/home/welinder/gnome-src/gnumeric/src/.libs/gnumeric:6636): CRITICAL **: pixbuf_to_cairo: assertion `GO_IS_PIXBUF (pixbuf) && image->data && pixbuf->pixbuf' failed
(In reply to comment #7) > > No, you did. The xls importer changes now makes the background be > saved as 9C:9C:FF:FF in both cases. For better or worse. I don't remember having fixed that, weird, Alzheimer? > However the only reason #3 appears fixed is that the image now isn't saved > the first time around either: Did you update both goffice and gnumeric?
#1 is more complicated than I thought. The type of the meta:user-defined fields gsf:document-parts and gsf:heading-pairs is not a standard type so we don't write a value-type. When we read the info we default to a value type of "string". Note that the ODF specs says: "The <meta:user-defined> element has character data content, or depending on the value of the meta:value-type attribute content of type double 18.2, date 18.2, dateTime 18.2, duration 18.2, boolean 18.3.3 or string 18.2." So we do not need a value-type and can just include character data. If I change ths code to always output a default value-type of "string" then we still have round trip trouble because for strings we write even an empty string and so the element has a separate end element.
Created attachment 210840 [details] [review] conceptual patch This is a conceptual patch to fix issue #1. The patch is not correct yet since it doesn't correctly parse the read string in gsf_xml_gvalue_from_str: currently I just cut at every comma, but some of the strings are quoted by "..." and I ignoring those quotes.
Created attachment 211018 [details] [review] proposed patch This patch fixes issue #1.
Note: I do not like this patch but think we can do much better by not storing the gsf-doc-prop-vector as a single meta:user-defined item but by a sequence of such!
What keeps us from storing the property as a sequence?
This is in gsf-opendoc-utils.c. We are using the same way of saving things in .gnumeric and in .ods files. This limits us to what ODF allows us to do, unless we want to use foreign extensions. At this time in libgsf we do not know whether we allow foreign extensions. There is no meta:user-defined sequence. Using simply several meta:user-defined elements with the same property name does not work since: "The meta:name attribute specifies the name of a metadata element. The name shall be unique within the domain of <meta:user-defined> elements." I think we can work around this by using some markers attached to the name.
Created attachment 211036 [details] [review] improved patch This patch fixes issue #1 by saving a sequence of meta:user-defined elements that are connected by a modified name: <meta:user-defined meta:name="GSF_DOCPROP_VECTOR:0:gsf:heading-pairs" meta:value-type="string">Worksheets</meta:user-defined> <meta:user-defined meta:name="GSF_DOCPROP_VECTOR:1:gsf:heading-pairs" meta:value-type="float">2</meta:user-defined> <meta:user-defined meta:name="GSF_DOCPROP_VECTOR:2:gsf:heading-pairs" meta:value-type="string">Named Ranges</meta:user-defined> <meta:user-defined meta:name="GSF_DOCPROP_VECTOR:3:gsf:heading-pairs" meta:value-type="float">2</meta:user-defined>
I have committed my patch. Issue #1 is now fixed. diff -u /tmp/obj{,2}.xml doesn't show any differences any more. So this bug is fixed?
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.