[cairo] Paths as paths

[Carl Worth]

On Sat, 05 Mar 2005 15:10:27 -0500, Owen Taylor wrote:
> The attached patch adds a new virtual function fill_path() to the
> surface backend interface. If it returns UNSUPPORTED then the current
> logic is run. And then implements a fill_path() for the PDF backend.

This looks good to me.

> To keep the patch from touching every single backend, I made NULL
> for fill_path be equivalent to UNSUPPORTED ... this is actually 
> something I'd like to see implemented uniformly across all backend
> functions.

Yes, I'd like that as well.

> Perhaps some sort of hybrid approach is right. We could actually
> try to detect paths that will produce problems with stroking
> algorithms that convert curve => polygon before stroking and emit
> those strokes as paths.

When I've considered this issues, this is the approach I've liked the
most. The problem with the quality-of-implementation approach is that
it blows big holes in our story for consistent output between display
and print backends. We'd be left with something like "You do get
consistent print output, unless your downstream print system has
bugs. Oh, and by the way, pretty much all existing print systems have
bugs that we're aware of." I'd like to avoid that, and it doesn't seem
like it will be too hard to characterize the bugs we've found so far.

As for lack of resolution-independent output, I don't see a major
problem here. The current model is that file output from cairo is
primarily destined for final output, not further manipulation, so
generate things at known, (or highest anticipated), resolution.

It *might* make sense to create a separate, high-level, output backend
for cairo, that would be suitable for creating resolution-independent
PDF, or editable SVG. But then again, it might not. Cairo wouldn't be
providing much in this case, as it would just be passing data directly
from the user to the various backends. And there would be a ton of
things that PDF/SVG file creators would like to do that would be
unavailable. So, we'd end up with a very limited PDF/SVG abstraction
layer, that happens to have the same API as the display/print drawing
layer. Would that be useful?

It's not obvious to me that it is, so I don't plan to add that unless
it becomes so. (The work involved would not be difficult, but that's
far from being a primary criteria.)

> Anyways, I don't think we need to block on fixing strokes to fix
> paths.

Agreed. Feel free to commit this as far as I'm concerned.

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20050307/950ed1fd/attachment.pgp