[cairo] Paths as paths

[Gustavo J. A. M. Carneiro]

On Mon, 2005-03-07 at 11:33 -0500, Carl Worth wrote:
[...]
> 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.

  Yeah, but if Cairo starts generating 40 Meg files and peoples print
jobs start getting dropped due to limitations in bandwidth and file size
on the company print spool server, then Cairo is going to be exactly
worthless to these people, despite all technical achievements.  There
_must_ be a quality tradeoff setting available somehow, either as
backend option or simply the ability to use a different backend.

> 
> 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.

  Believe me, the little Cairo provides in this case is more than
enough, it is crucial.

  Imagine that you are making a graph generator, like graphviz, and you
want to produce EPS files embeddable in LaTeX, besides presenting it on
screen.  Do you think the programmer should have to write yet another
buggy library for writing EPS (since the default Cairo PS driver
produces huge files)?  Isn't it better to simply have an EPS driver in
Cairo, and use that instead?  I mean, very few programmer know the PS
language even if they have to produce graphics, even less the PDF binary
format.

>  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?

  Yes!

> 
> 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.

  Oh!.. if the patch was committed please disregard my comments :P

  Regards.

-- 
Gustavo J. A. M. Carneiro
<gjc at inescporto.pt> <gustavo at users.sourceforge.net>
The universe is always one step beyond logic.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3086 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20050308/539d1e63/smime.bin