The problem is somewhere between GOImage (which contains some really
strange code) and sheet-object-image.c

If I save object-tests.gnumeric to ods and then open the archive to look at the file, I get a 0 byte image file. Clearly that does not work.

Note that this defintely used to work fine.

To save the file we have:

 static void
odf_write_images (SheetObjectImage *image, char const *name, GnmOOExport *state)
{
	char *image_type;
	char *fullname;
	GsfOutput  *child;
	GByteArray *bytes;

	g_object_get (G_OBJECT (image),
		      "image-type", &image_type,
		      "image-data", &bytes,
		      NULL);
	fullname = g_strdup_printf ("Pictures/%s.%s", name, image_type);

	child = gsf_outfile_new_child_full (state->outfile, fullname, FALSE,
							"compression-level", GSF_ZIP_DEFLATED,
							NULL);
	if (NULL != child) {
		gsf_output_write (child, bytes->len, bytes->data);
		gsf_output_close (child);
		g_object_unref (child);
	}

	g_free (fullname);
	g_free (image_type);

	odf_update_progress (state, state->graph_progress);
}


For the image in question, it turns out that the GByteArray we get has: odf_write_images: Pictures/Image1.jpeg bytes: 0x1128588 len: 0
(adding g_print ("odf_write_images: %s bytes: %p len: %i\n", fullname, bytes, bytes->len); before child = ...)

SO we are not getting any data for the image to write.

I think it depends on how the image is created.

xls export is suffering from the same thing you see in ods.

The situation is better now.  "Better", not "good".

The Gnumeric file contains the image in gdk-pixbuf format, around 20k.
It claims to have the jpeg file there.  That would have been around 6k.
This makes the ods export create a file with a jpeg name containing
gdkpixbuf data.

What a mess.

I think GOImage needs to be taught to keep the original image data around.
We could, in principle, recreate jpeg data, but it is lossy.  Thus I don't
want to do that.

GOImage does not know the original data for png and jpeg, but it is easy to change that, I suppose. When original data are saved we don't need to save the "rowstride" property, so it will be easy to diffentiate between the two situations.
We also need to get the image data when they are stored only in GOImage. This is something I missed, sorry.

Created attachment 298173 [details] [review]
Proposed patch for goffice

This preserves the original data for newly cretaed images and restores valid data for older ones if needed.

Created attachment 298174 [details] [review]
Patch for gnumeric

Feel free to commit.

Note, though, that I already introduced a go_pixbuf_new_from_data but
that it takes arguments in a different order -- sorry about that.

I don't see your version of go_pixbuf_new_from_data(). Did you commit it?

Comment on attachment 298174 [details] [review]
Patch for gnumeric

Commited the still needed part of it.

This problem has been fixed in our software repository. The fix will go into the next software release. Once that release is available, you may want to check for a software upgrade provided by your Linux distribution.

Feel free to reopen if I missed something.

Looks good to me.

Created attachment 298932 [details] [review]
baseparse: respect DISCONT flag on buffers

Drain the parser when a DISCONT buffer is received and then mark
the next buffer to be pushed as a DISCONT one

Thiago?

Sorry, typo when attaching with git-bz