Bug 25238

This problem is caused by the following code snippet in cairo-path-fixed.c.
cairo_status_t
_cairo_path_fixed_close_path (cairo_path_fixed_t *path)
{
    cairo_status_t status;

    if (! path->has_current_point)
	return CAIRO_STATUS_SUCCESS;

    status = _cairo_path_fixed_add (path, CAIRO_PATH_OP_CLOSE_PATH, NULL, 0);
    if (status)
	return status;

    status = _cairo_path_fixed_move_to (path,
					path->last_move_point.x,
					path->last_move_point.y);
    if (status)
	return status;

    return CAIRO_STATUS_SUCCESS;
}

My suggestion is to check the surface type before calling _cairo_path_fixed_move_to(). If the surface type is PDF, do not call _cairo_path_fixed_move_to().

Created attachment 31617 [details]
Test-case

The same problems happen in SVG and PS, too.

This would probably be best fixed either by ignoring any trailing MOVE_TO in _cairo_path_fixed_interpret or by avoiding to add a MOVE_TO after each CLOSE_PATH.
The first fix would keep current path semantic, the second one would have the advantage that any sequence of
([move_to|line_to|curve_to]* close_path)* stroke
and the corresponding sequence of
([move_to|line_to|curve_to]* close_path stroke)*
where each closed path part is stroked right after closing would draw the same lines (the result might be different because of compositing, but at least no line would appear/disappear).

This bug has been causing problems for inkscape users using PostScript output:

https://bugs.launchpad.net/inkscape/+bug/492773

Created attachment 31890 [details] [review]
Fix

I just pushed to cairo/master a patchset that changes how the path is constructed (internally).
One of the changes makes the final move_to disappear (because move_to's are now only added when there is a drawing operation after them).
Even if this approach is different from the two fixes I had proposed, it solves this problem.
Please test and reopen if the problem is still happening to you.