[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Top 10 IDL Requests

"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 B. Markwardt, Ph.D.         EMAIL:    craigmnet@cow.physics.wisc.edu
Astrophysics, IDL, Finance, Derivatives | Remove "net" for better response