[cairo] external backends
rogelio at smsglobal.net
Sun Aug 8 17:16:44 PDT 2004
I thought cairo was the PDF backend.
On 2004-08-09 08:02:59 +0800 Ross McFarland <rwmcfa1 at neces.com>
> 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
>> 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
>> 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
> 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.
More information about the cairo