John (and others),
I've made a quick change to the svg backend to cull the data, see attached
patch. I haven't tested it extensively, but it seems OK. It culls both
lines and polygons out of svg output.
About making it general across backends: I've looked a bit at how things
get rendered, and her
Michael Droettboom wrote:
> Here's simple_plot.ps generated with the old PS backend.
Crash! Again, with 400% magnification. So now you really are off the hook.
[EMAIL PROTECTED]:~/programs/py/mpl/tests$ evince simple_plot_ps.ps
ERROR: /unknownerror in --%op_show_continue--
Operand stack:
Execu
Eric Firing wrote:
> Michael Droettboom wrote:
>> Even if my Postscript is to spec, it's not terribly useful if it
>> crashes a very popular tool ;)
>>
>> I'm curious -- does the file fail if you set "ps.fonttype: 42" in
>> your matplotlibrc? That would at least rule out anything non-font in
>>
Michael Droettboom wrote:
> Even if my Postscript is to spec, it's not terribly useful if it crashes
> a very popular tool ;)
>
> I'm curious -- does the file fail if you set "ps.fonttype: 42" in your
> matplotlibrc? That would at least rule out anything non-font in the file.
Aha! You may be
On Mon, July 9, 2007 10:57 am, John Hunter wrote:
> I wonder if you cached some of the interval tests whether you might
> see some additional speedups. Eg, something like
>
You could do this, but I don't think you would even notice the difference.
Really, my impression is that the only thing
Even if my Postscript is to spec, it's not terribly useful if it crashes
a very popular tool ;)
I'm curious -- does the file fail if you set "ps.fonttype: 42" in your
matplotlibrc? That would at least rule out anything non-font in the file.
I just built my own ESP Ghostscript 815.04 and am abl
Oh dear. It works for me with my fairly old version of GNU ghostscript
(7.07) and a couple different Postscript HP laser printers I tried. The
file position where the error occurs at least seems plausible -- it's
where the first text is shown.
I'll have to look into this further. More data p
Michael Droettboom wrote:
[...]
> All should be in SVN.
Mike,
Now it compiles and runs all the demos, and displays OK at normal
resolution; but when I try to show it with gv or evince at 400%, gs crashes:
[EMAIL PROTECTED]:~/programs/py/mpl/matplotlib_units/examples$ evince
simple_plot_ps.ps
ER
On 7/9/07, Paul Kienzle <[EMAIL PROTECTED]> wrote:
> This change works for me under wx os OS X.
> I got the gui_paint idea from examples/dynamic_demo_wx.py. Replacing
> gui_paint with draw_idle seems to work okay there as well. I'll
> create a patch. Do you small patches like this on tracker as
On Mon, Jul 09, 2007 at 10:37:35AM -0500, John Hunter wrote:
> One minor bug I fixed for non wx backends in the (very cool)
> figure.canvas.mpl_connect("motion_notify_event",figure.canvas.hilite)
> functionality. gui_repaint is a wx only method, and I just commented
> it out and replaced the "draw
Eric Firing wrote:
> Michael Droettboom wrote:
>> Sorry about that. I didn't notice the SVN login error the first
>> time. It should be in SVN now.
>> The default is to output Type 3 fonts (i.e. the new way).
>>
>> Darren: you mean rcdefaults.py, not rcsetup.py, right? I can't find
>> an rcset
Michael Droettboom wrote:
> Sorry about that. I didn't notice the SVN login error the first time.
> It should be in SVN now.
>
> The default is to output Type 3 fonts (i.e. the new way).
>
> Darren: you mean rcdefaults.py, not rcsetup.py, right? I can't find an
> rcsetup.py.
Mike,
I renam
On 7/9/07, Michael Droettboom <[EMAIL PROTECTED]> wrote:
> Sorry about that. I didn't notice the SVN login error the first time.
> It should be in SVN now.
>
> The default is to output Type 3 fonts (i.e. the new way).
>
> Darren: you mean rcdefaults.py, not rcsetup.py, right? I can't find an
> rc
Sorry about that. I didn't notice the SVN login error the first time.
It should be in SVN now.
The default is to output Type 3 fonts (i.e. the new way).
Darren: you mean rcdefaults.py, not rcsetup.py, right? I can't find an
rcsetup.py.
Cheers,
Mike
John Hunter wrote:
> On 7/9/07, Darren D
On 7/9/07, Darren Dale <[EMAIL PROTECTED]> wrote:
> Could you be more specific about how to test your changes? I dont see anything
> in matplotlibrc.template, or in rcsetup.py, concerning the valid settings of
> ps.fonttype. (rc settings should be validated, have a default value, and have
> a comm
On Monday 09 July 2007 11:25:57 am Michael Droettboom wrote:
> An initial revision of TTF font subsetting has been committed to SVN.
Thank you for doing this.
[...]
> ttconv supports outputting a Type 42 font (without subsetting), so
> matplotlib's old Type 42 output has been replaced with ttconv
On 7/9/07, Paul Kienzle <[EMAIL PROTECTED]> wrote:
> On Sun, Jul 08, 2007 at 03:04:41AM -0400, Paul Kienzle wrote:
> > I submitted the 'contains' patch to the patch tracker on sourceforge.
>
> I've updated the 'contains' patch to handle figure enter/leave, at
> least on wx backends, and fixed a min
An initial revision of TTF font subsetting has been committed to SVN.
It seems to work for all tests run by backend_driver.py (with the
exception quiver_demo, which didn't seem to work without my changes either).
Some key results:
fonts_demo_kq_ps.py: 633518 -> 45232
mathtext_demo.py: 366268 -
On 7/9/07, Michael Droettboom <[EMAIL PROTECTED]> wrote:
>
> I am about to update the memory leak question in the FAQ, but I thought I'd
> run it by the list first. I removed language that talked about much earlier
> releases of mpl, and the paragraph about leaks in older versions of Numeric
> an
On 7/8/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> First, I noticed a bug in the version I sent before. I've attached a new
> version in patch form, to be applied from the base directory of a normal
> 0.90.1 installation with 'patch -p1 width)
thisoutsidey = (thisy<0 || thisy>height)
if (t
On Sun, Jul 08, 2007 at 03:04:41AM -0400, Paul Kienzle wrote:
> I submitted the 'contains' patch to the patch tracker on sourceforge.
I've updated the 'contains' patch to handle figure enter/leave, at
least on wx backends, and fixed a minor hit test bug in ellipse.
I've also removed the special
I am about to update the memory leak question in the FAQ, but I thought
I'd run it by the list first. I removed language that talked about much
earlier releases of mpl, and the paragraph about leaks in older versions
of Numeric and numarray. It seems like we should recommend numpy when
the us
On 7/9/07, Michael Droettboom <[EMAIL PROTECTED]> wrote:
> ...however, there are only about 40 patches between 2.12.3 and 2.13.2.
> Two of them are very crucial memory leak patches:
> When I patched 2.12.3 against these patches, the Python object leaks go
> away. There may be workarounds matplot
Eric,
It turns out that the key difference is in pygobject. I was using
2.13.2 (from source) here at work, and Ubuntu Feisty currently ships
2.12.3. 2.13.x is an unstable branch, of course, (gnome-related
packages follow the even/odd versioning scheme), so I shouldn't have
been using it to t
24 matches
Mail list logo
