I'm pretty sure this works by now.  You you retry or attach a sheet you have
problems with?

Hmm, there are some weird things going on in Gnumeric-1.4.3 with drawing
objects.  This is not all printing-related.

- The "label" object button actually seems to create a plain filled rectangle,
or at least something that I can't put text in.  (There is no field for text in
the Properties, and typing into the rectangle that is created doesn't seem to work.)
- "label" objects print (although I think these are actually rects, as above);
"frame" objects do not print.  I don't have a spreadsheet imported from Excel
with an Excel-generated text frame in to test with (that is what I originally
generated the bug report from).
- "rectangle" objects print with transparent fill, not opaque fill (i.e. they
look different on screen and on paper), so in one sense they are different from
"label" objects.
- unrelated: "list" objects cannot be dragged when created.  Actually, I take
that back, you have to *right-click* to actually select them, then there's a
1-pixel border that you can drag them with.
- unrelated: the weirdest behavior occurs with all these objects when you drag
them across a "freeze frames" boundary, even if the sheet is not scrolled past
the freeze frames origin.  The size of the dragged object changes dramatically,
and the position snaps at increasingly large increments the further away from
the boundary you get (you'll have to try it to see).  Perhaps this should be in
a separate bug.

Back to the original bug, if you or anyone has an example Excel sheet with a
text frame on it, I can re-test, otherwise it appears the printing is at least
partially fixed, but there are a bunch of other weird things that happen with
drawing objects now.

Actually, there are other controls that don't print too, such as the checkbox. 
I'm guessing this is because they are pure GTK widgets.  It's probably not as
much a problem as text frames not printing, but it would be nice to see the same
thing on paper that you see on the screen.  I imagine when GTK renders fully
through cairo this will all be easier, since you won't have to re-write any
renderers.

Textboxes should print now. There are several issues left:

Text in textboxes cannot be edited. Esseetially textboxes can only be imported from xls.

Frames, checkboxes, slides and scrollbars do not print.

Created attachment 132998 [details] [review]
Theoretical fix

In theory this patch should give the remaining sheet objects the ability of being printed. Unfortunately it requires gtk 2.14 plus bug fixes to gtk_widget_get_snapshot. In 2.14 itself it just crashes in X.

Note that the properties dialog for textboxes has been extended to allow editing of text.

We can test for gtk_widget_get_snapshot.  If it's not there, no widget
printing.  Over time that will solve itself.

Is there a gtk+ version from which it actually works?

I am not aware of any gtk version from where it actually works. That's why I called it a "Theoretical fix".

I also get a crash with gtk+ from current git:  GTK bug reported as 581829.

Let's call it bug 581829.  With that keyword, we get a link here.

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.

But it prints a bitmap of the screen image, ie. it looks _bad_.

Review of attachment 132998 [details] [review]:

A similar patch has been committed a while ago.

We are also failing to print these object when using ssconvert to pdf.

*** Bug 630335 has been marked as a duplicate of this bug. ***

How hard would it be to make our own bare-bones drawing for printing?

I don't even think we *want* to print widgets exactly as they appear
on screen: certainly we do not want prelight etc.

I see some action on this in git.

Obviously the question of where to get font and colour information from
then comes up.  It turns out that while we cannot create GtkWidgets without
a display, we can actually create a GtkStyle*

This prints "FD=[Sans 10]" for me:

	{
		GtkStyle *style = gtk_style_new ();
		g_printerr ("FD=[%s]\n", pango_font_description_to_string (style->font_desc));

		g_object_unref (style);
	}

Checkboxes now uses gtkstyle.

I intentionally didn't use GtkStyle since I hadn't figured out how to ensure the text to be placed in the right sport. Using "sans 10" I could hardcode the placement which I thought would be better than using theright font and having it placed to high or low as is likely happening now.

I have fixed the text placement issue.

We are now drawing (when printing) our own checkboxes and radio buttons.

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.