Currently, cairo_fill goes directly to the backend fill_path function
which means that a filled cairo path ends up as a filled PDF path (for
instance). However, cairo_stroke tessellates to trapezoids and goes
through the backend composite_trapezoids functions. This means that a
stroked path ends up as a bunch of filled trapezoids in the PDF output
(for instance).

This results in larger file sizes than we really want, and it also causes
less scalable results, (since the curves are flattened to within the
cairo tolerance given its knowledge of the output DPI).

We've discussed reasons not to make a stroke_path backend function, (such
as buggy stroke implementations in many/most?/all? PostScript implementations).
It might make sense to try to characterize such bugs and use a backend
stroke_path when we trust it, but that would be another project.

For now, what I would like is for cairo_stroke to generate the outline of
the stroke and then use backend_surface->fill_path on that. This should help
with file size quite a bit. The simplest implementation won't solve the
scaling problem, but I don't think it would be too hard to fix the stroking
algorithm to actually generate a stroke outline with curves rather than an
entirely flattened outline.