[comp.lang.postscript] n-up printing of Encapsulated PS file

rjchen@phoenix.Princeton.EDU (Raymond Juimong Chen) (02/05/89)

What I mean by n-up is printing n logical pages on one physical
page.  

From what I can figure from the EPS specs, an EPS-processing
program cannot be guaranteed that the last command on a logical
page is a "showpage".  Moreover, it cannot be guaranteed that
the "showpage" is not buried inside a macro that is "bind def"ed.

For example,

%%Page: ? 1
bop % a beginning-of-page macro, which perhaps sets up something
    % (although I don't see what, since everything should have been
    % set up by the prologue; all I can imagine it doing is a "save")
......... % assorted page information
eop % an end-of-page macro, which perhaps completes some output begun
    % by the "...", does a "showpage", and a "restore".
%%Page: ? 2
... and so on ...

Now, merely redefining /showpage doesn't seem to be feasible, since
the /eop macro might have been "bind def"'ed, so that it always
grabs the "official" showpage macro.

Am I misreading the specs?  
(Does anyone already have a program that does n-up printing of EPS files?)
-- 
Raymond Chen	UUCP: ...allegra!princeton!{phoenix|pucc}!rjchen
		BITNET: rjchen@phoenix.UUCP, rjchen@pucc
		ARPA: rjchen@phoenix.PRINCETON.EDU, rjchen@pucc.PRINCETON.EDU
"Say something, please!  ('Yes' would be best.)" - The Doctor

greid@adobe.com (Glenn Reid) (02/08/89)

In article <6114@phoenix.Princeton.EDU> rjchen@phoenix.Princeton.EDU (Raymond Juimong Chen) writes:

>Now, merely redefining /showpage doesn't seem to be feasible, since
>the /eop macro might have been "bind def"'ed, so that it always
>grabs the "official" showpage macro.

If you redefine "showpage" before "eop" is defined, there is no
problem.  If you read carefully the description of the "bind" operator,
it only binds names which point to objects of type "operatortype".
Thus the following will work just fine:

    /showpage { (showpage redefined here) = flush } def
    /eop { showpage } bind def

In general, when you redefine something you send it ahead of the whole
file, so using "bind" doesn't cause a problem.

There are many EPSF files which do not contain "showpage" (for example,
Adobe Illustrator files).  It is probably better to write a front-end
filter to place them exactly where you want them:

	%!
	/*showpage /showpage load def
	/showpage {} def

	/page save def
	0 792 2 div translate .5 .5 scale
    % file 1 here
	page restore

	/page save def
	612 2 div 792 2 div translate .5 .5 scale
    % file 2 here
	page restore
	
	/page save def
	0 0 translate .5 .5 scale
    % file 3 here
	page restore

	/page save def
	612 2 div 0 translate .5 .5 scale
    % file 4 here
	page restore

	*showpage

or something like that.  Then it doesn't matter whether they execute
"showpage" or not.  You call it when you want the page printed.

This is, in fact, something like what a page layout program would do
with four EPSF files that were placed in four quadrants of the page and
scaled to 50% each.

There is one major caveat: the EPSF files may not have a standard
bounding box, and you must correct for this in order for the preceding
scheme to work.  You have to read the %%BoundingBox comment, take the
first two numbers, and add a final "translate" (it's important to put
it after the "scale" command) with the negatives of those coordinates.

For example, if the bounding box for file 3 is

	%%BoundingBox: -10 -792 602 -792

You would add one more line to the above example for file 3 that looked
like this:

	10 792 translate

I hope this makes some sense.

Glenn Reid
Adobe Systems