matplotlib-devel Mailing List for matplotlib (Page 3)

Hello,
On Thu, Nov 11, 2004 at 09:30:31AM -0600, John Hunter wrote:
> >>>>> "Jochen" =3D=3D Jochen Voss <vo...@se...> writes:
>=20
> 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?
>=20
> 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.
I checked in the patch yesterday evening. The patch decreased the
total size of the PostScript files generated by backend_driver.py from
37MB to 31MB.
All the best,
Jochen
--=20
http://seehuhn.de/

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/

Hi there,
I hit a strange but in the code for logarithmic plotting. Executing the 
following code:
----------------------------------
from matplotlib.matlab import *
plot([1.,2.],[0.01,0.2])
gca().set_yscale('log')
show()
----------------------------------
gives the following traceback:
------------------------------------
Traceback (most recent call last):
 File "./matplotlib-bug.py", line 4, in ?
 show()
 File 
"/home/nobbi/NNlab/install/lib/python2.3/site-packages/matplotlib/backends/backend_tkagg.py", 
line 68, in show
 manager.show()
 File 
"/home/nobbi/NNlab/install/lib/python2.3/site-packages/matplotlib/backends/backend_tkagg.py", 
line 284, in show
 self.canvas.draw()
 File 
"/home/nobbi/NNlab/install/lib/python2.3/site-packages/matplotlib/backends/backend_tkagg.py", 
line 135, in draw
 FigureCanvasAgg.draw(self)
 File 
"/home/nobbi/NNlab/install/lib/python2.3/site-packages/matplotlib/backends/backend_agg.py", 
line 310, in draw
 self.figure.draw(self.renderer)
 File 
"/home/nobbi/NNlab/install/lib/python2.3/site-packages/matplotlib/figure.py", 
line 254, in draw
 for a in self.axes: a.draw(renderer)
 File 
"/home/nobbi/NNlab/install/lib/python2.3/site-packages/matplotlib/axes.py", 
line 935, in draw
 self.transData.freeze() # eval the lazy objects
ValueError: Cannot take log of nonpositive value
-------------------------------------
The appearance of this bug actually depends opn the ratio between the y-values 
given: if the factor exceeds 10, the code breaks:
[0.1,0.2] works
[0.01,0.02] works
[0.1,1.0] works
[0.1,2.0] breaks
[1.0,11.0] breaks
Also: the problem does not appear when using semilogy
I'm using cvs versions of matplotlib and Numeric on python 2.3.4
Greetings,
Norbert
-- 
_________________________________________Norbert Nemec
 Bernhardstr. 2 ... D-93053 Regensburg
 Tel: 0941 - 2009638 ... Mobil: 0179 - 7475199
 eMail: <No...@Ne...>

On Tue, 2004年11月09日 at 12:24, Fernando Perez wrote:
> Just curious: can you comment on what's similar/different between 
> cairo and agg? Is there significant duplication or do they target
> different problems? Would it make sense for these two projects to
> share code? I worry a bit about the explosion of backends, esp.
> because of the maintainability burden it tends to cause in the long
> term.
Agg is written in C++, has been around for a while and is quite
mature/stable. Cairo is younger and has not yet made an "official"
release. It is written in C with language bindings available for Python,
Java, Perl and others. Agg and Cairo both aim to be platform
independent, and they overlap on many of their features. Apparently
OpenOffice, Mozilla and GTK+ are considering using Cairo in their
software, so it could become very popular.
Steve

Hi John,
great work, many thanks!
John Hunter schrieb:
> * cairo backend - Steve Chaplin has contributed cairo and gtkcairo
> backends - http://cairographics.org. Cairo is a vector graphics
> library designed to provide high-quality display and print
> output. Currently supported output targets include the X Window
> System, OpenGL, in-memory image buffers, and image files (PNG and
> PostScript). See http://matplotlib.sf.net/backends.html#Cairo for
> details and install instructions
Just curious: can you comment on what's similar/different between cairo and 
agg? Is there significant duplication or do they target different problems? 
Would it make sense for these two projects to share code? I worry a bit about 
the explosion of backends, esp. because of the maintainability burden it tends 
to cause in the long term.
> * ipython integration - Fernando has continued his excellent work
> integrating matplotlib with ipython and a number of pylab bugs
Thanks :)
> have been ironed out. matplotlib has incorporated ipython's
> numutils in the matplotlib.mlab module - See IPython-0.6.4 - all
> similarities betwen matplotlib and ipython version numbers are
> purely coincidental.
No they're not! They are just one of the few visible signs of our evil master 
plan for world domination :)
Best,
f

This announcement, with links, is available at
http://matplotlib.sf.net/whats_new.html .
What's new in matplotlib-0.64
 * polar plots - polar plots with the polar command. These create a
 axes.PolarAxes instance, which defines the default axes,
 gridlines, etc. Other plot types can be used on polar axes, eg
 scatter. See examples/polar_demo.py, examples/polar_scatter.py
 and screenshot at
 http://matplotlib.sf.net/screenshots.html#polar_demo.
 * cairo backend - Steve Chaplin has contributed cairo and gtkcairo
 backends - http://cairographics.org. Cairo is a vector graphics
 library designed to provide high-quality display and print
 output. Currently supported output targets include the X Window
 System, OpenGL, in-memory image buffers, and image files (PNG and
 PostScript). See http://matplotlib.sf.net/backends.html#Cairo for
 details and install instructions
 * ipython integration - Fernando has continued his excellent work
 integrating matplotlib with ipython and a number of pylab bugs
 have been ironed out. matplotlib has incorporated ipython's
 numutils in the matplotlib.mlab module - See IPython-0.6.4 - all
 similarities betwen matplotlib and ipython version numbers are
 purely coincidental.
 * Jochen Voss has made a number of bugfixes and improvements to the
 postscript backend, including text layout problems. PS backend
 should now be DSC compliant.
 * xticks and yticks now take kwargs so you can do, for example
 xticks( arange(3), ('Tom', 'Dick', 'Harry'), fontsize=14 )
 * imshow now supports PIL images - see examples/image_demo3.py.
 Thanks Andrew Straw.
 * barh for horizontal bar charts. See examples/barh_demo.py
 * added a verbose class to allow different levels of verbosity - see
 http://matplotlib.sf.net/.matplotlibrc for details. Eg, you can
 now do 
 > python myscript.py --verbose-helpful
 to get a lot of information about what matplotlib is doing behind
 the scenes, what resource files are being used etc. The default
 verbose settings and file handles for reporting are customizable
 in rc.
 * numerous small bugfixes and improvements: fixes for gcc-3.4, allow
 -dsomeflag where someflag is not a backend, errorbar now accepts
 barsabove to determine the plot order of the errorbar markers and
 lines, fixed a corrcoef bug where args is a matrix, Andrew Dalke
 contributed code to extend the strftime range to the new matplotlib
 date range, fixes to support for python2.2
Downloads at
http://sourceforge.net/project/showfiles.php?group_id=80706&package_id=82474&release_id=281218
Enjoy!
JDH 

>>>>> "Norbert" == Norbert Nemec <Nor...@ph...> writes:
 Norbert> By itself, this patch is completely pointless (exposing
 Norbert> isaxes is nonsense - setting this argument to False
 Norbert> indicates that the parent is *not* an axes. when
 Norbert> Legend.__init__ is called by axes.legend, the parent, of
 Norbert> course, is - by definition - an axes...)
Yes, this is meant to be used by figlegend....
JDH

Strike me dumb - please ignore that patch about kwargs in legend.
I just found that patch from last week unsubmitted in my directory. It seemed 
reasonable, so I submitted it. Now i realize, that it was just the 
preparation for a larger change that I never completed.
By itself, this patch is completely pointless (exposing isaxes is nonsense - 
setting this argument to False indicates that the parent is *not* an axes. 
when Legend.__init__ is called by axes.legend, the parent, of course, is - by 
definition - an axes...)
On Monday 08 November 2004 20:11, John Hunter wrote:
> >>>>> "Norbert" == Norbert Nemec <Nor...@ph...>
> >>>>> writes:
>
> Norbert> Hi there, see attached two tiny patches:
>
> Hi, a quick question on the legend patch. The only kwarg that Legend
> accepts is isaxes - is this the one you are trying to expose?
>
> The kwargs to errorbar seem reasonable...
>
> JDH
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
-----------------------------------------------------> Norbert Nemec
 Molecular Computing Group ... Institute for Theoretical Physics
 University of Regensburg ... D-93040 Regensburg
 phone: +49-(0)941-943-2026 ... mobile: +49-(0)179-7475199
eMail: <Nor...@ph...> ... room: Phy 4.1.30

>>>>> "Norbert" == Norbert Nemec <Nor...@ph...> writes:
 Norbert> Hi there, see attached two tiny patches:
Hi, a quick question on the legend patch. The only kwarg that Legend
accepts is isaxes - is this the one you are trying to expose?
The kwargs to errorbar seem reasonable...
JDH

Hi there,
see attached two tiny patches:
* adding **kwargs to axes.errorbar
* passing **kwargs through axes.legend to Legend()
Greetings,
Nobbi
-- 
-----------------------------------------------------> Norbert Nemec
 Molecular Computing Group ... Institute for Theoretical Physics
 University of Regensburg ... D-93040 Regensburg
 phone: +49-(0)941-943-2026 ... mobile: +49-(0)179-7475199
eMail: <Nor...@ph...> ... room: Phy 4.1.30

John Hunter schrieb:
> There have been enough new features and bug fixes in CVS that I think
> it's time to roll out another release, target date Monday. Man, we're
> getting stodgy around here, no releases since Sept 27th. Oh well,
> I'll blame it on the baby :-)
Well, I was also planning on releasing ipython 0.6.4 (nice numbering 
coincidence :) on Monday, and it includes a number of enhancements for 
matplotlib use. Mainly, better handling of Ctrl-C and an improved %run which 
doesn't open spurious windows, plus a few other small fixes.
Perhaps you might want to mention that the matplotlib+ipython 0.64+0.6.4 combo 
is now a pretty usable toolset (and that matplotlib carries within all of 
ipython's numutils, which some existing ipython users were accustomed to).
I'll certainly highlight the improved matplotlib support as one of the 
interesting improvements of this new ipython version.
Cheers,
f

There have been enough new features and bug fixes in CVS that I think
it's time to roll out another release, target date Monday. Man, we're
getting stodgy around here, no releases since Sept 27th. Oh well,
I'll blame it on the baby :-)
So if you have any changes you want to commit before then, or any
reasons why I should hold off, fire away.
JDH

>>>>> "Thane" == Thane <th...@ma...> writes:
 Thane> Source is attached. --tkp
OK, many thanks. zip file is available at 
http://matplotlib.sf.net/backend_dotnet.zip
JDH

Thanks John, I'll be forwarding the source separately. Now to your
questions:
1. [JDH] It's still the case, isn't it, that matplotlib itself will not
work on a general .Net machine? 
[TKP] No. Matplotlib DOES work on a general .Net machine. I've run
successful -- but not exhaustive -- tests of the "DotNet" backend on
("normal") CPython 2.3, and PythonNet.
2. [JDH] In particular, it won't work on IronPython because it uses numerix
extension code as well as it's own, right?
[TKP] Yes and no. Matplotlib doesn't work on IronPython (yet) as the
supporting libraries are not yet there. (With some effort, this might be
feasible with PyPy.) However, the "DotNet" backend (DLL) works just fine.
Output from the session below creates a graphic window and draws a blue line
on it. This isn't too useful except to note that once the libraries are in
place, matplotlib will indeed work on IronPython.
C:\Python\IronPython-0.6\bin>IronPythonConsole
>>> import sys
>>> sys.LoadAssemblyFromFile("./_backend_dotnet.pyd")
>>> foo = backend_dotnet.GraphicsForm(640, 480)
IronPython.Objects.PythonNameError: name 'backend_dotnet' is not defined
 at IronPython.Objects.Frame.GetGlobal(String name)
 at input_2.Run(Frame frame)
 at IronPythonConsole.IronPython.DoInteractive()
>>> import backend_dotnet
>>> foo = backend_dotnet.GraphicsForm(640, 480)
>>> from System.Drawing import *
>>> bar = Color.Blue
>>> bar
Color [Blue]
>>> pen = Pen(bar)
>>> pen
<System.Drawing.Pen object at 0x00000021>
>>> foo.draw_line(pen, 0, 0, 100, 100)
>>> foo.Repaint()
>>>
3. [JDH] How does PythonNet handle this problem, and is it fair to say that
matplotlib with your backend currently work only on PythonNet?
[TKP] That was the case, but isn't any longer. A bit of history... I
originally wrote the backend in PythonNet, and consequently it would only
work with the PythonNet distribution. However, (foolishly) encouraged by my
success, I wrote a DLL so that this backend could work with any .Net
machine. I say foolishly, because the DLL took about 5 times as long to
write as the Python version! It now works also with the "regular" Python
(aka CPython) distribution.
> -----Original Message-----
> From: John Hunter [mailto:jdh...@ac...]
> Sent: Friday, November 05, 2004 9:30 AM
> To: th...@ma...
> Cc: 'Andrew Straw'; mat...@li...
> Subject: Re: [matplotlib-devel] .NET backend
> 
> >>>>> "Thane" == Thane <th...@ma...> writes:
> 
> Thane> My source code posting seems to have bounced. I got the
> Thane> following message: host mail.sourceforge.net
> Thane> [66.35.250.206]: 550-"For the time being, we are blocking
> Thane> all mail with the .zip extension....
> 
> If you email it to me, I'll post it on the matplotlib web site, and
> follow-up here with a link to it. Best if you include all the code
> (*.py and *.c) in one zip along with the pyd and any examples since
> the sf archives won't include your previous plain text)attachments,
> and it will be easiest for people searching the archives to get
> everything in one bundle.
> 
> Can you clarify something for me? In the backend comments you wrote
> 
> 0.2.0 11/01/04 Created a DLL for the backend. Should work with any
> .NET machine.
> 
> It's still the case, isn't it, that matplotlib itself will not work on
> a general .Net machine? In particular, it won't work on IronPython
> because it uses numerix extension code as well as it's own, right?
> How does PythonNet handle this problem, and is it fair to say that
> matplotlib with your backend currently work only on PythonNet?
> 
> Thanks!
> JDH
> 
> 
> 

>>>>> "Thane" == Thane <th...@ma...> writes:
 Thane> My source code posting seems to have bounced. I got the
 Thane> following message: host mail.sourceforge.net
 Thane> [66.35.250.206]: 550-"For the time being, we are blocking
 Thane> all mail with the .zip extension....
If you email it to me, I'll post it on the matplotlib web site, and
follow-up here with a link to it. Best if you include all the code
(*.py and *.c) in one zip along with the pyd and any examples since
the sf archives won't include your previous plain text)attachments,
and it will be easiest for people searching the archives to get
everything in one bundle.
Can you clarify something for me? In the backend comments you wrote
 0.2.0 11/01/04 Created a DLL for the backend. Should work with any .NET machine.
It's still the case, isn't it, that matplotlib itself will not work on
a general .Net machine? In particular, it won't work on IronPython
because it uses numerix extension code as well as it's own, right?
How does PythonNet handle this problem, and is it fair to say that
matplotlib with your backend currently work only on PythonNet?
Thanks!
JDH

My source code posting seems to have bounced. I got the following message:
host mail.sourceforge.net [66.35.250.206]: 550-"For the time being, we are
blocking all mail with the .zip extension....
What's the best way to distribute a project?
> -----Original Message-----
> From: mat...@li... [mailto:matplotlib-
> dev...@li...] On Behalf Of Andrew Straw
> Sent: Thursday, November 04, 2004 9:57 PM
> To: th...@ma...; mat...@li...
> Subject: Re: [matplotlib-devel] .NET backend
> 
> Thane wrote:
> 
> > Attached are the files needed for running a .NET backend. This code
> > still needs a lot of work, but this should demonstrate the feasibility
> > of a .NET backend, for those interested.
> >
> Dear Thane,
> 
> This looks very interesting, but what about the source to
> _backend_dotnet.pyd? Did you forget to include that?
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 

Hello,
On Tue, Nov 02, 2004 at 12:41:03PM -0600, John Hunter wrote:
> >>>>> "Jochen" =3D=3D Jochen Voss <vo...@se...> writes:
> Jochen> Is there a reason for storing the PostScript data in a
> Jochen> string first? Otherwise I could just pass the real file
> Jochen> handle to RendererPS and it would write all the stuff
> Jochen> directly into the output file.
>=20
> The reason I did it (I think) was for efficiency, (wrongly) thinking
> it would be faster to write to StringIO than to a file object. Of
> course, file objects buffer their output, so this is not a real
> consideration. I think its fine to make the change you suggested -
I found a good reason for storing the PS in a string first:
we have to process all of the figure before we write the PostScript
prologue. Otherwise there is no good way to know which fonts
to include in the PostScript file :-(
I reverted my change for now, we are back to storing the PostScript
data temporarily in a string.
All the best,
Jochen
--=20
http://seehuhn.de/

Thane wrote:
> Attached are the files needed for running a .NET backend. This code 
> still needs a lot of work, but this should demonstrate the feasibility 
> of a .NET backend, for those interested.
>
Dear Thane,
This looks very interesting, but what about the source to 
_backend_dotnet.pyd? Did you forget to include that?