Some observations. In conjunction with the initialization file from fink there are path variables set that tell where the fink pgplot directory is (presumably on other Unixes as well). In terms of moving away from pgplot, I have been using a crystallographic library that uses blt (written in tcl) that is an extension to tcl/Tk. This is free and has scientific graphics functionality and also is being continually updated. The web site is: http://sourceforge.net/projects/blt/. The advantage here is that this is a write-once use everywhere library. The downside is that it is in tcl/Tk so you would have to interface via some intermediate code from fortran, but I suspect Bruce knows a lot more about Tk than I. The blurb on sourceforge states: The BLT Toolkit is an extension to Tcl and Tk. It adds new commands and widgets to the Tcl interpreter. Included widgets are 2D graph, barchart, stripchart, tab notebook, and tree viewer. Also in looking over the fink list, there is a gnu library called plotlibs (http://www.gnu.org/software/plotutils/) which is a device independent library that outputs in just about every format available. This is callable from fortran or c and also would seem to support a format a windows viewer could use (I think other than a blt/java route windows will always have to be different -- Bill Gates wants it that way) (from the web site) GNU libplot and libplotter support all the output formats mentioned above (X11, SVG, PNG, PNM, pseudo-GIF, WebCGM, Illustrator format, idraw-editable Postscript, PCL 5, Fig format, HP-GL/2, ReGIS, Tektronix, and GNU Metafile). They can produce animated pseudo-GIFs, and smooth, double-buffered animations on any X Window System display. The libplot imaging model is similar to Postscript's. In any output format, they can draw the following. • Graphical objects such as lines, circles and ellipses, points, and marker symbols; also paths. A path is defined as in Postscript as a sequence of line segments, arcs (either circular or elliptic), or Bezier curve segments (either quadratic or cubic). Paths may be open or closed, and they may be dashed. The filling of paths is supported (fill color, as well as pen color, may be set arbitrarily). • Text strings, in many fonts. Text strings may include subscripts and superscripts, and may include characters chosen from more than one font in a typeface. The X11, SVG, WebCGM, Illustrator, Postscript, and xfig drivers support the 35 standard Postscript fonts, and the SVG, Illustrator, PCL 5 and HP-GL/2 drivers support the 45 standard PCL 5 fonts. All drivers support a set of 22 Hershey vector fonts. This includes HersheyCyrillic, a Russian font that uses the KOI8-R encoding, and HersheyEUC, a Japanese font that uses the 8-bit EUC-JP encoding. Japanese text strings may include both syllabic characters (Hiragana and Katakana) and ideographic characters (Kanji). A library of over 600 Kanji is built in. When using libplot or libplotter, a programmer draws vector graphics in a `user frame', rather than in the device frame. As in Postscript, the user frame may be transformed into the device frame by an arbitrary affine map. Scaling, rotation, shearing, and translation are all supported. On Friday, December 13, 2002, at 08:17 AM, Matt Newville wrote:

Bruce, Paul,

...

Solving the problem at the level of ifeffit's build doesn't quite address the horae problem. The whole point of putting Ifeffit.pm and the wrapper in the horae tarball was one-stop shopping for perl-y goodness. However, it may suffice if the ifeffit C program, when invoked with a --pgplot_dir command line flag, writes the location of pgplot to STDOUT and exits. Then I could use perl's exec command in the Makefile.PL to set the compiler's -L flag properly. I normally avoid exec because I don't understand how it works on Windows. But I don't have Makefile.PL compile the wrapper on Windows, so it should be ok.

See, I think ifeffit's build *should* solve horae's problem on Unixes (Mac OS X included). Windows is inherently different. On Unix, the issue of how to link to Ifeffit lib, PGPLOT lib (any extra libs like X, png, ...) and generic C libs on any particular machine are all fully determined when Ifeffit's Makefile is run.

So Ifeffit's build can write all the needed build info without relying on ExtUtils::F77, OS-specific switches, or any hardwired values. In fact, an easily parsed Config.mak is built and installed. In perl, this could be used like this:

$iff_path = `ifeffit -i`; chomp $iff_path; $iff_path =~ s/ $//g; $file = "$iff_path/config/Config.mak"; open(F,$file) or die "no file $file .. Ifeffit not installed?\n"; my @keys = ('LIB_IFF','LIB_PLT','LIB_F77','INC_IFF'); my %build; while(<F>){ chomp; foreach $i (@keys) { if (/^$i[ ]*=(.*)/) { $build{$i} = $1;} } } close(F) foreach $i (@keys){ print "$i: $build{$i}\n";}

I'm sure it could be done more elegantly... But Ifeffit's build should be fixed to make sure it finds /sw/lib/pgplot and not /sw/pgplot for PGPLOT on MacOS X.

...

Actually fink is way better than RPM. (More precisely, debian's apt-get is way better than RPM. Fink's cleverness was to use apt-get but the credit for an amazing packaging system goes to those clever debian folks.)

I can agree that Fink is clever, and that apt is more clever than RPM. I may even agree that apt is _better_ than RPM. That's not high praise. All binary package systems are painful. Like, Fink can just up and decide to move PGPLOT, and we're screwed.

...

And, yes, pgplot is a thorn in my side. Adam Webb at the U of Alberta had the linux equivalent of this problem the other day.

What was the linux problem? PGPLOT_install should work fine on all linuxes. Or did Adam do something silly like rely on a binary package from debian... Oh, wait a second.

I'd much prefer a plotting lib that could be built with ifeffit, not relying on a separate library, and worked better on Windows. I'd be willing to use python/blt myself, but some people still like perl, so something that works in C/Fortran is needed. PLPLOT is a possibility, so is using R, or wxWindows. PLPLOT is the most like PGPLOT, but less stable than PGPLOT (no, really), but at least they're working on it. R is straight C (GPL'ed), and probably a LOT of work to use, but makes lovely plots.

--Matt

Paul Fons, Ph.D. Senior Staff Researcher Photonics Institute National Institute for Advanced Industrial Science & Technology Tsukuba, JAPAN 305-8568 email: paul-fons@aist.go.jp tel. +81-298-61-5636 fax: +81-298-61-5615 The lines below are in Japanese 主任研究官　ポール・フォンス 産業技術総合研究所 光技術研究部門 つくば市茨城県　 305-8568