| Re: Postscript dump to a Laserwriter [message #632 is a reply to message #631] |
Fri, 18 December 1992 09:46   |
scowen
Messages: 11
Registered: December 1992
|
Junior Member |
|
|
In article <18DEC199211000500@stars.gsfc.nasa.gov>, thompson@stars.gsfc.nasa.gov (William Thompson, code 682.1, x2040) writes:
|> I don't understand this part. I have trouble seeing how the internal commands
|> like CONTOUR, TVRD, TVLCT, etc. can affect the values stored in the COLORS
|> common block.
Well, so do I - but try it. It does exactly that - completely forgetting the
stretch you've set.
|> >1. Given a color strectched image with contours overlaid, how can I produce
|> >*either* color or laserwriter PS from a tvrd() call (ignoring the screen-
|> >dump bugaboo)?
|>
|> You can do a dump of a window with exactly the same colors that appear on the
|> screen by using TVLCT,/GET to get the current (stretched) color table. For
|> example,
|>
|> IMAGE = TVRD(0,0,!D.X_SIZE,!D.Y_SIZE)
|> TVLCT,RED,GREEN,BLUE,/GET
|> SET_PLOT,'PS'
|> TV, IMAGE !Note: Not TVSCL
|> TVLCT,RED,GREEN,BLUE
|> SET_PLOT,'X'
Unfortunately, Bill, this does *not* work. I've just tried it several times,
with several different stretches, and the resulting PS file looks execatly
the same for all versions. It uses the default setting of b/w linear in the
4bit mode, which is of no use to me. This is my whole point.
|> >2. Alternatively, using the tvscl method, is there anyway to stop the
|> >colormap in colors (common) from being erased by the contour call, so we
|> >could reload the strectched version of the colortable before tvscl is
|> >called. And then (long winded I know) redo the contours inside the PS
|> >setup?
|>
|> This shouldn't happen. I suspect that your using some software to do the
|> contour plot that also makes calls to some routines that manipulate the COLORS
|> common block (e.g. LOADCT, STRETCH, etc.). Either that, or the values in the
|> common block no longer represent what you're seeing on the screen, but you're
|> assuming that it does.
Well, I'm using CONTOUR in NOERASE mode to produce the overlay contours. If
what you're saying is true then I guess I'll have to lobotomise the .pro file
for my own purposes.
|> >3. Does RSI plan to fix this rather annoying feature in tvrd() since it
|> >doesn't appear to be a terribly uncommon feature for such a function, to
|> >grab the data that is off screen instead of dumping the actual screen
|> >buffer itself?
|>
|> Another related problem is that TVRD can be messed up if the window being read
|> is partially obscured by another window. It would be nice if that could be
|> changed too.
Well, yes, that's the problem I'm having with a display widget that has
scollbars and so has part of the image obscured by the widget frame.
Thanks for your response Bill.
--
------------------------------------------------------------ -------------------
Paul A. Scowen INTERNET: scowen@wfpc3.la.asu.edu
Department of Physics & Astronomy uk1@spacsun.rice.edu
Arizona State University Tel: (602) 965-0938
Tempe, AZ 85287-1504 FAX: (602) 965-7954
------------------------------------------------------------ -------------------
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
