I found that there are some dummy move_to instructions in uncompressed PDF output. See the following part of PDF content for example. 0 0.26 0.6 rg 373 198 m 377 200 l 382 200 l 378 198 l h 373 198 m f 0.26 0.26 0.26 RG 373 197.5 m 377 199.5 l 382 199.5 l 378 197.5 l h 373 197.5 m S It is better to remove the dummy "* * m" between "h" and "f/S". In cairo's archive, I found a related topic at http://lists.cairographics.org/archives/cairo/2008-February/013104.html Thanks.
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.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.