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 637658 - xls export: incorrect color for graph
xls export: incorrect color for graph
Status: RESOLVED FIXED
Product: Gnumeric
Classification: Applications
Component: import/export MS Excel (tm)
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Jody Goldberg
Jody Goldberg
Depends on:
Blocks:
 
 
Reported: 2010-12-20 12:14 UTC by Frédéric Parrenin
Modified: 2010-12-26 14:51 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
.xls file to reproduce the problem (885.50 KB, application/vnd.ms-excel)
2010-12-20 12:14 UTC, Frédéric Parrenin
  Details
Proposed patch (1.47 KB, patch)
2010-12-21 12:27 UTC, Jean Bréfort
none Details | Review

Description Frédéric Parrenin 2010-12-20 12:14:44 UTC
Created attachment 176757 [details]
.xls file to reproduce the problem

Steps to reproduce the problem:
- open the attached file in XL
=> the graph appears with colored line (red, blue, green)
- open the same file and gnumeric and save it in .xls format
- re-open it in XL
=> the graph appears with black lines
Comment 1 Andreas J. Guelzow 2010-12-20 23:32:32 UTC
When you are saving the file in Gnumeric do you see any warnings in the console/terminal?

I am wondering whether there may be some relationship to comment 11 in bug  496250. (In that case a file is being saved as .xls and the exporter claims not to understand the colours and saves it as black instead.)
Comment 2 Jean Bréfort 2010-12-21 07:45:50 UTC
I don't see the issue, colors are correctly saved. Which gnumeric version are you using?
Comment 3 Jean Bréfort 2010-12-21 07:48:56 UTC
Sorry, I did not reopen in XL, just in gnumeric and oocalc. Ther only diffeernce I can see is that gnumeric adds a backplane which is a bug per se.
Comment 4 Jean Bréfort 2010-12-21 12:27:40 UTC
Created attachment 176820 [details] [review]
Proposed patch

I dont remember how this extra bit went in, I'm pretty sure that it was intended to fix an older bug. Anyway, as the documentation says that it should always be 0, let's follow the documentation.

XL2k does not like the file we export, because we define the Print_Area name, it asks for a new name because this a predefined name (at least this is what I can read in the message box), and then crashes.
Comment 5 Jean Bréfort 2010-12-26 14:51:28 UTC
This problem has been fixed in our software repository. The fix will go into the next software release. Thank you for your bug report.

Crossing fingers.