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 681009 - problems in export of sheet objects
problems in export of sheet objects
Status: RESOLVED FIXED
Product: Gnumeric
Classification: Applications
Component: import/export OOo / OASIS
git master
Other Linux
: Normal normal
: ---
Assigned To: Andreas J. Guelzow
Jody Goldberg
Depends on:
Blocks:
 
 
Reported: 2012-08-01 17:31 UTC by Andreas J. Guelzow
Modified: 2012-08-02 19:17 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
sample file (2.00 KB, application/gnumeric)
2012-08-01 17:31 UTC, Andreas J. Guelzow
Details
Sample file created with LO calc (7.95 KB, application/vnd.oasis.opendocument.spreadsheet)
2012-08-02 07:01 UTC, Jean Bréfort
Details

Description Andreas J. Guelzow 2012-08-01 17:31:33 UTC
Created attachment 220083 [details]
sample file

When saving the attached gnumeric file as ODS file, there are aparently two problems:

(1) the vertical ordering of the ellipses is switched
(2) the alpha component of the fill colour of the ellipses is lost

At least this is the way the file looks afterwards when opened in AOO, KSpread and Gnumeric.

Note that LO fails to correctly size and place tose ellipses at all, but that has been filed against LO in https://bugs.freedesktop.org/show_bug.cgi?id=53054
Comment 1 Andreas J. Guelzow 2012-08-01 18:45:35 UTC
The problem with (1) is that we were neither writing nor reading a z-index, so the order of the objects in the file (given by the scanning order of the cells to which the objects are anchored) determined the layering.

We now correctly export the z-index. We still so not use it when reading ODF files.
Comment 2 Morten Welinder 2012-08-01 20:42:36 UTC
Does ods have an alpha component in its colours?

(Don't even try googling for that!)
Comment 3 Andreas J. Guelzow 2012-08-01 20:48:31 UTC
no, there is no alpha component but there is an opacity attribute that can be used for some things.
Comment 4 Jean Bréfort 2012-08-01 20:56:58 UTC
I created a blue and 50% transparent ellipse inside a using LOCalc. When loaded
in gnumeric the ellipse is white.
In the ods file, I see for the style: draw:opacity="50%". The color does not
appear at all, seems that light blue is the default.
Comment 5 Andreas J. Guelzow 2012-08-02 03:21:21 UTC
Problem (1) is fixed.
Comment 6 Andreas J. Guelzow 2012-08-02 04:40:29 UTC
We are now exporting the opacity of sheet objects' fill colour. The is half of problem #2.
Comment 7 Andreas J. Guelzow 2012-08-02 05:59:02 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.


Jean, ODF producer unfortunately are allowed to skip many style specifications and use "defaults" instead. These defaults vary between producers. For interoperability, producer are urged not to use defaults but to specify the colours in the file. Apparently LO does not do that.
Comment 8 Jean Bréfort 2012-08-02 07:01:17 UTC
Created attachment 220117 [details]
Sample file created with LO calc

Sampel file with a semi-transparent ellipse
Comment 9 Jean Bréfort 2012-08-02 07:01:49 UTC
We do not properly import above sample.
Comment 10 Andreas J. Guelzow 2012-08-02 07:10:19 UTC
I don't see much wrong with our import. LibreOffice fails to save a fill-color.
Comment 11 Andreas J. Guelzow 2012-08-02 07:14:16 UTC
I see we are somehow missing to fall-back to the specified default style....
Comment 12 Jean Bréfort 2012-08-02 08:09:50 UTC
The ellipse has transparency in LO, not in gnumeric.
Comment 13 Andreas J. Guelzow 2012-08-02 08:33:46 UTC
The import of the LO generated ellipse (file from comment #8) should now work fine.

But there is till a problem with the layering of objects:

take the file from teh initial import and save it as an ODF file. Then open it several times. The layering is correct the first time it is opened but wrong the second, third, etc. time.
Comment 14 Jean Bréfort 2012-08-02 08:41:01 UTC
It crashes for me!

  • #0 *__GI_raise
    at ../nptl/sysdeps/unix/sysv/linux/raise.c line 64
  • #1 *__GI_abort
    at abort.c line 92
  • #2 __libc_message
    at ../sysdeps/unix/sysv/linux/libc_fatal.c line 189
  • #3 malloc_printerr
  • #4 *__GI___libc_free
    at malloc.c line 3738
  • #5 oo_style
    at openoffice-read.c line 4411
  • #6 lookup_child
    at gsf-libxml.c line 654
  • #7 gsf_xml_in_start_element
    at gsf-libxml.c line 728

Comment 15 Andreas J. Guelzow 2012-08-02 09:01:58 UTC
that crash was probably due to an uninitialized variable.
Comment 16 Andreas J. Guelzow 2012-08-02 09:15:49 UTC
The issue of comment #13 is now bug #681049. So everything else in here seems fixed.