Hi Paul, Have we had this conversation before??? Anyway, yes, I've looked at and played with PLPLOT a few times over the past couple years. It's similar to PGPLOT as far as call structure and some important advantages over PGPLOT, especially the LGPL license. It could probably replace PGPLOT in Ifeffit. PLPLOT is under active development, which is a good thing, as their make system is still quite buggy. They try to build many drivers for many languages (octave,tcl,python,java,....) and drivers. I've had problems building it from their kit on various flavors of RedHat. I tried it in January, and had to modify their Xwindows driver to work for me, which is pretty scary. It seems to work better now, but my guess is that either some build wrapper like PGPLOT_install would be needed, and might even be more extensive than the PGPLOT one. Cursor support is available in PLPLOT, but not (I believe) available from Fortran. That would have to be fixed. I tried PLPLOT on Windows once: it worked and looked better than GrWin/PGPLOT but wasn't painless. The person maintaining this is at ESRF, which is a good thing. Anyway, PLPLOT seems to be the most likely candidate to replace PGPLOT, if it gets replaced. It would be some work. Whether it would be _better_ than PGPLOT is not clear. Whether it is worth the effort is also not obvious. Another possibility is to re-interpret the PGPLOT license, and include it with Ifeffit, either as source or pre-built binaries. That is, if debian and Fink can distribute binaries and .deb files of PGPLOT source, why not Ifeffit? That would be a lot less work than using PLPLOT!! I'd also consider other plotting packages as well. The amazing R statistical package has beautiful graphics (and is GPL), but the graphics are deeply embedded and it looks like tons of work to pull them out. A final possibility would be to drop graphics from the core library and rely on the wrapper to handle the graphics. Sam is already using graphics in the GUI with SixPack. If I were starting Ifeffit now, I'd almost certainly do Ifeffit's outer layer in python, leaving only the truly numerically-intensive stuff in a compiled language. That could have many benefits, including better choices of graphics packages. This is a distinct possibility for Ifeffit2, though it would require some work to have a perl interface that Bruce could use. I think it could be workable with a client/server or service model, which could be cool for other reasons, but that's for another discussion.... --Matt