Carl Worth wrote:
> On Thu, 12 Jul 2007 11:35:25 -1000, Eric Firing wrote:
>> Carl Worth wrote:
>>
[...]
> Later, you said...
>
>> Aha! Cairo ps output is full of "initclip" commands, so it can't be
>> converted to eps without substantial reworking.
>
> Oh, actually that should be really easy to
On 7/12/07, Carl Worth <[EMAIL PROTECTED]> wrote:
> Anyway, I'll try to get setup to profile the cairo run above and see
> if any obvious things stick out that could be easily fixed.
Most likely, the biggest win by far will be to implement draw_markers.
You will see the start of an attmept in dr
On Thu, 12 Jul 2007 11:35:25 -1000, Eric Firing wrote:
> Carl Worth wrote:
>
> > It sounds like something that should be really easy to change in
> > cairo.
>
> Yes, so much so that I don't understand why it is not already done. (I
> know you are a cairo dev--is there not a postscript specialist i
On Thursday 12 July 2007 5:57:27 pm Eric Firing wrote:
> Carl Worth wrote:
> [...]
>
> > But yeah, I also understand that there are licensing concerns.
> > Anything else? Are there cairo performance concerns? If so, I'd love
> > to hear about them so we can fix them.
>
> Backend cairo.ps took 0.87
Darren Dale wrote:
> On Thursday 12 July 2007 05:11:31 pm Carl Worth wrote:
>> On Thu, 12 Jul 2007 10:31:19 -1000, Eric Firing wrote:
>>> if only cairo would make eps files
>> Isn't EPS a trivially change compared to PS? Something like a modified
>> header and the addition of bounding-box informati
Carl Worth wrote:
[...]
> But yeah, I also understand that there are licensing concerns.
> Anything else? Are there cairo performance concerns? If so, I'd love
> to hear about them so we can fix them.
Backend cairo.ps took 0.87 minutes to complete
Backend ps took 0.66 minutes to complete
So the m
Carl Worth wrote:
> On Thu, 12 Jul 2007 10:31:19 -1000, Eric Firing wrote:
>> if only cairo would make eps files
>
> Isn't EPS a trivially change compared to PS? Something like a modified
> header and the addition of bounding-box information?
Carl,
My knowledge of graphics topics is sketchy, but
On Thursday 12 July 2007 05:11:31 pm Carl Worth wrote:
> On Thu, 12 Jul 2007 10:31:19 -1000, Eric Firing wrote:
> > if only cairo would make eps files
>
> Isn't EPS a trivially change compared to PS? Something like a modified
> header and the addition of bounding-box information?
The following is
On Thu, 12 Jul 2007 10:31:19 -1000, Eric Firing wrote:
> if only cairo would make eps files
Isn't EPS a trivially change compared to PS? Something like a modified
header and the addition of bounding-box information?
It sounds like something that should be really easy to change in
cairo.
Maybe yo
John Hunter wrote:
> On 7/12/07, Eric Firing <[EMAIL PROTECTED]> wrote:
>> John Hunter wrote:
>
>> Do all the backend devices or libraries we *need* now support compound
>> paths (1) at all, and (2) in a consistent enough way to solve the
>> contouring problem as well as to make something like pol
Michael Droettboom wrote:
> cntr.c is creating the inner and outer
> polygons correctly, just not connecting them with a slit, right?
>
To answer my own question, unfortunately, this isn't always the case.
There is also a bug where if a masked region is inside of the *inner*
polygon of a con
On 7/12/07, Carl Worth <[EMAIL PROTECTED]> wrote:
> What's the "GTK drawing model" here that is problematic? Is that
> pre-cairo stuff? And can using cairo directly help at all?
Yes, this is pre cairo and unfortunately, no I don't think cairo can
help. When I wrote MPL, it was GTK only and I use
On 7/12/07, Eric Firing <[EMAIL PROTECTED]> wrote:
> John Hunter wrote:
> Do all the backend devices or libraries we *need* now support compound
> paths (1) at all, and (2) in a consistent enough way to solve the
> contouring problem as well as to make something like polygon collections
> more eff
On Thu, 12 Jul 2007 09:29:06 -1000, Eric Firing wrote:
> > So one reason why the backends are a bit of a kludge is because we
> > have tried to throw some extra stuff into the GTK drawing model as an
> > afterthough. We could redo all the collection stuff w/ compounds
> > paths.
What's the "GTK d
John Hunter wrote:
[...]
> So one reason why the backends are a bit of a kludge is because we
> have tried to throw some extra stuff into the GTK drawing model as an
> afterthough. We could redo all the collection stuff w/ compounds
> paths.
John,
Do all the backend devices or libraries we *nee
John Hunter wrote:
> On 7/12/07, Michael Droettboom <[EMAIL PROTECTED]> wrote:
>
>> It looks like that the backend API isn't really set up to do compound
>> paths. The PolygonCollection class appears to be just a list of simple
>> polygons, rather than something that could be used for compound pa
On 7/12/07, Michael Droettboom <[EMAIL PROTECTED]> wrote:
> It looks like that the backend API isn't really set up to do compound
> paths. The PolygonCollection class appears to be just a list of simple
> polygons, rather than something that could be used for compound paths.
> (Correct me if I'm
Eric,
Thanks for the scripts -- they make it quite clear what the problem is.
As you know, cntr.c is a fairly opaque chunk of code, and I'm not having
much luck so far tracking down why the branch-cutting between the outer
and inner polygons is not working.
In the meantime, I have some more ge
Mike,
The attached file masked_interior.py illustrates masking failure in a
very simple case; you can see masking working in the plot on the left,
where a contour intersects the masked region, but when that contour
level is removed the masked region is getting filled in.
The file contourf_de
19 matches
Mail list logo