Bug 25238

Summary: Dummy final move_to in PDF output
Product: cairo Reporter: Lance <lliu>
Component: generalAssignee: Andrea Canciani <ranma42>
Status: RESOLVED FIXED QA Contact: cairo-bugs mailing list <cairo-bugs>
Severity: normal    
Priority: medium CC: lliu, ranma42
Version: 1.8.8   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments: Test-case
Fix

Description Lance 2009-11-22 23:21:56 UTC
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.
Comment 1 Lance 2009-11-23 17:38:18 UTC
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().
Comment 2 Andrea Canciani 2009-12-01 01:43:45 UTC
Created attachment 31617 [details]
Test-case

The same problems happen in SVG and PS, too.
Comment 3 Andrea Canciani 2009-12-01 01:45:37 UTC
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).
Comment 4 Adrian Johnson 2009-12-06 05:44:00 UTC
This bug has been causing problems for inkscape users using PostScript output:

https://bugs.launchpad.net/inkscape/+bug/492773
Comment 5 Andrea Canciani 2009-12-09 10:45:01 UTC
Created attachment 31890 [details] [review]
Fix
Comment 6 Andrea Canciani 2010-10-29 10:50:16 UTC
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.