GNOME Bugzilla – Bug 671845
line style issue in xls export or import
Last modified: 2018-05-22 13:49:42 UTC
This is t6002-objs.pl, still uncommitted. #!/usr/bin/perl -w # ----------------------------------------------------------------------------- use strict; use lib ($0 =~ m|^(.*/)| ? $1 : "."); use GnumericTest; &message ("Check the xls exporter."); &test_exporter ("$samples/excel/objs.xls"); --cut-- It does xls->gnumeric and compares it with xls->xls->gnumeric The resulting files should be identical. Problem: something is importing and/or exporting auto-dash and auto-fore inconsistently. - <outline dash="solid" auto-dash="1" width="0" color="0:0:0:FF" auto-color="1"/> - <fill type="pattern" auto-type="1" is-auto="0" auto-fore="1"> + <outline dash="solid" auto-dash="0" width="0" color="0:0:0:FF" auto-color="0"/> + <fill type="pattern" auto-type="1" is-auto="0" auto-fore="0">
Jean: ideas? You changed this code about a year ago.
This is most probably related to the differences in auto flags interpretation in gnumeric and xls. I'll have a closer look.
If I turn on chart debugging in boot.c and do ./ssconvert ../samples/excel/objs.xls /tmp/ooo.xls 2>&1 | tee ~/aaa ./ssconvert /tmp/ooo-new.xls /tmp/ooo.gnumeric 2>&1 | tee ~/bbb diff -u ~/aaa ~/bbb I notice... -Chart @ 0, 0 is 2.24077" x 1.4815" +Chart @ 0, 0 is 0.000847723" x 0.000847723" --> that's a very small chart lineformat( LineColor 00:00:00; -flags == 9. +flags == 0. Lines are 0.000000 pts wide. Lines have a solid pattern. ); --> that's the line style issue fontx( -apply font Arial 5;); +apply font Tahoma Bold 8;); ai( ); --> I'm looking at this one
Arial/Tahoma problem fixed.
The automatic behavior in gnumeric and excel are so different that I'm not sure that it would be wise to change things for lines. We can't expect that opening and writing an xls file does not change anything. As far as I remember, the Microsoft documentation say that flags should be 0 or 1, so I don't know how to interpret 9. Previous attempts resulted in new bugs.
The documentation does indeed define the lower bit only. We can't be afraid of making changes -- that's a sign that our test suite is incomplete. I'll try to make a .gnumeric with a line style compendium.
Created attachment 209587 [details] [review] Proposed patch OK, the line issue is a clear bug, the test doing just the opposite of what it should. For the auto flag for area pattern, looks like we can set it if one of auto_fore and auto_back is true given that on import, we set only one of these flags. We should probably add a comment and cross fingers. With this patch, the two gnumeric files are identical, just the line flag in xls changes from 9 to 1. This does not solve the chart size issue.
Created attachment 209589 [details] [review] Enhanced patch Added the comment, and export a better chart size, not exactly the same as on input though (difference seems to be around 1 pixel).
Looks great as far as I can tell. The size part uses state.root_view->allocation and appears to work without the gui. I just want to confirm that that makes sense.
I don't remember why we don't use an existing view when we have a gui (probably because it is not so easy), but clearly, we need to create a view when called from a non-gui program such as ssconvert.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnumeric/issues/182.