gelphman@adobe.COM (David Gelphman) (12/16/90)
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 >like flyers or newsletters that are mailed to diffrent individuals. >Unfortunatly, the duplex implementation does (currently) not work in >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 >sided page, and then using copypage, kick another copy of the page >out. As more and more duplexing printers (I know of on that is >currently in the works) come out, unless this is changed, they will >be crippled, and virtually useless. 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 on a simplex printer. I get four sheets of paper, each of which has marks on one side of the paper: 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. 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 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''' Indeed that is what I get on a duplexing PostScript printer when using copypage as described above. I believe this is the behavior that most PostScript programmers expect and is appropriate given the semantics of the PostScript language. It may not allow copypage to achieve some special purposes; however, I believe it is the correct implementation. General comment: In many cases, copypage is used by PostScript programmers to enable forms printing at high speed. One of the problems with copypage is that it copies ALL of the graphics from the previous page image which is typically NOT what a forms programmer wants. We have tried to address this shortcoming with a new mechanism in PostScript level 2 which allows for 'forms' to be created and imaged with the benefit of caching when possible. A form is similar to a font with one character but it can contain color information and still be cached (unlike fonts). I hope this clarifies things a bit. David Gelphman Adobe Systems Incorporated Developer Technical Support
woody@chinacat.Unicom.COM (Woody Baker @ Eagle Signal) (12/17/90)
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
chris@bullwinkle.UUCP (Chris Andersen (The Dangerous Guy)) (12/18/90)
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
jmm@eci386.uucp (John Macdonald) (12/19/90)
In article <1760@chinacat.Unicom.COM> woody@chinacat.Unicom.COM (Woody Baker @ Eagle Signal) writes: |In article <9184@adobe.UUCP>, gelphman@adobe.COM (David Gelphman) writes: |> |> I believe this is the behavior that most PostScript programmers expect and | |Just for grins, let's take a poll on this one. It's a breath/candy mint. These are two different interpretations, useful in different ways. The "each face is built from the previous" allows you to do incremental activites (allowing a sort of time-lapse photography). The "each two-faced page is built from the previous" allows easy duplication (or near duplication). I would find Woody's method more often useful, but neither is really what is best. I agree with David's comment that the most useful is a form type, where a page is built on a previously defined form (one of many, which allows you to do either type of activity argued about above). Of course you might run into memory problems if you define too many forms... -- Cure the common code... | John Macdonald ...Ban Basic - Christine Linge | jmm@eci386