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 676441 - inappropriate base-cell-address on conditional format export
inappropriate base-cell-address on conditional format export
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-05-20 20:17 UTC by Andreas J. Guelzow
Modified: 2012-05-22 00:44 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Andreas J. Guelzow 2012-05-20 20:17:32 UTC
Gumeric uses A1 as the base-cell-address in conditional format export even if the formula refers to cells to the top left resulting in:

      <style:map style:apply-style-name="Gnumeric-1" style:condition="of:is-true-formula([$'Sheet1'.IS65531]&lt;0)" style:base-cell-address="Sheet1.A1"/>

This is not correctly loaded by other implementation, and may in fact fail to load in Gnumeric if the default sheet size differs.
Comment 1 Andreas J. Guelzow 2012-05-20 22:40:08 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.
Comment 2 Andreas J. Guelzow 2012-05-20 23:13:07 UTC
We now fail in a different direction. gnm_expr_top_get_boundingbox seems to have an unusual behaviour.
Comment 3 Morten Welinder 2012-05-21 01:30:27 UTC
What do we do for .gnumeric and .xlsx?
Comment 4 Andreas J. Guelzow 2012-05-21 06:31:31 UTC
When we write validations to odf we collect them using sheet_style_collect_validations which in fat gives us style ranges so we use the top left of the style range as the base address. This should usually work.

For .gnumeric we don't worry about what to use as a bas address because we can wrap:
            <gnm:Condition Operator="8">
              <gnm:Expression0>Sheet1!IS65531&lt;0</gnm:Expression0>
              <gnm:Style Shade="1" Back="FFFF:0:0" PatternColor="0:0:0"/>
            </gnm:Condition>

In the .gnumeric format we know the saved sheet size so there is no problem. In ODF we do not know the sheet size so wrapping is not well defined.
Comment 5 Andreas J. Guelzow 2012-05-21 06:34:09 UTC
We do not save conditional styles in .xlsx (at this time).
Comment 6 Andreas J. Guelzow 2012-05-21 07:05:31 UTC
Well, the whole bounding box code in expr.c is bizarre. For example in cellref_boundingbox we are checking whether cr->col and cr->row is positive or negative but we never seem to get any negative cols and rows.

For example for an expression that essentially is R[-6]C[-4] we see:
(gdb) p *cr
$4 = {sheet = 0x8278158, col = 252, row = 65530, col_relative = 1 '\001', row_relative = 1 '\001'}

so by the time we get there the col and row have already been changed to positive values (ie. wrapped).
Comment 7 Andreas J. Guelzow 2012-05-21 07:37:17 UTC
The issue has to do with the .gnumeric file:

When I was testing I created the appropriate conditional styles and saved tehm as .gnumeric files. To test I would open the file and then save as .odf.

But in the saved .gnumeric file the cellrefs wrapped and so when we loaded them internally we had the wrapped cellref.

If I create teh conditional style and save directly to ODF then cellref_boundingbox works as advertised and expected.

I guess, back to the drawingboard....
Comment 8 Andreas J. Guelzow 2012-05-22 00:44:27 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.