[cairo] Proposal to disable PDF and PS backends by default for 1.0

[Owen Taylor]

On Wed, 2005-08-24 at 14:46 +0100, Gustavo J. A. M. Carneiro wrote:
>   Hello,
> 
> On Wed, 2005-08-24 at 05:12 -0700, Carl Worth wrote:
> > As sad as it is to do so, I think the right thing to do at this point
> > is to disable-by-default the PDF and PostScript backends and mark them
> > as experimental in the 1.0 release notes. This is definitely a shame
> > as we won't have a solid implementation of display-and-print in 1.0,
> > but we still have a solid story about where we're headed in that area.
> > 
> > And I think it's actually better to avoid advertising as complete
> > backends that just aren't quite there yet.
> > 
> > I think the important thing here is to look at 1.0 for what it
> > is---the beginning---and move forward quickly to lots of improved
> > versions of cairo down the road.
> 
>   As much as I admire your desire to have a perfect 1.0 implementation,
> when deciding whether GNOME 2.12 would adopt gtk+ 2.8 with cairo, you
> said[1]:
> 
> 	"I just updated the ROADMAP[1] to reflect our current plans, which is
> 	  that all API _changes_ are scheduled for an as-soon-as-possible 0.6,
> 	leaving just a couple of API additions on the 1.0 roadmap."
> 
>   Well, removing PDF/PS backends is a _huge_ API break, but you were
> supposed to only make API _additions_ after 0.6 release.

There is a context for every statement; Cairo is structured as a core
API and a swarm of backends. There are some backends that are clearly
unstable (Quartz) or depend upon unstable libraries (XCB, glitz).
We can't make API guarantees there. On the other hand, for the 
parts of the API that GTK+ is depending on we can make a very
solid API guarantees.

The basic fact is that these backends don't really fully work. On,
say, a Fedora system (where the default Sans-Serif font is the 
postscript version of Luxi Sans), drawing with either the PDF or
PS backend will produce no output, since Type1 font embedding
code isn't there yet.

I don't think this is a black and white question. When balancing
the problem of someone trying to use the PDF or PS backend and
getting frustrated when things don't work or it crashes versus
the partial utility we have now, I could go either way.

But we really are concentrating on the deadlines and stability
guarantees we need to have for GNOME-2.12 at the moment; and
the printing API of GNOME-2.12 is libgnomeprint. The PS and PDF
backends are not relevant to that.

>   Even with that consideration apart, I don't think disabling the PDF
> backend just because the gradients don't look so good is a sound idea.
> Sure, go ahead and document it as experimental, but please don't disable
> them by default, they are still useful.  Many applications out there
> don't need to use gradients, and so do not trigger these bugs.  But if
> this backend is disabled by default, and if distributions follow this
> default, people won't test it, you don't get bug reports, and it won't
> improve much, leaving GNOME stuck with a buggy PDF library again in 6
> months.  

My guess is that that we'd enable these backends immediately again in
CVS after the release; patches to fix some of the major outstanding
issues are close to being ready to land. These backends are in no
way being abandoned, but what we don't want to do is "false advertising"
that we have PS and PDF backends fully working when they aren't.

> And cairo was supposed to bridge the gap between screen and
> printing worlds; if both PS and PDF backends are left out, imho it is
> failing the main goal, and is only marginally useful.

Having an *API* that can bridge screen and printing and starting to
use that is quite valuable, even if we don't have finished
implementations of the printing side.

Regards,
						Owen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/cairo/attachments/20050824/f0794be3/attachment-0001.pgp