From: scowen@wfpc3.la.asu.edu (Paul A. Scowen)
Subject: Re: Postscript dump to a Laserwriter
Organization: Dept. of Physics & Astronomy, Arizona State University
Date: Fri, 18 Dec 1992 17:46:15 GMT

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
-------------------------------------------------------------------------------
Newsgroups: comp.lang.idl-pvwave