On Tue, 4 May 2004, Rolf von Kuhlmann wrote: > Here is an update and hopefully a solution to the issue: My aim was to > produce a number of high quality postscript files directly from a shell > script, and with the orientation and scaling as I want it. I think I > could find a solution, based also on a previous posting in this list. > Basically I was trying to get the same power as the "gksm2ps" options > but in batch mode, where "metafile" stuff is not working. Options 1 and > 2 where not satifactory, but No. 3 does the job nicely. > > 3) use the -unmapped option. It seems to allow "set > window/aspect=XY/size=XY" commands for the first internal ferret window > and also set + cancel metafile commands, but not "set window/new". > Then use gksm2ps to creat the ps file to your needs. With this method it > is possible to create nice looking single page ps-files. Hi Rolf, We ran into this at GFDL a while ago, and came to the same conclusion: "ferret -unmapped" provides the best functionality when it comes to PostScript output. Like interactive ferret, "ferret -unmapped" allows you to write multiple PostScript files in a single session, while "ferret -batch" writes only one, with squashed graphics. Note: at present, "ferret -unmapped" requires a connection to a valid display, even though Ferret doesn't actually generate a window on the screen. Hopefully this will not cause problems for you. In our case, we needed to run in batch mode on a computer cluster, to produce a set of standard diagnostic figures as part of of our GCM postprocessing. The cluster was not connected to any displays, so "ferret -unmapped" by itself did not work. Steve Hankin suggested a workaround using the Xvfb (virtual frame buffer) utility, which creates a "fake display" in memory. This works well in a single-user environment -- you start Xvfb, set the display to that, run "ferret -unmapped", and then terminate Xvfb. If you must run in a multi-user environment, things get much more complicated -- you'll have to manage the Xvfb displays yourself, to ensure that users don't kill each other's displays. To implement this at GFDL, I wrote some scripts that use "lockfiles" to protect the displays. I've attached these scripts (tar -xzvf go_ferret.tgz) so you can get some idea of what's involved. We run a daily crontab to clean out defunct lockfiles, which get left behind when the cluster crashes or the user kills the Ferret batch job. Hopefully, these details will be wrapped into Ferret at some point. Cheers, Andrew +--------------------------------------------------------+ | Dr. Andrew T. Wittenberg | GFDL/NOAA | | Andrew.Wittenberg@noaa.gov | Princeton, NJ | +--------------------------------------------------------+
Attachment:
go_ferret.tgz
Description: go_ferret.tgz