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 642941 - c:crossesAt should be read and used for xlsx import
c:crossesAt should be read and used for xlsx import
Status: RESOLVED FIXED
Product: Gnumeric
Classification: Applications
Component: import/export MS Excel (tm)
git master
Other Linux
: Normal normal
: ---
Assigned To: Jody Goldberg
Jody Goldberg
Depends on:
Blocks:
 
 
Reported: 2011-02-22 04:35 UTC by Andreas J. Guelzow
Modified: 2011-03-05 12:44 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
sample file (8.16 KB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet)
2011-02-26 16:30 UTC, Jean Bréfort
Details
sample file printed as pdf (23.91 KB, application/pdf)
2011-02-28 14:57 UTC, Morten Welinder
Details

Description Andreas J. Guelzow 2011-02-22 04:35:00 UTC
The file attached to bug #642850 used to cause:

Unexpected element 'c:crossesAt' in state : 
	chartSpace -> chart -> plotArea -> valAx
Unexpected element 'c:crossesAt' in state : 
	chartSpace -> chart -> plotArea -> catAx

We now have stubs for 'c:crossesAt' to avoid these warnings. WE really shoiuld use the provided info though!
Comment 1 Jean Bréfort 2011-02-22 06:34:47 UTC
I'll have a look. Can you provide a sample file? I have no access to a recent excel.
Comment 2 Andreas J. Guelzow 2011-02-22 07:33:30 UTC
Jean, the file attached to bug #642850 should work as a sample file.
Comment 3 Jean Bréfort 2011-02-26 10:39:09 UTC
That sample is not very useful since all crossing occurs at 0 which is the default in gnumeric.
The tricky thing is that goffice logic is not the same as xl. We store the cross value with the crossed axis and they do it in the crossing axis. I don't know what OOo/LibreOffice do.
Comment 4 Jean Bréfort 2011-02-26 16:30:52 UTC
Created attachment 181995 [details]
sample file

This file, generated by LibreOffice calc looks quite differently in calc and gnumeric. The Y-axis position needs to be fixed in gnumeric. Can anybody test in excel,I'd be interested by a screenshot.
Comment 5 Morten Welinder 2011-02-28 14:57:19 UTC
Created attachment 182094 [details]
sample file printed as pdf

Here's a printout from xl that more or less matches the screen.

Note: some of the lines are very, very hard to see in evince and (only)
very hard to see on paper.
Comment 6 Jean Bréfort 2011-02-28 17:01:15 UTC
This is a bit different from LibreOffice where the series have an invisible line style.
Comment 7 Morten Welinder 2011-03-03 15:48:10 UTC
That was from, I believe, xl2003.  It mumbled something about conversion
during load.
Comment 8 Jean Bréfort 2011-03-05 08:22:02 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.

Still remains the series style issue, but this is another bug.
Comment 9 Jean Bréfort 2011-03-05 12:44:02 UTC
The series style issue looks like a curious interpretation of the Open XML spec by LibreOffice/OOo. Seems I should not generate samples using LibreOffice.