[Date Prev][Date Next][Thread Prev][Thread Next][Thread Index]
RE: [XaraXtreme-dev] EPS export
- From: "Gerry Iles" <GerryI@xxxxxxxx>
- Date: Mon, 12 Jun 2006 18:26:05 +0100
- Subject: RE: [XaraXtreme-dev] EPS export
I'm not actually implementing any plugin filters other than the
test/example filter. I'm certainly not currently porting any of the
existing internal filters into plugin ones.
I don't agree that the EPS filters should be reimplemented as plugins
for precisely the reason you gave, Alex. All the EPS based filters and
postscript printing use the same code to "render" our tree structure as
postscript and this code uses at least one technique that the plugin
filter system doesn't (outputting masked bitmaps for rasterised objects
that include non-alpha compatibly transparency).
For import it makes more sense to write a plugin filter though it would
probably be easiest to do this by writing a Xar format "output device"
for Ghostscript and then interfacing to that. This would give us
(admittedly limited unless a lot of tricky object combination were
implemented) import filters for all the file types that Ghostscript
supports. Would it also give people the ability to print to a Xar file
from other applications in the same way as the print to PDF option?
I would say that if we rely on external developers to implement all our
existing EPS based filters as plugins then they wont be ready by the
time 1.0 is released.
From: owner-dev@xxxxxxxxxxxxxxxx [mailto:owner-dev@xxxxxxxxxxxxxxxx] On
Behalf Of Alex Bligh
Sent: 12 June 2006 17:45
Cc: Alex Bligh
Subject: Re: [XaraXtreme-dev] EPS export
Charles Moir wrote:
> To be honest, going forward, the EPS filter should be done using the
> filter mechanism. This would be a lot more maintainable, much easier
> develop and understand (you wouldn't have to know anything at all
> any render region stuff, or indeed any Camelot internals at all) and
> because of this would be much more likely to be maintained by people
> the open source world I would suspect. The new filter mechanism is a
> plug-in and so just a lot, lot better.
Yes I agree. But sadly ps printing seems to share code with the existing
EPS filter code, which is why I'm trying to get it to work.
Gerry - am I wasting my time if I try and get the Illustrator,
Corel and Freehand ones working too? (i.e. are you replacing them).