🚀 go-pugleaf

On a tangential note, it seems to me that a good way to write Postscript code
for pictures (which allows them to be easily embedded inside other structures)
is to always generate them within the coordinate space (0,0) -> (1,1). They can
then be scaled, rotated, and translated appropriately so as to occupy the
desired region.

It also seems to me that there is a class of pictures for which the actual
dimensions of the picture on the output medium is not interesting; rather, the
picture should simply fill the output medium. Ok, you probably want to preserve
the aspect ratio. So, then you are left with the question "what is the largest
this picture can be scaled uniformly in both dimensions and still fit in the
output medium?"

Answering this question requires that you know the output medium's dimensions,
right?

So, I set about figuring out how to calculate this in Postscript, and found
that it didn't seem to be possible independent of language level. The
'getdeviceparms' call seemed appropriate, but isn't defined for Level 1
interpreters.

Has anyone come up with code to do this?

Does someone think I am on the "wrong track"?
--

-- Bob

In <RMF.92Oct1203636@chopin.cs.columbia.edu> rmf@chopin.cs.columbia.edu
(Robert M. Fuhrer) writes:
>[wants to be able to determine how big the output page is so PS
>programs can scale themselves to fill it]

The default clipping path is the imagable area of the output page.
Simply call "clippath flattenpath pathbbox".


Ciaran.
-- 
Ciaran McHale                                                             ----
Department of Computer Science, Trinity College, Dublin 2, Ireland.       \bi/
Telephone: +353-1-7021539 FAX: +353-1-772204 email: cjmchale@dsg.cs.tcd.ie \/

In article <1992Oct2.114504.26092@dsg.cs.tcd.ie> cjmchale@dsg.cs.tcd.ie (Ciaran McHale) writes:

   In <RMF.92Oct1203636@chopin.cs.columbia.edu> rmf@chopin.cs.columbia.edu
   (Robert M. Fuhrer) writes:

   >[wants to be able to determine how big the output page is so PS
   >programs can scale themselves to fill it]

   The default clipping path is the imagable area of the output page.
   Simply call "clippath flattenpath pathbbox".

Try and avoid doing such things UNLESS you are sure that noone will EVER try
and use this as an inserted figure.  If your graphics is included as an
EPS file somewhere this trick will kill any positioning and scaling done by
the enclosing PS code.  Most annoying that some reall applications produce
code just like this!  In defense, the application importing the PS has to
play games like changing the clipping path...

Berthold K.P. Horn
Cambridge, Massachusetts, USA

>  In article <1992Oct2.114504.26092@dsg.cs.tcd.ie> cjmchale@dsg.cs.tcd.ie (Ciaran McHale) writes:
> 
> 	  In <RMF.92Oct1203636@chopin.cs.columbia.edu> rmf@chopin.cs.columbia.edu
> 	  (Robert M. Fuhrer) writes:
> 
> 	  >[wants to be able to determine how big the output page is so PS
> 	  >programs can scale themselves to fill it]
> 
> 	  The default clipping path is the imagable area of the output page.
> 	  Simply call "clippath flattenpath pathbbox".
> 
>  Try to avoid doing such things UNLESS you are sure that noone will EVER try
>  and use this as an inserted figure.  If your graphics is included as an
>  EPS file somewhere this trick will kill any positioning and scaling done by
>  the enclosing PS code.  Most annoying that some reall applications produce
>  code just like this!  In defense, the application importing the PS has to
>  play games like changing the clipping path...

The idea was to be able to write postscript code that would "work" regardless
of the output medium. Therefore, I needed to be sure that such code could be
reasonably inserted (i.e., scaled and translated) in an output page. So the
included code would not have the "clippath flattenpath pathbbox", the including
code would.
--

-- Bob