On 2010-07-19 15:55-0400 si...@mungewell.org wrote: > >> Thank you Alan, I think that I have figured out how to do this w/ the >> appropriate version checks. It seems to work on my system, but my >> version of swig is not of recent enough vintage to support plsmem() so I >> did not test the with plsmem() case. > > For the record; I grabbed a copy from SVN and built it on my XP machine. > Seems to be good, my little test script for plotting via plsmem worked > fine.
Hi Simon: I have changed the subject line corresponding to the new direction I would like to take this discussion. As of revision 11103, I did some rearranging of python plsmem support. I tested that rearrangement on Linux (Debian testing with the python-imaging package installed), and I found that your test script continued to work. Important question: Would you be willing to donate your script to PLplot under the LGPL? If so, I would make it part of our source tree as a special python test for now, but later on (assuming substantial improvements to mem-type functionality, see below) we would probably want to create a standard example (with all that implies about propagating plsmem to all our language interfaces) using some ideas from the test script. I have to say this is the first time I have seen the mem device in action, and there are several glaring issues; e.g., no support for transparency, no support for fills (and the software fallback for that really sucks as can be seen from the test script results), and no support for unicode fonts. Adding transparency support should be straightforward, and it is possible we could do something about fills, but I have substantial doubts about support for unicode fonts. One possibility there is to use the deprecated plfreetype approach, but that has so many limitations I would definitely prefer not to expand its use, and IMHO the best way to support unicode in PLplot is to use the excellent unicode facilities of external libraries like cairo and qt. One important question for further discussion is whether our current qt and cairo devices could be modified along with plsmem to provide similar functionality to the mem device with automatic high-quality support of transparency, fills, and unicode fonts? If so, I would strongly support making a change to plsmem to propagate the user-prepared memory area to the qt, cairo, and mem devices as needed, and not bothering at all with further mem device improvements. Of course, even if mem-type functionality could be arranged via our cairo and qt devices with suitable changes to plsmem, we would probably want to continue to keep the more primitive mem device driver for those cases where the user doesn't want to bother with dealing with the cairo and Qt dependencies. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
