Push seems to have failed.  Will retry tomorrow.

So the order of the gnm:SheetObjectGraphic is changing. Quite a few of these differences would be gone if we can get the order fixed.

Oh.

That order (the z order, possibly reversed) is determined by the other
you call sheet_object_set_sheet.

We have code (in oo_table_end) that is intended to adjust the object placement as well as the z order. On any smallish example I can make up, that seems to work correctly but obviously fails on the file used for this test.

There are only 5-6 instances of "z-index" in the generated file.
That means most are made up inside oo_table_end.  I'm not sure
how that can be expected to work.

Anyway, I think you need to loop: one to calculate "top" and one to
assign numbers to those missing.  Right now I think you get duplicates
until the point where you meet the biggest z-order.

Hmm, I f I save the file in question as ODS and open it with current git, all colours are gone. If I open the same file with Gnumeric 1.12.6 the stroke colours (not the fill colours) are correct. So from 1.12.6 to now we had some regression. (Note if I open the file in LO, it looks like if it were opened in 1.12.6 minus the frames)

The z-ordering should be better now. We neither wrote nor read the z-ordering for lines and on reading gave them the z-order of the previously read object.

We apparently are not handling colours any more....

The stroke colour issue seems to be (incorrectly) summarized by a comment in the code:

	/*
	 * Stroke colour is tricky: if we have lines, that is what it
	 * refers to.  Otherwise it refers to markers.
	 */

This comment may be correct for styles applied to graphs, but for styles that apply to sheet objects "we have lines" has no meaning I think.

We get the stroke colours back with:	
/*
	 * Stroke colour is tricky: if we have lines, that is what it
	 * refers to.  Otherwise it refers to markers.
	 */
	/* if (!gnm_auto_color_value_set) */
	/* 	gnm_auto_color_value = !stroke_colour_set; */

	/* style->line.auto_color = (lines_value ? gnm_auto_color_value : TRUE); */

but that is likely to break marker colours and/or other chart related things.

I have fixed the stroke colour issue (by distinguishing between chart context and sheet object context).

Note that
../test/t6516-graph.pl --subtests ods
shows some issues again but they are unrelated to this change. 

We still have fill colour issues remaining for
../test/t6518-objects.pl --subtests ods

That's already looking at lot better.

For a filled object for which a fill colour is explicitly set, style->fill.auto_type still appears to be true. That causes us not to write the fill-type and fill -colour...

go_style_fill_sax_save seems to output "type" unconditionally.  That's
really a bug.

Anyway, auto_type just means that the *type* is automatic, probably solid.
That should not affect the colours.

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.