GNOME Bugzilla – Bug 667489
failure to correctly anchor sheet objects on ODF import
Last modified: 2012-03-25 20:07:17 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.
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.
gnm_print_sheet_objects is called with a too narrow range argument. If I remove the cairo_clip call, things work.
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.
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.
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.
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.
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.
We might have a list of objects to reposition when cell sizes are known, I suppose.
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.