Re: Top 10 IDL Requests

[Craig Markwardt <craigmnet(at)cow.physics.wisc.edu>]

"Mark Hadfield" <m.hadfield@niwa.cri.nz> writes:

> > "Kristian Kjaer" <Kristian.Kjaer@Risoe.Dk> wrote in message
> 3981DA40.F3BC8FC9@Risoe.Dk">news:3981DA40.F3BC8FC9@Risoe.Dk...
> >
> > A print button (and an equivalent cmd-line command) which would work
> > on (direct) graphics already rendered to the screen (using std. direct
> > graphics commands) would null _the_ major quirk in IDL, IMHO.
> 
> And how would it be done?
> 
> Once a direct graphics command has sent output to an output device, the only
> "memory" IDL has of that command is the changed state of the output device.
> At that point the system (or the user) has two ways of recreating the output
> to a different device:
> 
> 1. Switch devices & re-issue the same commands
> 2. Read the output back off the device and send it to the new device.
> ...

3. Have the direct graphics window itself store the required data to
   reproduce the output, and the ability to redirect to a new device.

And I am totally serious; this is what I hacked up with XFWINDOW,
which puts a "print" button on any direct graphics window under Unix.
It's a hack because IDL doesn't provide enough documented
functionality to achieve the full effect.  I had to go stealth. :-)

The professional astronomy package ESO/MIDAS and the plotting program
QDP have similar functionality: plot windows can remember their input
data, and with a simple command can be redirected to the printer.

The complaint could be made that such a feature might require too much
memory, in the case of complex or repeatedly redrawn graphics.  There
are pretty simple ways to get around this too.  Sigh...

Craig

-- 
--------------------------------------------------------------------------
Craig B. Markwardt, Ph.D.         EMAIL:    craigmnet@cow.physics.wisc.edu
Astrophysics, IDL, Finance, Derivatives | Remove "net" for better response
--------------------------------------------------------------------------