[cairo] SVG backend patch

[Emmanuel Pacaud]

Le lundi 01 août 2005 à 22:50 -0400, Kristian Høgsberg a écrit :
> I agree, it should be possible to output strokes as svg stroked paths, 
> but it's one of those things we've been discussing back and forth.  The 
> short story is that stroking a path is hard and most ps/pdf/svg 
> renderers expose some bugs and misrenderings when you go to extremes 
> (very thick stroked paths doing sharp bends).  Cairo's algorithm for 
> stroking paths is fairly simple and roboust, and by outputting the 
> trapezoids, cairo output will look good even in renderers that have 
> problems with these corner cases.

I guess one solution is to only use good SVG renderers based on cairo :)

Anyway, I agree with your proposal of proposing two different output
qualities: either accurate or compact in size.

> Now, outputting the trapezoids creates a huge and uneditable svg file, 
> and is not what we want in any case.  Right now the stroking algorithm 
> produces trapezoids directly, but the goal is to rewrite it to produce a 
> new path that is the outline of the stroke and then fill that path. 
> With this in place, the PDF, PS and SVG backends need not implement 
> composite_trapezoids, since all drawing will go through fill_path.

Yes, this would produce an acceptable SVG output. In my opinion, current
composite_trapezoids output is not acceptable: it generates a lot of
data, and having a lot of adjacent surfaces produces rendering
artifacts.

> > What is also new in this version is the use of libxml. Please tell me if
> > you feel this is wrong (or anything else in the patch).
> 
> I'm not convinced that we need libxml.  It's a big, somewhat political 
> dependency, and we won't be using very much of it.  I think that 
> instead, if you feel that the cairo_output_stream_t API is awkward, you 
> should look into adding the convenience functions you need, for example
> 
>    cairo_output_stream_print_tag (stream, "path", "style", style, NULL);
> 
> even though that example doesn't seem too useful to me :-)  What I was 
> thinking of was something like
> 
>    cairo_output_stream_printf (stream, "<path");
>    emit_pattern (pattern, stream);
>    cairo_output_stream_printf (stream, "/>\n");
> 
> and in emit_pattern:
> 
>    cairo_output_stream_printf (stream, " style=\"color: red;\");

I'm using a bit more of libxml than that, but I agree this library is
not absolutly required. But for now I'll continue to use it for
convenience. When this backend will reach an almost feature complete
state, this dependency could be removed.

> A general comment: the cairo indent style is 4 spaces and further 
> documented in the CODING_STYLE file.

I know. I'll fix that later. I just have to figure out how to
automatically configure vim when I'm switching between different
projects with different coding styles.

> > +cairo_int_status_t
> > +_cairo_surface_stroke (cairo_operator_t		operator,
> > +		       cairo_pattern_t		*pattern,
> > +		       cairo_surface_t		*dst,
> > +		       cairo_path_fixed_t	*path,
> > +		       double			line_width,
> > +		       cairo_line_cap_t		line_cap,
> > +		       cairo_line_join_t	line_join,
> > +		       double			miter_limit,
> > +		       double			*dash,
> > +		       int			num_dashes,
> > +		       double			dash_offset,
> > +		       cairo_matrix_t		*ctm_inverse)
> > +{
> > +	if (dst->backend->stroke)
> > +		return dst->backend->stroke (operator, pattern, dst, path,
> > +					     line_width, line_cap, line_join, miter_limit,
> > +					     dash, num_dashes, dash_offset, ctm_inverse);
> > +	else
> > +		return CAIRO_INT_STATUS_UNSUPPORTED;
> > +}
> 
> The name of the function shold be stroke_path, i.e. 
> _cairo_surface_stroke_path and backend->stroke_path to match up with 
> fill_path.  

Ok.

> Also, I've been thinking that instead of passing around all 
> the line attributes (width, cap, join, miter limit, dashes) we could 
> group them in a cairo_line_attributes_t struct in cairo_gstate_t and 
> pass a pointer to that struct to _cairo_surface_stroke_path.

Agreed. 

Thanks for your comments.

	Emmanuel.