GNOME Bugzilla – Bug 496985
Ridiculous length of string on clipboard
Last modified: 2007-11-16 00:24:46 UTC
Start gnumeric with env.var GNM_DEBUG=clipboard. Ctrl+A to mark sheet, Ctrl+C to copy to clipboard. Request the clipboard as text. You see. ** Message: clipboard target=UTF8_STRING ** Message: clipboard text of 16777215 bytes 65535 lines, each 2040 spaces. String comes from cellregion_to_string. If running under gnome, quit gnumeric. You see ** Message: clipboard target=application/x-gnumeric ** Message: clipboard .gnumeric of 887 bytes ** Message: clipboard target=text/html ** Message: clipboard html of 631 bytes ** Message: clipboard target=UTF8_STRING ** Message: clipboard text of 16777215 bytes ** Message: clipboard target=COMPOUND_TEXT ** Message: clipboard text of 16777215 bytes ** Message: clipboard target=STRING ** Message: clipboard text of 16777215 bytes I.e. only the text formats behave unreasonably. Start gnumeric with env.var GNM_DEBUG=clipboard. Ctrl+A to mark sheet, Ctrl+C to copy to clipboard. Request the clipboard as text. You see. ** Message: clipboard target=UTF8_STRING ** Message: clipboard text of 16777215 bytes 65535 lines, each 2040 spaces. String comes from cellregion_to_string. If running under gnome, quit gnumeric. You see ** Message: clipboard target=application/x-gnumeric ** Message: clipboard .gnumeric of 887 bytes ** Message: clipboard target=text/html ** Message: clipboard html of 631 bytes ** Message: clipboard target=UTF8_STRING ** Message: clipboard text of 16777215 bytes ** Message: clipboard target=COMPOUND_TEXT ** Message: clipboard text of 16777215 bytes ** Message: clipboard target=STRING ** Message: clipboard text of 16777215 bytes I.e. only the text formats behave unreasonably.
This also inspired me to file 496991 against the control center. We shouldn't have to render all the legacy string formats, the clipboard manager should be able to handle that.
Plus ça change.. During october 2006, I limited strings on clipboard to non-empty part of sheet by adding if (cr->origin_sheet != NULL) { extent = sheet_get_extent (cr->origin_sheet, FALSE); cols = MIN (cr->cols, 1 + extent.end.col - cr->base.col); cols = MAX (cols, 1); rows = MIN (cr->rows, 1 + extent.end.row - cr->base.row); rows = MAX (rows, 1); } to cellregion_to_string (diff 15046 15047). Looks like it would be appropriate to bring it back.
Jody killed it with http://svn.gnome.org/viewvc/gnumeric?view=revision&revision=15173 Go ahead and bring it back.
Created attachment 99142 [details] [review] cr_extent The patch wasn't quite right. We should not be using the extent of the current sheet to measure the extent of the cr. Try the attached patch instead.
a new patch in svn that fixes this and handles more obscure cases of visibility.