🚀 go-pugleaf

In article <9184@adobe.UUCP>, gelphman@adobe.COM (David Gelphman) writes:
> In article <1736@chinacat.Unicom.COM> woody@chinacat.Unicom.COM (Woody Baker @ Eagle Signal) writes:
> 
> >On a single page printer, you can image a page, do a copypage, and then
> >go back and erase a portion of the page, change the data and do another
> >copypage etc.  This makes for very fast generation of repetitive things
> >an analogous manner.  If you print a double sided newsletter, say, and
> >then want to change some data on one of the pages, you have to re-image
> >the entire document.  What should happen, is that you should be able to
> >make either the front or back side the currently active side, so that
> >you could select side 1, change data just like you can on a single
> 
>     To the contrary, I believe that the current implementation of
> copypage on duplex devices is the one most useful for almost every use
> of duplex printing. In addition it is exactly as it should be in order 
> to follow the normal semantics of the PostScript language. An example
> is probably appropriate.
>    Consider a page description which calls showpage 4 times and is printed
> 
> sheet number	1	2	3	4
> page image	A	B	C	D
> 
> Now imagine printing the same document on a printer which is printing
> on both sides of the paper:
> 
> sheet number    1-side1	1-side2	2-side1	2-side2
> page image      A       B       C       D
> 
> This is what one would expect when printing duplex and indeed that
> is what you get on a PostScript printer which supports duplex printing.

Exactly.  But the point here, is that you have to re-transmit the entire
two pages again, or if you have taken the time to distill them to a procedure,
you have to go through the long process of re-imaging them again.

What about the case of
1     2     3     4
A     B     A     B
i.e. a two page printing repeated.
or
1    2    3    4    5   6    7   8   
A    B    C    D    A   B    C   D

on a duplexing machine the first case should be

1    2    3   4
A    B    A'  B'

the second case

1   2   3   4   5   6   7   8
A   B   C   D   A   B   C   D

This one appears to be the same.  Note:  that,  A B   and   C D  really
are SIDES to the same sheet.  Now  If I image A B and do a copy page
I should get
1   2   3   4   5   6   7   8 
A   B   A'  B'  A'' B'' A''' B'''  I now send c and d down, and do copypage:
1   2   3   4   5   6   7    8
C   D   C'  D'  C'' D'' C''' D'''  Note:   that since the printer
can only store 2 pages in the video buffers at a time, you would HAVE to
send  AB  <showpage or copypage>  CD <showpage or copypage> inorder
to be able to do the incremental changes that the "red book" says you can
do with copypage. 

> 
> 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.


> I get if instead of calling showpage in the above example I call
> copypage imaging each page.
> 
> On a simplex printer:
> 
> sheet number	1	2	3	4
> page image      A       A'	A''	A'''
> 
> Where A' is a page image which contains all of A and whatever
> marks I place before the next copypage. A'' is a page image
> which contains all of A' and whatever marks I place before the
> next copypage, and so on.
> 
> 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.
> 
> 
> I believe this is the behavior that most PostScript programmers expect and

Just for grins, let's take a poll on this one.

> allow copypage to achieve some special purposes; however, I believe it
This is not just "some special purpose".  If you use your printer to
produce say a multipage book, it becomes even more important.
> 
The solution to this is simple.  It would solve the problem for folks
who need it solved, and would also allow operation the way that Adobe
thinks it should.  That is an operator that would allow the selection
of either side of the page to be the current page.  If it was not invoked
before the duplex print was done, then you get whatever broken thing that
is currently being done.  If it is invoked, then you can modify the page,
and the print operation can (if copypage is invoked), handle it intellegently
and produce the results desired.  Just make it possible to select EITHER
side of the page, as the current page to image on, and the problem goes
away.  You can then, image a page, (both sides) and do a copypage, select
either page, modify it incrementally, and copypage would then be able to
copy the page again (always starting with page 1 of course).  It wouldn't
matter for showpage, as that wipes the page anyway.



Cheers
Woody