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 667489 - failure to correctly anchor sheet objects on ODF import
failure to correctly anchor sheet objects on ODF import
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-01-08 04:43 UTC by Andreas J. Guelzow
Modified: 2012-03-25 20:07 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
sample ODS file (9.22 KB, application/vnd.oasis.opendocument.spreadsheet)
2012-01-08 04:43 UTC, Andreas J. Guelzow
Details

Description Andreas J. Guelzow 2012-01-08 04:43:30 UTC
Created attachment 204826 [details]
sample ODS file

Note that this might be an ODF import or printing problem.

Open the attached file, preview. Note that the textbox is not included in the preview.

Change the size of the textbox, preview. Note theat the textbox is now included in the preview.
Comment 1 Jean Bréfort 2012-01-09 08:24:58 UTC
Not sure it is a range issue, if you add data in cells around the text box they appear in the preview. Most probably something that is not updated during import.
Comment 2 Jean Bréfort 2012-01-09 08:53:13 UTC
gnm_print_sheet_objects is called with a too narrow range argument. If I remove the cairo_clip call, things work.
Comment 3 Jean Bréfort 2012-01-09 17:16:41 UTC
The issue is in od_draw_frame_start (GsfXMLIn *xin, xmlChar const **attrs).

The anchor is not properly evaluated at this point. both start and end cells are A1, so A1 is printed, but not the real range. The evaluated offsets are 2.17913, 7.17666, 5.82224, and 14.4022 while they should be less than 1 in order to make things work.
Comment 4 Andreas J. Guelzow 2012-01-09 17:21:43 UTC
sheet_get_extent (sheet=0x825e238, spans_and_merges_extend=1) at sheet.c:2116
(...)
2127		for (ptr = sheet->sheet_objects; ptr; ptr = ptr->next) {
(gdb) n
2128			SheetObject *so = SHEET_OBJECT (ptr->data);
(gdb) 
2130			closure.range.start.col = MIN (so->anchor.cell_bound.start.col,
(gdb) p so->anchor.cell_bound
$4 = {start = {col = 2, row = 4}, end = {col = 2, row = 4}}

I don't see A1 but you are right that the bounds are set incorrectly. So this is an ODF import issue.
Comment 5 Andreas J. Guelzow 2012-01-10 03:14:48 UTC
I see: When we read elements we anchor them to the current cell. If a draw:frame element occurs inside a table cell then this is not that far off from the correct anchor position. But draw:frames can also appear in a table:shapes element in which case we think that we are in cell A1. We basically need to adjust our anchors after having determined the location.

Note that we cannot do this when we read the shape since we may still change the height of future rows. We clearly need to wait until the sheet has been completely read.
Comment 6 Andreas J. Guelzow 2012-01-10 05:05:57 UTC
Something like:

diff --git a/plugins/openoffice/openoffice-read.c b/plugins/openoffice/openoffice-read.c
index c959c22..b9b54de 100644
--- a/plugins/openoffice/openoffice-read.c
+++ b/plugins/openoffice/openoffice-read.c
@@ -2368,6 +2368,7 @@ oo_table_end (GsfXMLIn *xin, G_GNUC_UNUSED GsfXMLBlob *blob)
        GnmRange r;
        int rows, cols;
        int max_cols, max_rows;
+       GSList *obj;
 
        maybe_update_progress (xin);
 
@@ -2426,6 +2427,19 @@ oo_table_end (GsfXMLIn *xin, G_GNUC_UNUSED GsfXMLBlob *blob)
                                       sheet_style_default (state->pos.sheet));
        }
 
+       /* We need to adjust all the anchors of the sheet objects */
+       for (obj = state->pos.sheet->sheet_objects; obj; obj = obj->next) {
+               SheetObject *so = SHEET_OBJECT (obj->data);
+               SheetObjectAnchor *anchor = (SheetObjectAnchor *)sheet_object_get_anchor (so);
+               double coords[4];
+               SheetView *sv = sheet_get_view (state->pos.sheet, state->wb_view);
+               sheet_object_position_pts_get (so, coords);
+
+               /* And here we need to recalculate the new anchor */
+
+               sheet_object_set_anchor (so, anchor);
+       }
+
        state->pos.eval.col = state->pos.eval.row = 0;
        state->pos.sheet = NULL;
 }

might work if we can calculate the correct anchor here from the offset in points.
Comment 7 Andreas J. Guelzow 2012-01-12 21:48:16 UTC
Even my suggestion of comment #6 will not work correctly: If an object is included in table:shapes we don't even have the correct row height for row 1, ie. the row height will change.
Comment 8 Jean Bréfort 2012-01-12 22:09:18 UTC
We might have a list of objects to reposition when cell sizes are known, I suppose.
Comment 9 Andreas J. Guelzow 2012-03-25 20:07:17 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.