Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!uunet!zephyr.ens.tek.com!tektronix!sequent!toontown!bullwinkle!chris
From: chris@bullwinkle.UUCP (Chris Andersen (The Dangerous Guy))
Newsgroups: comp.lang.postscript
Subject: Re: copypage on duplex printers
Message-ID: <1378@bullwinkle.UUCP>
Date: 17 Dec 90 17:12:17 GMT
References: <1734@chinacat.Unicom.COM> <9184@adobe.UUCP> <1760@chinacat.Unicom.COM>
Organization: The Department For Doing Departmental Things
Lines: 99

woody@chinacat.Unicom.COM (Woody Baker @ Eagle Signal) writes:
>In article <9184@adobe.UUCP>, gelphman@adobe.COM (David Gelphman) writes:
>> 
>> Now what happens if you use 'copypage'. The effect of 'copypage'
>> is to allow marks on a given 'page' to be copied to the next page
>> instead of starting with no marks on the next page. Here the meaning
>> of the word 'page' is exactly as it is in the previous case, e.g.
>> it means the next page image which may be on a different physical
>> sheet (simplex printing) or the same sheet (duplex printing). Here is what
>
>Woah!.  I quote the "red book"
>outputs one *copy* of the current page on the **current output device**
>WITHOUT ERASING the current page or changing the graphics state....
>as a means for printing successive pages with incrementally
>accumulated contents..
>This says that you are supposed to be able to print a page, 
>incrementaly change the contents, and copy the page again.  over and
>over.  This cannot be done in the current duplex printer implementation,
>when printing on both sides.

A page != a sheet.  A "page" is a single imageable region described by a set
of PostScript code.  A "sheet" is a physical piece of paper upon which a 
printer can image the "page" described in PostScript.  In simplex one page
turns out to be one sheet while in duplex you have TWO pages per sheet of
paper.  As described in the redbook copypage should function the way David
describes.

The problem is that PostScript is not a Printer Control Language.  It is a
Page Description Language with little to no knowledge of the underlying 
printer mechanisms which implement the imaging of a page (it need not even
be a printer).  PostScript is concerned only with the descriptions of 
individual pages.  One of the few concessions PostScript makes to the 
underlying implementation is the "showpage" operator whose only function
is to pass the currently described page off to the printer controller.  It's
up to the controller to determine what to do with it.

Of course the seperate of PostScript from the underlying hardware is an
ideal which unfortunately is a LOT more difficult then it would seem (in fact,
I would say this is the #1 reason why so many clone makers have gone out of
business: they consistently run into difficulty when trying to realize the
theory of PostScript on an actual hardware platform).  This problem results
in confusing things like what does copypage mean in duplex mode (let alone
#copies!) and the mess of paramaters currently stored in statusdict.

Fortunately PostScript Level II is a bit more realistic and understands that
while seperation of Page Description from Page Imageing and Page Delivery is
a nice theory it just isn't practical in real life.  It has a more robust
facility for handling device dependent features.

>> Now if I am printing to a duplex printer, I would hope that the results
>> are consistent with what I obtained in the example above. I would expect:
>> 
>> sheet number	1-side1	1-side2	2-side1	2-side2
>> page image	A	A'	A''	A'''
>
>Wrong.  This says that duplex printing is useless.  You get the same
>page on all sheets.  What you should get is:
>
>using showpage
>
>1-side1  1-side2  2-side1  2-side2
>A         B          A      B
>
>now, copypage should work the same way, using the same model.
>
>1-side1   1-side2   2-side1   2-side2
>A         B         A'        B'    ....etc.
>
>This preserves the consistancy of the way that copypage and show
>page work in a simplex machine.  2 copies (1 for each side)
>exist in a duplex printers ram.

"copypage" is simply a "showpage" without the erasure of the page between
delivery to the underlying hardware.  That is all.

Admittedly it would be nice to have something comparable to what you are
talking about here.  But it goes beyond what I perceive to be the original
intent of copypage.  What is needed is some form of page context switching.
In essence, a printer that has TWO pages being processed at any time and
PostScript commands for switching between the two pages at will.  In such
an environment, copypage WOULD function the way you describe here.  

Unfortunately this kind of functionality is not built into PostScript (either
Level I or II).  I'd be interested to see how it could be done such that
PostScript code meant for such a printer could still be sent to a printer
without this special environment, yet still produce the same output.

In other words, could such a PDL be described that would still be portable?

>> I believe this is the behavior that most PostScript programmers expect and
>
>Just for grins, let's take a poll on this one.

As you can guess from the above this is the behaviour I expect from PostScript.

-- 
Chris Andersen (..!uunet!sequent!toontown!chris)

  "Life: live it or live with it!"  -- Firesign Theater