[Ifeffit] Max OS X woes -- Solution ?

[Paul Fons]

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 at aist.go.jp
tel. +81-298-61-5636 fax: +81-298-61-5615

The lines below are in Japanese
主任研究官　ポール・フォンス
産業技術総合研究所
光技術研究部門
つくば市茨城県　 305-8568
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 8283 bytes
Desc: not available
URL: <http://millenia.cars.aps.anl.gov/pipermail/ifeffit/attachments/20021213/f190e86c/attachment.bin>