GNOME Bugzilla – Bug 642941
c:crossesAt should be read and used for xlsx import
Last modified: 2011-03-05 12:44:02 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!
I'll have a look. Can you provide a sample file? I have no access to a recent excel.
Jean, the file attached to bug #642850 should work as a sample file.
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.
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.
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.
This is a bit different from LibreOffice where the series have an invisible line style.
That was from, I believe, xl2003. It mumbled something about conversion during load.
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.
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.