[cairo] external backends

[Rogelio Serrano]

I thought cairo was the PDF backend.

On 2004-08-09 08:02:59 +0800 Ross McFarland <rwmcfa1 at neces.com> 
wrote:

> On Sun, 2004-08-08 at 17:04, Jamey Sharp wrote:
>> Well, it's easier to just install a separate header file. :-)
> 
> very much agree there.
> 
>>> in the long run i would envision cairo's core becoming 
>>> rather stable and
>>> development on it slowing. i don't see this being the case 
>>> as much for
>>> backends. i would imagine there will always be new 
>>> situations required
>>> new backends or at least changes to existing backends.
>> 
>> That's the problem.
>> 
>> If you're willing to always work in terms of giant images or 
>> lists of
>> trapezoids, then the current interface between the Cairo core 
>> and the
>> backends is good enough. Somebody could move a few functions 
>> from the
>> current non-installed headers to a new installed header, and 
>> then the
>> backends could be pulled out of the library.
>> 
>> But to efficiently implement a Cairo backend, it makes a lot 
>> of sense to
>> hook at higher semantic levels. For example, a PDF backend 
>> could
>> transform cairo_move_to, cairo_line_to, and cairo_stroke 
>> calls directly
>> into the equivalent PDF commands. (There may be reasons to 
>> not do this,
>> but I needed an example.)
> 
>> So it's hard to design an API that's flexible enough to allow 
>> efficient
>> implementation, and as a result keeping the backends inside 
>> the main
>> Cairo library has seemed like the best idea so far.
>> 
>> I could see a multi-level backend API making some sense, 
>> perhaps. The
>> existing images/trapezoids interface would be a low-level 
>> API, but as
>> uses are found for higher-level hooks, new backend APIs can 
>> be added.
> 
> that's the exact problem i ran into when i did the pdf backend 
> a few
> months ago. working with the current backend api wasn't ideal.
> 
> after putting a bit of thought into it i came to the 
> conclusion (though
> not very well thought through) that cairo might should be 
> broken into
> three pieces. the application api, the middleman, and the 
> backend. the
> app api would never change. the middle man could be the 
> current stuff
> between that api and the backends, or something else like pdf. 
> and then
> the backends would only be around when the current "middleman" 
> was used.
> as i said this hasn't been thought through or investigated any 
> further
> than brainstorming. i actually had two other messages to 
> follow this
> thread (one of which was going to discuss this and another was 
> going to
> re-present the colorspace discussion from a while back.) i 
> figured it
> best to take one at a time though.
>