matplotlib-devel Mailing List for matplotlib

John Hunter wrote:
>>>>>>"Jochen" == Jochen Voss <vo...@se...> writes:
> 
> 
>     Jochen> Hello, I am very sorry about this, but I messed up the PS
>     Jochen> backend shortly before the release :-( While trying to
[...]
> No worries, we're used to doing bug fix releases around here.  Better
> that you caught it than some irate gnuplot user who comes around here
> complaining about matplotlib's PS file sizes :-)

hey! I was nice when I asked!  ;)

Best,

f

>>>>> "Jochen" == Jochen Voss <vo...@se...> writes:

    Jochen> I have another (more intrusive) patch ready, which strips
    Jochen> down the PostScript file size even more by removing about
    Jochen> 20 million gsave/grestore pairs per figure.  I tried the
    Jochen> backend_driver script and the patch seems to work.  Can I
    Jochen> also check this in, or should I be stabilising the
    Jochen> PostScript backend at the moment?

If it passes backend driver and appears logically correct to you,
check it in.  I added those 20 million pairs to be on the safe side
when I wrote the PS backend, but was never very happy about them.

JDH

Hello John,

On Thu, Nov 11, 2004 at 08:12:00AM -0600, John Hunter wrote:
> No worries, we're used to doing bug fix releases around here.  Better
> that you caught it than some irate gnuplot user who comes around here
> complaining about matplotlib's PS file sizes :-)
Well, everything is of course still dominated by the huge included
fonts, so they will probably not notice ;-)  Maybe I can start doing
something about this during the week-end.  Let's see ...

> Just commit the patch and in a few days as we iron out any remaining
> bugs that are discovered I'll post a bug fix release.
The patch is already in CVS.

I have another (more intrusive) patch ready, which strips down the
PostScript file size even more by removing about 20 million
gsave/grestore pairs per figure.  I tried the backend_driver script
and the patch seems to work.  Can I also check this in, or should I be
stabilising the PostScript backend at the moment?

All the best,
Jochen
--=20
http://seehuhn.de/

>>>>> "Jochen" == Jochen Voss <vo...@se...> writes:

    Jochen> Hello, I am very sorry about this, but I messed up the PS
    Jochen> backend shortly before the release :-( While trying to
    Jochen> move a block of code I duplicated it instead.  The
    Jochen> consequence is, that PostScript files generated with
    Jochen> matplotlib 0.64 draw every bit of the figure twice.  The
    Jochen> output is still ok, but it is generated in an inefficient
    Jochen> way.

    Jochen> Luckily at least the huge PostScript fonts are only
    Jochen> included once.


    Jochen> Again, I am very sorry about this, Jochen --

No worries, we're used to doing bug fix releases around here.  Better
that you caught it than some irate gnuplot user who comes around here
complaining about matplotlib's PS file sizes :-)

Just commit the patch and in a few days as we iron out any remaining
bugs that are discovered I'll post a bug fix release.

JDH

Hello,

I am very sorry about this, but I messed up the PS backend shortly
before the release :-(  While trying to move a block of code I
duplicated it instead.  The consequence is, that PostScript files
generated with matplotlib 0.64 draw every bit of the figure twice.
The output is still ok, but it is generated in an inefficient way.

Luckily at least the huge PostScript fonts are only included once.

The problem can be fixed with the following patch
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
diff -u -r1.10 backend_ps.py
--- backend_ps.py       5 Nov 2004 11:05:14 -0000       1.10
+++ backend_ps.py       11 Nov 2004 13:08:43 -0000
@@ -585,16 +585,6 @@
=20
         # write the figure
         print >>fh, renderer.get_ps()
-        origfacecolor =3D self.figure.get_facecolor()
-        origedgecolor =3D self.figure.get_edgecolor()
-        self.figure.set_facecolor(facecolor)
-        self.figure.set_edgecolor(edgecolor)
-
-        renderer =3D RendererPS(width, height, fh)
-        self.figure.draw(renderer)
-
-        self.figure.set_facecolor(origfacecolor)
-        self.figure.set_edgecolor(origedgecolor)
=20
         # write the trailer
         print >>fh, "grestore"
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Again, I am very sorry about this,
Jochen
--=20
http://seehuhn.de/

Hello John,

On Thu, Nov 11, 2004 at 06:22:11AM -0600, John Hunter wrote:
> This looks very good and will remove a pesky problem, so yes, plase
> commit it.  Can we build tk w/o an X11 connection.  If memory serves,
> there was an X requirement for tk..
My patch only fixes GTK and GtkAgg.  I do not know much about tk,
but maybe a similar patch will help there?

All the best,
Jochen
--=20
http://seehuhn.de/

>>>>> "Jochen" == Jochen Voss <vo...@se...> writes:

    Jochen> Hello, currently the GTK backends for matplotlib won't
    Jochen> build without an X-server connection.  The following patch
    Jochen> fixes this:

    Jochen> It makes use of the fact the the import of gtk fails with
    Jochen> an RuntimeError instead of an ImportError when the module
    Jochen> is present but not X-server is there.  Do you think that
    Jochen> this is safe to commit?  Or will it have unwanted
    Jochen> side-effects?

    Jochen> I hope this helps, Jochen -- http://seehuhn.de/

Hi Jochen

This looks very good and will remove a pesky problem, so yes, plase
commit it.  Can we build tk w/o an X11 connection.  If memory serves,
there was an X requirement for tk..

JDH

Hello,

currently the GTK backends for matplotlib won't build without
an X-server connection.  The following patch fixes this:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- setup.py    4 Nov 2004 15:58:57 -0000       1.108
+++ setup.py    11 Nov 2004 09:54:24 -0000
@@ -122,11 +122,16 @@
 build_transforms(ext_modules, packages, NUMERIX)
    =20
 if BUILD_GTKAGG:
-    try: import gtk
-    except ImportError: print 'GTKAgg requires pygtk'
-    else:
-        BUILD_AGG =3D 1
-        build_gtkagg(ext_modules, packages)
+    try:
+        import gtk
+    except ImportError:
+        print 'GTKAgg requires pygtk'
+        BUILD_GTKAGG=3D0
+    except RuntimeError:
+        print 'pygtk present but import failed'
+if BUILD_GTKAGG:
+    BUILD_AGG =3D 1
+    build_gtkagg(ext_modules, packages)
=20
 if BUILD_TKAGG:
     try: import Tkinter
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

It makes use of the fact the the import of gtk fails with an
RuntimeError instead of an ImportError when the module is present
but not X-server is there.  Do you think that this is safe to
commit?  Or will it have unwanted side-effects?

I hope this helps,
Jochen
--=20
http://seehuhn.de/