You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(33) |
Dec
(20) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(7) |
Feb
(44) |
Mar
(51) |
Apr
(43) |
May
(43) |
Jun
(36) |
Jul
(61) |
Aug
(44) |
Sep
(25) |
Oct
(82) |
Nov
(97) |
Dec
(47) |
2005 |
Jan
(77) |
Feb
(143) |
Mar
(42) |
Apr
(31) |
May
(93) |
Jun
(93) |
Jul
(35) |
Aug
(78) |
Sep
(56) |
Oct
(44) |
Nov
(72) |
Dec
(75) |
2006 |
Jan
(116) |
Feb
(99) |
Mar
(181) |
Apr
(171) |
May
(112) |
Jun
(86) |
Jul
(91) |
Aug
(111) |
Sep
(77) |
Oct
(72) |
Nov
(57) |
Dec
(51) |
2007 |
Jan
(64) |
Feb
(116) |
Mar
(70) |
Apr
(74) |
May
(53) |
Jun
(40) |
Jul
(519) |
Aug
(151) |
Sep
(132) |
Oct
(74) |
Nov
(282) |
Dec
(190) |
2008 |
Jan
(141) |
Feb
(67) |
Mar
(69) |
Apr
(96) |
May
(227) |
Jun
(404) |
Jul
(399) |
Aug
(96) |
Sep
(120) |
Oct
(205) |
Nov
(126) |
Dec
(261) |
2009 |
Jan
(136) |
Feb
(136) |
Mar
(119) |
Apr
(124) |
May
(155) |
Jun
(98) |
Jul
(136) |
Aug
(292) |
Sep
(174) |
Oct
(126) |
Nov
(126) |
Dec
(79) |
2010 |
Jan
(109) |
Feb
(83) |
Mar
(139) |
Apr
(91) |
May
(79) |
Jun
(164) |
Jul
(184) |
Aug
(146) |
Sep
(163) |
Oct
(128) |
Nov
(70) |
Dec
(73) |
2011 |
Jan
(235) |
Feb
(165) |
Mar
(147) |
Apr
(86) |
May
(74) |
Jun
(118) |
Jul
(65) |
Aug
(75) |
Sep
(162) |
Oct
(94) |
Nov
(48) |
Dec
(44) |
2012 |
Jan
(49) |
Feb
(40) |
Mar
(88) |
Apr
(35) |
May
(52) |
Jun
(69) |
Jul
(90) |
Aug
(123) |
Sep
(112) |
Oct
(120) |
Nov
(105) |
Dec
(116) |
2013 |
Jan
(76) |
Feb
(26) |
Mar
(78) |
Apr
(43) |
May
(61) |
Jun
(53) |
Jul
(147) |
Aug
(85) |
Sep
(83) |
Oct
(122) |
Nov
(18) |
Dec
(27) |
2014 |
Jan
(58) |
Feb
(25) |
Mar
(49) |
Apr
(17) |
May
(29) |
Jun
(39) |
Jul
(53) |
Aug
(52) |
Sep
(35) |
Oct
(47) |
Nov
(110) |
Dec
(27) |
2015 |
Jan
(50) |
Feb
(93) |
Mar
(96) |
Apr
(30) |
May
(55) |
Jun
(83) |
Jul
(44) |
Aug
(8) |
Sep
(5) |
Oct
|
Nov
(1) |
Dec
(1) |
2016 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
(3) |
Sep
(1) |
Oct
(3) |
Nov
|
Dec
|
2017 |
Jan
|
Feb
(5) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
(7) |
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
S | M | T | W | T | F | S |
---|---|---|---|---|---|---|
|
|
1
(1) |
2
|
3
|
4
|
5
|
6
|
7
|
8
|
9
(1) |
10
(2) |
11
|
12
(4) |
13
(1) |
14
|
15
|
16
(2) |
17
(5) |
18
(6) |
19
(4) |
20
(1) |
21
(1) |
22
(1) |
23
(2) |
24
(1) |
25
(2) |
26
(1) |
27
(1) |
28
(3) |
29
|
30
(1) |
31
(2) |
|
|
>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes: Steve> This looks incomplete, what's the Exception type? I tried Steve> on my system and it ran OK. Oops, the complete traceback is below. Maybe my cairo is out of whack. Are you using CVS? I tried upgrading my cairo from CVS and got the build error indicated below. Any ideas? I can post to the cairo mailing list.... Steve> The Cairo colour problem has been noticed and discussed on Steve> the Cairo mailing list. The cairo.FORMAT_ARGB32 stores each Steve> 32-bit pixel in native-endian format so on big-endian Steve> systems it looks like ARGB and on little-endian systems Steve> (like my PC) it looks like BGRA, I'm not sure if Cairo will Steve> be updated to 'fix' this or not. A possible workaround is Steve> to check sys.byteorder, and if its 'little' then get the Steve> image module / Agg to generate BGRA (I'm not sure if it can Steve> do this) and even then I think it must be BGRA with Steve> litte-endian ordering. Or a 'bit-flipping' routine could be Steve> written to do the same, but seems like a very inefficient Steve> thing to need to do. Steve> I guess a good test to start with would be to see if the Steve> colours are actually correct on a big-endian system. I Steve> understand the PowerPC is bi- endian - the OS imposes the Steve> endianness, and that with OS X it is big- endian. So Steve> perhaps someone with a Mac could test if the colours do Steve> currently work. Steve> Or we could simply use RGB32 where the byte order is Steve> correct, and do without the alpha. I would vote for dealing with the endianess and different pixel formats in a platform specific way. The current pixel converters in agg tostring_rgb tostring_argb tostring_bgra buffer_rgba and I can provide whatever you need, or you can follow the existing code and provide them yourself. agg prettty much has a converter for every format I've heard of. JDH ### Cairo backend traceback peds-pc311:~/python/projects/matplotlib/examples> python simple_plot.py -dCairo Traceback (most recent call last): File "simple_plot.py", line 15, in ? savefig('simple_plot') File "/usr/local/lib/python2.3/site-packages/matplotlib/pylab.py", line 712, in savefig return fig.savefig(*args, **kwargs) File "/usr/local/lib/python2.3/site-packages/matplotlib/figure.py", line 457, in savefig self.canvas.print_figure(*args, **kwargs) File "/usr/local/lib/python2.3/site-packages/matplotlib/backends/backend_cairo.py", line 647, in print_figure orientation) File "/usr/local/lib/python2.3/site-packages/matplotlib/backends/backend_cairo.py", line 561, in print_figure_fn if ext == 'png': _save_png (figure, fileObject) File "/usr/local/lib/python2.3/site-packages/matplotlib/backends/backend_cairo.py", line 583, in _save_png ctx.set_target_png (fileObject, cairo.FORMAT_ARGB32, width, height) TypeError: Context.set_target_png() argument 1 must be string, not file peds-pc311:~/python/projects/matplotlib/examples> ### Cairo CVS build error make[2]: Entering directory `/home/jdhunter/python/cvs/cairo/src' if /bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -I. -I/usr/X11R6/include -I/usr/local/include/libpng12 -I/usr/local/include -I/usr/include/freetype2 -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -g -O2 -MT cairo.lo -MD -MP -MF ".deps/cairo.Tpo" -c -o cairo.lo cairo.c; \ then mv -f ".deps/cairo.Tpo" ".deps/cairo.Plo"; else rm -f ".deps/cairo.Tpo"; exit 1; fi mkdir .libs gcc -DHAVE_CONFIG_H -I. -I. -I.. -I. -I/usr/X11R6/include -I/usr/local/include/libpng12 -I/usr/local/include -I/usr/include/freetype2 -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -g -O2 -MT cairo.lo -MD -MP -MF .deps/cairo.Tpo -c cairo.c -fPIC -DPIC -o .libs/cairo.lo In file included from cairo.h:48, from cairoint.h:60, from cairo.c:37: cairo-features.h:42:9: macro names must be identifiers cairo-features.h:48:9: macro names must be identifiers cairo-features.h:52:9: macro names must be identifiers cairo-features.h:56:9: macro names must be identifiers cairo-features.h:58:9: macro names must be identifiers cairo-features.h:60:9: macro names must be identifiers make[2]: *** [cairo.lo] Error 1 peds-pc311:~/python/cvs/cairo> gcc --version gcc (GCC) 3.3.3 Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. peds-pc311:~/python/cvs/cairo> uname -a Linux peds-pc311.bsd.uchicago.edu 2.4.21-15.0.2.ELsmp #1 SMP Wed Jun 16 22:52:07 EDT 2004 i686 i686 i386 GNU/Linux
>>>>> "Bryan" == Bryan Cole <bry...@te...> writes: Bryan> I've using Python-2.3.4 BTW. Maybe CXX didn't update to the Bryan> new python object model. I know nothing about CXX Bryan> internals, however. I just upgraded mpl to the most recent CXX and I still get the segfault. What would be most useful is if you created a minimal CXX extension independent of mpl and see if you can replicate the bug. If so, could you file a bug report on the CXX sf project page? JDH
On 2005年3月17日 13:10:24 +0000, Bryan Cole wrote: > >>>> from matplotlib._transforms import * >>>> from types import * >>>> V=Value(0) >>>> issubclass(type(V), TypeType) > Segmentation fault > > The 'issubclass' function is called by the default pickler. The seg-fault > seems to occur for any of the matplotlib._transform CXX-types. I see that >>> type(V).__bases__ '*' whereas every other object I have tried gives something like: >>> type(None).__bases__ (<type 'object'>,) I've tested this with a trivial external C-type (the 'noddy.c' example in the python documentation chapter on Extending and Embedding) and even the most basic python object has it's base class defined as <object> now. I've using Python-2.3.4 BTW. Maybe CXX didn't update to the new python object model. I know nothing about CXX internals, however.
I've been looking at how to pickle figures: it looks like is should be a simple modification to make all _transform objects (Value, Point, Bbox, Affine etc.) picklable. This should be possible without modifying any cpp code. I hit a problem though. The following code generates a seg-fault: >>> from matplotlib._transforms import * >>> from types import * >>> V=Value(0) >>> issubclass(type(V), TypeType) Segmentation fault The 'issubclass' function is called by the default pickler. The seg-fault seems to occur for any of the matplotlib._transform CXX-types. I can't reproduce the bug with any other python C-entensions (SWIG-generated wrappers work differently, so the problem doesn't occur). Both Numeric array and VTK objects work fine with 'issubclass'. Could this be a problem with CXX? It may be a python bug of course, but it will be quicker to fix matplotlib than wait for the next python release. Ideas? Bryan
On Wed, 2005年03月16日 at 20:27 -0800, matplotlib-devel- re...@li... wrote: > > I just noticed all of the image and colorbar colors are wrong in > > GTKCairo (on linux). When I tried to test on the pure Cairo backend, > > I get > > > > peds-pc311:~/python/projects/matplotlib/examples> python pcolor_demo.py -dCairo Traceback (most recent call last): > > File "pcolor_demo.py", line 25, in ? > > savefig('pcolor_demo') > > File "/usr/local/lib/python2.3/site-packages/matplotlib/pylab.py", line 712, in savefig > > return fig.savefig(*args, **kwargs) > > File "/usr/local/lib/python2.3/site-packages/matplotlib/figure.py", line 457, in savefig > > self.canvas.print_figure(*args, **kwargs) > > File "/usr/local/lib/python2.3/site-packages/matplotlib/backends/backend_cairo.py", line 647, in print_figure > > orientation) > > File "/usr/local/lib/python2.3/site-packages/matplotlib/backends/backend_cairo.py", line 561, in print_figure_fn > > if ext == 'png': _save_png (figure, fileObject) > > File "/usr/local/lib/python2.3/site-packages/matplotlib/backends/backend_cairo.py", line 583, in _save_png > > ctx.set_target_png (fileObject, cairo.FORMAT_ARGB32, width, height) This looks incomplete, what's the Exception type? I tried on my system and it ran OK. The Cairo colour problem has been noticed and discussed on the Cairo mailing list. The cairo.FORMAT_ARGB32 stores each 32-bit pixel in native-endian format so on big-endian systems it looks like ARGB and on little-endian systems (like my PC) it looks like BGRA, I'm not sure if Cairo will be updated to 'fix' this or not. A possible workaround is to check sys.byteorder, and if its 'little' then get the image module / Agg to generate BGRA (I'm not sure if it can do this) and even then I think it must be BGRA with litte-endian ordering. Or a 'bit-flipping' routine could be written to do the same, but seems like a very inefficient thing to need to do. I guess a good test to start with would be to see if the colours are actually correct on a big-endian system. I understand the PowerPC is bi- endian - the OS imposes the endianness, and that with OS X it is big- endian. So perhaps someone with a Mac could test if the colours do currently work. Or we could simply use RGB32 where the byte order is correct, and do without the alpha. Steve
I just noticed all of the image and colorbar colors are wrong in GTKCairo (on linux). When I tried to test on the pure Cairo backend, I get peds-pc311:~/python/projects/matplotlib/examples> python pcolor_demo.py -dCairo Traceback (most recent call last): File "pcolor_demo.py", line 25, in ? savefig('pcolor_demo') File "/usr/local/lib/python2.3/site-packages/matplotlib/pylab.py", line 712, in savefig return fig.savefig(*args, **kwargs) File "/usr/local/lib/python2.3/site-packages/matplotlib/figure.py", line 457, in savefig self.canvas.print_figure(*args, **kwargs) File "/usr/local/lib/python2.3/site-packages/matplotlib/backends/backend_cairo.py", line 647, in print_figure orientation) File "/usr/local/lib/python2.3/site-packages/matplotlib/backends/backend_cairo.py", line 561, in print_figure_fn if ext == 'png': _save_png (figure, fileObject) File "/usr/local/lib/python2.3/site-packages/matplotlib/backends/backend_cairo.py", line 583, in _save_png ctx.set_target_png (fileObject, cairo.FORMAT_ARGB32, width, height) Here is my configuration information matplotlib data path /usr/local/share/matplotlib loaded rc file /home/jdhunter/.matplotlibrc matplotlib version 0.73 verbose.level helpful interactive is False platform is linux2 numerix Numeric 23.6 font search path ['/usr/local/share/matplotlib'] loaded ttfcache file /home/jdhunter/.ttffont.cache backend GTKCairo version PyGTK(2.2.0),PyCairo ?? JDH
>>>>> "Jochen" == Jochen Voss <vo...@se...> writes: Jochen> Hi John, in case it is not obvious from my inactivity: it Jochen> turns out that I have not enough time and energy to do Jochen> much for matplotlib's PostScript backend. Therefore I Jochen> would prefer not to be considered the backend maintainer Jochen> any more :-( Jochen> Of course I will continue to follow the matplotlib Jochen> development and will try to provide patches from time to Jochen> time. Hi Jochen, Sorry to see you go :-( Thanks for all the hard work you've put into making the PS backend compliant. We'll keep hammering away at it. Poke in every once in a while to make sure we aren't mucking things up. Again, thanks a lot, and thanks for bowing out officially so I know to take over rather than just grumbling and pestering! JDH
Hi John, in case it is not obvious from my inactivity: it turns out that I have not enough time and energy to do much for matplotlib's PostScript backend. Therefore I would prefer not to be considered the backend maintainer any more :-( Of course I will continue to follow the matplotlib development and will try to provide patches from time to time. All the best, Jochen --=20 http://seehuhn.de/
I've been tooling around with matplotlib, as graciously packaged by Chris Barker, and hosted on Bob Ippolito's pythonmac.org/packages site. Everything seems to be working smoothly, but I've run into a couple of warnings I can't decrypt. 1) Executing the following code, #! /usr/bin/pythonw import pylab pylab.plot([1, 2, 3], [4, 5, 6]) pylab.show() displays a chart as expected (the toolbar icons are a little mucked, but that's minor). However, dismissing the chart window brings up this warning: 2005年03月12日 17:26:52.075 Python[569] *** _NSAutoreleaseNoPool(): Object 0x66402d0 of class NSCFString autoreleased with no pool in place - just leaking *** malloc[569]: Deallocation of a pointer not malloced: 0x66c73d0; This could be a double free(), or free() called with the middle of an allocated block; Try setting environment variable MallocHelp to see tools to help debug Is this a bug with matplotlib, with my installation of matplotlib, or with my script? Can I ignore it, and if not, what can I do to address it? 2) a smaller issue: I tried to change matplotlib's array class by opening /system/library/frameworks/python.framework/version/2.3/share/ .matplotlibrc and changing "numerix : numeric" to "numerix: numarray" but I got the following error: The import of the numarray version of the _contour module, _na_contour, failed. This is is either because numarray was unavailable when matplotlib was compiled, because a dependency of _na_contour could not be satisfied, or because the build flag for this module was turned off in setup.py. If it appears that _na_contour was not built, make sure you have a working copy of numarray and then re-install matplotlib. Otherwise, the following traceback gives more details: File "/platlib/matplotlib/_contour.py", line 5, in ? ImportError: No module named _na_contour I know I had numarray installed before unpackaging matplotlib. Chris' notes say that he had numeric installed when he packaged matplotlib, but makes no mention of numarray. Perhaps the matplotlib.mpkg needs to be rebuilt on a machine that has numarray installed? It isn't a big deal, as the two types are -mostly- interchangeable, but it would be nice to have the choice. -Brendan ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca
I should have also mentioned that the new signature is document in backend_bases in the _draw_markers method def _draw_markers(self, gc, path, rgbFace, x, y, trans): """ This method is currently underscore hidden because the draw_markers method is being used as a sentinel for newstyle backend drawing path - a matplotlib.agg.path_storage instance Draw the marker specified in path with graphics context gc at each of the locations in arrays x and y. trans is a matplotlib.transforms.Transformation instance used to transform x and y to display coords. It consists of an optional nonlinear component and an affine. You can access these two components as if transform.need_nonlinear(): x,y = transform.nonlinear_only_numerix(x, y) # the a,b,c,d,tx,ty affine which transforms x and y vec6 = transform.as_vec6_val() ...backend dependent affine... """ pass
>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes: Steve> John, I noticed ./examples/dash_control.py -dAgg from the Steve> latest cvs, is not working.. Steve> I think the problem may be in lines.set_dashes() If I Steve> change self._dashSeq = seq[1] to self._dashSeq = seq it Steve> seems to work. OK, great. Thanks. Steve> Also, what happened to matplotlib.path - it was being used Steve> by Cairo for draw_markers() Hmm. I thought I posted this already. I rewrote the path handling to use agg paths, which are a more complete implementation (eg supporting move_rel, line_rel and friends. I found my post as an emacs backup file, so will just paste it in here -- it provides a code snippent to convert an agg path to a list path we were using previously. To: Steve Chaplin <ste...@ya...> Cc: mat...@li... Subject: Re: [matplotlib-devel] refactoring the backend drawing methods From: John Hunter <jdh...@ac...> Gcc: nnml:outgoing-mail References: <m3u...@pe...> <1110376248.3691.24.camel@f1> X-Draft-From: ("nnml:mail-list.matplotlib-devel" 1256) --text follows this line-- >>>>> "Steve" == Steve Chaplin <ste...@ya...> writes: Steve> I've implemented draw_markers() for Cairo, and tested it Steve> using line- styles.py - it seems to be working OK. I did Steve> find that it caused draw_lines() to stop working and had to Steve> modify it to get it working again. Yes, sorry for failing to update you on this. Steve> I don't think 'fill' and 'fill_rgb' information should be Steve> encoded into the 'path', and would to prefer to have Steve> rendering separated into two independent steps: 1) call a Steve> function to parse 'path' and generate a path - the path is Steve> a general path (with no fill or colour info) that you can Steve> later use any way you wish. 2) set colour etc as desired Steve> and fill/stroke the path. Steve> The draw_markers() code I've written calls generate_path() Steve> before drawing each marker and it reads the fill value and Steve> the fill_rgb each time which it unnecessary since the Steve> values are the same for all the markers. Passing the Steve> fill_rgb as an extra argument to draw_markers() would be Steve> one way to 'fix' this. Done. I also wrapped agg's path storage and am using this rather than the list storage. You can get the old representation from the new rather easily, as illustrated here import matplotlib.agg as agg path = agg.path_storage() path.move_to(10,10) path.line_to(20,30) path.curve3_rel(100,200) path.end_poly() print [ path.vertex() for i in range(path.total_vertices())] Steve> Cairo (and probably Agg, PS, SVG) supports rel_move_to() Steve> and rel_line_to () - so you can define a path using Steve> relative rather than absolute coords, which can sometimes Steve> be useful. For example, instead of translate(x,y) Steve> generate_absolute_path(path) stroke() you can use Steve> move_to(x,y) generate_relative_path(path) stroke() and the Steve> path is stroked relative to x,y with no need to translate Steve> the coordinates. agg has move_rel and line_rel, etc, but I don't think it works the same way, because it computes the actual move_to, line_to, etc under the hood and stores these values, so I'm not sure it's possible to actually store a relative moveto in agg. Could be missing something, though. As far as I can see, everything gtes converted to one of the 6 primitive commands (STOP, MOVETO, LINETO, CURVE3, CURVE4, ENDPOLY) under the hood. JDH
John, I noticed ./examples/dash_control.py -dAgg from the latest cvs, is not working.. I think the problem may be in lines.set_dashes() If I change self._dashSeq = seq[1] to self._dashSeq = seq it seems to work. Also, what happened to matplotlib.path - it was being used by Cairo for draw_markers() Steve
>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes: Steve> I thought I would implement draw_line_collection() for Steve> Cairo and looked for an example script I could use for Steve> testing. Yet after adding a 'print "line collection"' Steve> statement to backend_bases.draw_line_collection() and Steve> running backend_driver.py I did not see any examples using Steve> line collections. Does this mean that line collections are Steve> not useful, or just that there is no example script (called Steve> by backend_driver.py) which uses line collections? contours use line collections, as does the finance module. If you run the contour_demo*.py examples, you should see them called. It may be that none of the backend_driver functions use these yet, but the driver should be updated to include all the new contouring functionality (very nice contour labeling thanks to Nadia and filled contours thanks to Nadia and Eric Firing). Steve> Also, is it worthwhile implementing these collections Steve> routines or are they effectively deprecated and about to be Steve> superseded by new path based drawing routines? The pure python backend implementation is a good bit faster than the bad old way of using lots of independent objects and gc calls. It may be fast enough for a python module like the pycairo backend. They are not deprecated, but since no backend other than agg has implemented them yet, I am amenable to losing them in favor of a streamlined, reduced API based around paths. Profile the contour routines on cairo and compare their performance to agg. If they are in the same ballpark, you may want to let this lie for a while. Ditto for scatter which uses poly collections. JDH
I thought I would implement draw_line_collection() for Cairo and looked for an example script I could use for testing. Yet after adding a 'print "line collection"' statement to backend_bases.draw_line_collection() and running backend_driver.py I did not see any examples using line collections. Does this mean that line collections are not useful, or just that there is no example script (called by backend_driver.py) which uses line collections? Also, is it worthwhile implementing these collections routines or are they effectively deprecated and about to be superseded by new path based drawing routines? Steve
I've implemented draw_markers() for Cairo, and tested it using line- styles.py - it seems to be working OK. I did find that it caused draw_lines() to stop working and had to modify it to get it working again. I don't think 'fill' and 'fill_rgb' information should be encoded into the 'path', and would to prefer to have rendering separated into two independent steps: 1) call a function to parse 'path' and generate a path - the path is a general path (with no fill or colour info) that you can later use any way you wish. 2) set colour etc as desired and fill/stroke the path. The draw_markers() code I've written calls generate_path() before drawing each marker and it reads the fill value and the fill_rgb each time which it unnecessary since the values are the same for all the markers. Passing the fill_rgb as an extra argument to draw_markers() would be one way to 'fix' this. Cairo (and probably Agg, PS, SVG) supports rel_move_to() and rel_line_to () - so you can define a path using relative rather than absolute coords, which can sometimes be useful. For example, instead of translate(x,y) generate_absolute_path(path) stroke() you can use move_to(x,y) generate_relative_path(path) stroke() and the path is stroked relative to x,y with no need to translate the coordinates. Steve
Hi there, has anybody thought about a Grace backend, yet? I've recently been using Grace for some plotting and was really surprised how the version 5.99 has evolved over the past months. Not quite finished, but a huge step forward compared to the former versions of Grace. For other tasks, I also have gotten to like the possibility of scripting plotting tasks in matplotlib. I have a number of scripts that I really don't want to dump completely. Now my idea was: how about a matplotlib backend producing a .xgr file? Unlike the old .agr format, .xgr is now a XML based format describing a plot in Grace (without any scripting possibilities) The structure of an .xgr file is not too different from the model that matplotlib uses, so the basic functionality should be rather simple to implement. The main difficulty would probably be, that .xgr describes plots at a much higher level than the usual backends. The usual backend interface will therefore not work. I have no clear idea yet how the .xgr export could be incorporated in the easiest way. B.t.w: I myself will most likely not be able to spend any serious time on this in the near future, so if anybody wants to look into it, I will not stand in the way. Ciao, Norbert