This one will be quite difficult to fix, if just possible.

That's certainly possible.

However, note that like for some of the other tests we have the option
of telling the tests not to look at specific things.  Greek text in biff7,
for example.

The hope is to identify specific things such as things one for ods:

-                  <text_layout/>
+                  <text_layout angle="0"/>

We don't even roundtrip through our own format, apparently. Weird.

I fixed the angle issue.

Yes, the lack of roundtrip for gnumeric is strange.

The reason for the .gnumeric mismatches:

-                    <line dash="solid" auto-dash="1" width="0" color="0:0:80:FF" auto-color="1"/>
-                    <marker auto-shape="1" shape="diamond" auto-outline="1" outline-color="0:0:80:FF" auto-fill="1" fill-color="0:0:80:FF" size="5"/>
+                    <line dash="solid" auto-dash="1" width="0" color="0:0:0:FF" auto-color="1"/>
+                    <marker auto-shape="1" shape="none" auto-outline="1" outline-color="0:0:0:FF" auto-fill="1" fill-color="FF:FF:FF:FF" size="5"/>

is that we apply a theme on load to those items that are "auto".

This begs the question: why we are saving anything for those?

I don't know why we save auto fields. We always did as far as I know.

change of auto fields when going through xls or odt can't be avoided because the semantics of auto values is somewhat different in other spreadsheets.

Ths xlsx is not surprising, our chart export is very incomplete (I could never correctly export a radial axis style to xlsx and could not find why).

We not longer save values for things that are "auto".  Gnumeric roundtrips.

We don't really need to save the "is-auto" properties, I suppose, although this would need some changes in the loading code to stay compatible.

Fixed the xls axis issue (I'm pretty sure there are others around, especially in the catserrange field).

The remaining issues in xls biff8 can't be fixed, or we might have the same file, but not the same appearance than in other spreadsheets (not 100% sure, but I fixed several related bugs years ago).

<property name="manual-size">size</property>

Wouldn't it make more sense to have a boolean?

My last comment was intended for a different bug...

Re comment #7: I do not see that Gnumeric round trips. I see:

t6516-graph.pl: Check graph gnumeric roundtrip.
--- graph-tests.xml	2014-04-16 21:22:22.500258423 -0600
+++ graph-tests-new.xml	2014-04-16 21:22:22.508258423 -0600
@@ -99,7 +99,7 @@
             <property name="theme-name">Default</property>
             <property name="padding-pts">7.086614</property>
             <property name="style" type="GogStyle">
-              <outline auto-dash="1" width="0" auto-color="1"/>
+              <outline dash="none" auto-dash="1" width="0" color="0:0:0:FF" auto-color="1"/>
               <fill type="none" auto-type="1" is-auto="1" auto-fore="1"/>
             </property>
             <property name="anchor">top-left</property>

and many more.

For ODF roundtrip we have:
         <gnm:SheetObjectGraph ObjectBound="B1:F9" ObjectOffset="0.516 0.412 0.656 0.0588" Direction="17" Print="1">
           <GogObject type="GogGraph">
-            <property name="height-pts">97.496700</property>
-            <property name="width-pts">198.720000</property>
             <property name="theme-name">Default</property>

Since the height-pts and width-pts can be calculated from 
ObjectBound="B1:F9" ObjectOffset="0.516 0.412 0.656 0.0588"
and the known column widths and row heights, this seems to be a redundant piece of information.

What do we gain by calculating this?

Andreas: don't worry about height-pts etc.  We don't even get those from
xls so they can't be that important.

Strange observation: graph-tests.gnumeric and the xls file we create from
that both load with a graph that has a frame around it.  When we load the
ods file that either we or localc generates, we get no frame.  And yet
it's not showing the the roundtrip diffs in any way I can tell.

I have masked the auto-dash issue for ods.
There still are some width issues as well as an auto-type issue.

ODF roundtrips now.

Note that issue of a missing frame around the graph for ODF did show in the diff as the 'width' difference for the 'outline'.

Great!  I'm likely to break it again when adding more stuff, but I want to
get the Excel situation under control first.

We cannot handle the auto_* stuff round tripping through LO, but we can do it for round trips through ODF+extension. Since that is what we are really testing here, I have disabled that filter part and fixed the auto_dash issue.

Works for me.

I have strategic goal of one day being able to supply

    --primary-format=ods

to configure -- not because I think ods is a particular good format, but
I can see an organisation wanting to standardize on it.

Having to use extensions is an unfortunate thing, but if nothing else it
can serve as a reminder about what parts of the ods standard we would like
to see updated one day.  Anyway, I'm just thinking ahead here.

Something went wrong with the Y coordinates for xlsx:

-        <gnm:SheetObjectGraph ObjectBound="B1:F9" ObjectOffset="0.516 0.412 0.656 0.0588" Direction="17" Print="1">
+        <gnm:SheetObjectGraph ObjectBound="B1:F9" ObjectOffset="0.516 0.109 0.656 0.0134" Direction="17" Print="1">

There is also some strange scaling happening in xlsx import for the horizontal direction. I added the corresponding scaling in export, but that means that the numbers may be wrong inside the xlsx file.

The read side of xlsx object positions was badly broken in that it was
using columns for both columns and rows.

I have added a few more things to t6516.

ods loses the colour of titles:

-                  <font color="0:0:FF:FF" font="Sans Bold 12" auto-scale="1"/>
+                  <font color="0:0:0:FF" font="Sans Bold 12" auto-scale="1"/>

Several issues here:

1. go_style_font_sax_save doesn't save font.auto_color.

2. go_style_sax_load_font leaves font.auto_color unchanged.  We will need some
   kind of hack when reading old files that do not have the "auto-color"
   attribute.  Maybe "black is auto, others not."

With 1+2 fixed we can resave graph-tests and have the auto-flag reasonably
set (in memory).  Then...

3. odf_write_gog_style_graphic knows nothing about fonts.

Comments, anyone?

May be we should not save auto fields at all.

As long as we keep theming support we need the auto fields.  I don't think
we want to get rid of it, even if we aren't using the theming code a lot
right now.

The idea was not exactly that: if a color is auto, we might not save the color. When reading, if a color is found then it is not auto (unless if the auto field is there, of course, for compatibility). Samthing for line width, dashes and other fields that might be auto.

Ah, I see.

We can do that if we can figure out a way to do it while still being able
to read existing files.  For now I am going to move towards saving the
"auto" flag and only saving data for non-auto fields.  If we can get that
to work, then we can make the "auto" fields optional later.

Created attachment 276132 [details] [review]
Sample patch

Just a sample of my idea concerning lines only.

Created attachment 276134 [details] [review]
Updated patch

Actually, if we want the new files to be loaded correctly by old gnumeric instances, we need to save some auto flags, but only when they are FALSE since the default is to have all set to TRUE.

We do want old gnumerics to read the new files.

And we worry somewhat over how new gnumerics read old files that lack
certain auto flags.

I added saving of auto-width with a heuristic for reading old files.

I added saving of font.auto-color with a heuristic for reading old files.

Chart text colour is now exported and LO can load it.  We cannot.

We roundtrip chart titles' colours now.

Created attachment 276298 [details]
Updated graph-tests.gnumeric with marker tests

This updated file (which will be committed when I can) shows various problems:


1. We fail to export the size for the diamond-shaped marker.  All the others
   do get their sizes exported.

2. We fail to export marker colour.

I believe (2) is not fully solvable.  Or, if it is, it involves a little
svg file as the marker.  (svg to make it scalable.)

Other than as an image, I don't think that ods allows different colours for
the line and the markers.  Andreas, can you confirm that?

We have three different colours in play: line, marker, and marker's
outline.  Something will have to give.  In this case -- which has no
line at all -- I suspect that we should use the marker's fill colour
for the series.  Maybe, if the fill colours is fully transparent, we should
even go on to using the outline colour.

Fix in hand for export-size problem.  The shape isn't "diamond", but "auto"
in this case.

For ods we have a number of these:

-            <property name="padding-pts">7.086614</property>
+            <property name="padding-pts">7.086614173228346</property>

(The reason that we have a few non-default values, i.e., 7.086614 is that
we used to save doubles with too little precision; we now roundtrip this
truncated value.)

We get the difference above because we don't save this to ods at all.
Andreas: do we have a place to save this in ods?

this change is peculiar:

-            <property name="height-pts">92.90700000000004</property>
+            <property name="height-pts">87.92175000000003</property>

It looks like we're adjusting for some kind of padding on write, but not
on read.

I made the padding-pts part of the file use the default value, so we don't
see any differences until we start setting it on purpose.

I have hidden differences related to outline colour.

We are down to this:

+                  <property name="interpolation-skip-invalid">TRUE</property>


-                    <marker auto-shape="1" auto-outline="1" auto-fill="1" size="5"/>
+                    <marker auto-shape="0" shape="none" auto-outline="1" auto-fill="1" size="5"/>


-            <property name="height-pts">92.90700000000004</property>
+            <property name="height-pts">87.92175000000003</property>

-            <property name="height-pts">85.49924999999999</property>
+            <property name="height-pts">89.7345</property>


(And that's really not bad!)

+                  <property name="interpolation-skip-invalid">TRUE</property>
 is now fixed

It is strange that there are only 2 occurrences of height-pts differences, since there are many more charts in the file.

for the last one we have:

        <gnm:SheetObjectGraph ObjectBound="C11:F17" ObjectOffset="0.0625 0.235 0.641 0.882" Direction="17" Print="1">
          <GogObject type="GogGraph">
            <property name="height-pts">85.49924999999999</property>
            <property name="width-pts">171.76800000000003</property>
            <property name="theme-name">Default</property>
            <property name="padding-pts">7.086614173228346</property>


and saved in ODF:

            <draw:frame svg:x="3pt" svg:y="3.1725pt" table:end-x="30.768pt" table:end-y="11.907pt" svg:width="171.76800000000003pt" svg:height="89.7345pt" table:end-cell-address="$'Markers'.F17" draw:z-index="16">

+                  <property name="interpolation-skip-invalid">TRUE</property>

I still see that.  Missing "push"?


> It is strange that there are only 2 occurrences of height-pts differences,
> since there are many more charts in the file.

I agree.  And changing something -- anything -- for the graph in question
tends to make the difference go away.


This is new and comes from new tests I added:

-                    <marker auto-shape="0" shape="circle" auto-outline="0" outline-color="0:FF:0:FF" auto-fill="0" fill-color="0:FF:0:FF" size="5"/>
+                    <marker auto-shape="1" auto-outline="0" outline-color="0:0:0:FF" auto-fill="0" fill-color="FF:FF:FF:FF" size="5"/>

Yes, there was a push missing. It should be gone now.

This seems to be a problem with reading the ODF file, since we have there:

<style:style style:name="GOG-0x18df120" style:family="chart">
      <style:chart-properties chart:interpolation="gnm:cspline" gnm:interpolation-skip-invalid="false" chart:lines="true" chart:symbol-name="circle" chart:symbol-width="5pt" chart:symbol-height="5pt" chart:symbol-type="named-symbol"/>
      <style:graphic-properties gnm:auto-type="true" draw:stroke="dash" draw:stroke-dash="s-dot" gnm:auto-width="true" svg:stroke-color="#00ff00"/>
      <style:paragraph-properties/>
      <style:text-properties fo:font-size="8pt" fo:font-variant="normal" fo:font-family="Sans" fo:font-style="normal" fo:font-weight="normal" gnm:font-stretch-pango="4"/>
    </style:style>

So the shape of the marker is given (correctly). We apparently are not reading it correctly.

The reason while we don't get the correct marker is the code

 		if (gnm_object_has_readable_prop (state->chart.plot,
						  "default-style-has-markers",
						  G_TYPE_BOOLEAN,
						  &dshm) &&
		    !dshm) {
			style->marker.auto_shape = TRUE;
			go_marker_set_shape (m, GO_MARKER_NONE);
		}

in odf_apply_style_props.

Marker issue fixed.

The basic problem is that we cannot export the marker as "automatic"
when that means "none" as it does in a plot that doesn't have markers by
default.  We have to export as "none" and deduce the automatic.

Interestingly we roundtrip the trend line I added -- module some naming -- but
localc doesn't see the trend line at all.

The file we are creating is not valid ODF 1.2 (extended):

graph-tests.ods/Graph30/content.xml[106,235]: Error: attribute "chart:interpolation" has a bad value. Possible values are: b-spline,cubic-spline,none

The issue of comment #50 is a gnumeric specific attribute value. According to 3.17 in ODF 1.2 part 1:

A conforming consumer that encounters an OpenDocument defined attribute that has a value that is not defined by OpenDocument, then it should:
1) If the attribute has a specified default value, use its default value, or
2) If the attribute does not have a specified default value, ignore the attribute.

Moreover we have there:
OpenDocument extended documents may contain elements and attributes not defined by the OpenDocument schema. Elements and attributes not defined by the OpenDocument schema are called foreign elements and attributes.

Note that this does not allow for foreign attribute values. We should use a foreign attribute.

The issue of comment #50 is fixed.

When LO saves the trendline, it includes the specs to the style attached to the series. We are attaching that info to the style of the chart:regression-curve element, which I believe is more correct.

LO apparently ignores the specification if attached to the style of the chart:regression-curve element. I believe that is an LO bug.

I have filed that LO bug as https://bugs.freedesktop.org/show_bug.cgi?id=78999

Supposedly LO 4.2 and later is showing the trendline.

I can confirm that my 4.2 does show the trendline.

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnumeric/issues/253.