After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 743613 - ods write/re-read loses plot series fill-to mode
ods write/re-read loses plot series fill-to mode
Status: RESOLVED FIXED
Product: Gnumeric
Classification: Applications
Component: import/export OOo / OASIS
1.12.x
Other Linux
: Normal normal
: ---
Assigned To: Andreas J. Guelzow
Jody Goldberg
Depends on:
Blocks:
 
 
Reported: 2015-01-28 04:02 UTC by John Denker
Modified: 2015-01-28 19:13 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
simple graphic with filled series (85.20 KB, application/vnd.oasis.opendocument.spreadsheet)
2015-01-28 04:02 UTC, John Denker
Details

Description John Denker 2015-01-28 04:02:37 UTC
Created attachment 295604 [details]
simple graphic with filled series

It looks like ods format can do things that xlsx
(not to mention xls) cannot.  Among other things, it
knows about sliders.

However, it does bad things to /filled/ series in an
XY plot.  Recipe:
  Read in the attached file.
  Right-click on the graph;  select Properties.
  Within PlotXY1, select the series called "reflector"
  On the Style tab, change it to Fill-to: Self
  Note that the magenta filled region should have a Γ shape.
  Save
  Quit
  Re-open the file.

Observe that the Fill-to mode is not "Y origin".  The
magenta region has lost its Γ shape.

Desired behavior:  Fill modes should be preserved.

----------------

Note that this has nothing to do with conversion
from gnumeric to ods file format.  It also has
nothing directly to do with interoperation with
other spreadsheet products.  Those are topics for 
another day;  today we are living entirely in 
the ods world.

Note that this is not urgent for me at the moment,
because for present purposes I can restructure my
data so that fill-to-self is not essential.

I haven't thought of an easy way to write an automatic
test for this.  If the recipe were read-then-write, it
would be easy to compare the two files.  In this case,
the only recipe I know to demonstrate the but involves
write-then-re-read, and involves some hand work.  I
hope I am overlooking something;  I hope there is an
easier and more systematic test.
Comment 1 Andreas J. Guelzow 2015-01-28 05:27:22 UTC
I am not sure what you mean "this has nothing to do with conversion from gnumeric to ods file format"?

Your recipe includes opening an ods file, then making changes in Gnumeric. So you are working within a program whose native file format is .gnumeric.

When you are opening the ods file you are converting from ods to .gnumeric, then you make the changes in .gnumeric and on save you are exporting to .gnumerc.

So this is an import/export issue.

Of course it needs to be fixed .
Comment 2 Andreas J. Guelzow 2015-01-28 18:08:41 UTC
This does not seem to be supported by the ODF standard, so we will need to implement it using an extension. Note that that will mean that other consumers are unlikely to understand the feature.
Comment 3 Andreas J. Guelzow 2015-01-28 19:13:36 UTC
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.