Changing PageSize with setpagedevice causes calling of EndPage procedure with reason code 2 (device deactivation). Current Ghostscript seems to have a problem with this handling. I created a PS job which first set A4 paper size, setup watermark and 4-up (2x2) BeginPage/EndPage procedures. Then print 3 simple (sub)pages, after that changes paper size to Letter, and quit. This job should create a A4 size output, but gs generated a Letter size output with garbage in it. I confirmed this with r9906 trunk, on both WinXPPro SP3 + VS2008 and MacOSX 10.5.7 + Xcode 3.1.2. I see three issues here. 1. Gs outputs a Letter size, where it should be a A4 size. And for a raster device, previous 3 subpages rendered in A4 size seems just dumped into Letter size memory, making a garbage in image. 2. The forth calling of EndPage, which was caused by PageSize change, seems like executed after changed paper size to Letter, where it should be done with A4 size. At least from raster output it looks like so, but the currentpagedevice says PageSize is still A4. And, for this EndPage execution, the matrix is initialized to device default one, where is should keep A4 (sub)page context. 3. For fifth calling of BeginPage and EndPage, which is a first call with Letter size device activation, the operand (page count) is 3, where is should be 0. Reproducing procedure comes in next comment.
Created attachment 5248 [details] Bug690667.ps A file 'Bug690667.ps' is a job I created to reproduce. BeginPage and EndPage procedure makes several debug print and those can see in .log files. b690667_acrobat601.pdf is generated using Acrobat Distiller 6.0.1 and, which I believe, it illustrates what correct output should be. b690667_acrobat601.log is a log generated with it. b690667_gs9906.tiff is generated using this command: $ bin/gs -sDEVICE=tiffgray -o b690667_gs9906.tiff Bug690667.ps In this file I see 3 problems; a. the size is 612x792 (Letter), b. three subpages become garbage, and c. the string (3 2 EndPage #4) which is printed by 4th calling of EndPage, is printed with device default matrix, not subpage matrix. b690667_gs9906.pdf is created by this command: $ bin/gs -dCompatibilityLevel=1.2 -dSAFER -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -o b690667_gs9906.pdf -c .setpdfwrite -f Bug690667.ps This file displays same symptoms with b690667_gs9906.tiff except (b), because this is not a raster format. b690667_gs9906.log is outputs from above two command. I see 4th EndPage is under device default matrix, and 5th BeginPage/EndPage is called with page count 3. Compare this with b690667_acrobat601.log.
Created attachment 5249 [details] b690667_acrobat601.pdf
Created attachment 5250 [details] b690667_acrobat601.log
Created attachment 5251 [details] b690667_gs9906.tiff
Created attachment 5252 [details] b690667_gs9906.pdf
Created attachment 5253 [details] b690667_gs9906.log
Reassign to support for proper assignment next meeting.
I believe that commit 88bce110851c10455d3165ca748a3371d9c917cc fixes this one. We now reset the count of pages whenever we execute setpagedevice, even if the device doesn't change, and the execution of the EndPage routine has been moved to be much earlier in the setpagedevice process, so that it occurs *before* we change the device parameters.
The non-standard ShowpageCount device parameter isn't an Adobe parameter, but resetting this on every setpagedevice doesn't seem like what we want, since a setpagedevice that sets the PageSize (for example) because as far as I can tell this should reset the parameter passed to BeginPage and EndPage. The definition of the "count" parameter in the PLRM says this is the count since device activation, and setpagedevice doesn't deactivate the device.
(In reply to comment #9) > The non-standard ShowpageCount device parameter isn't an Adobe parameter, > but resetting this on every setpagedevice doesn't seem like what we want, > since a setpagedevice that sets the PageSize (for example) because as far > as I can tell this should reset the parameter passed to BeginPage and > EndPage. It does, that's exactly why I changed it. > The definition of the "count" parameter in the PLRM says this is the count > since device activation, and setpagedevice doesn't deactivate the device. If you try this with Adobe Acrobat (as I stated in the commit log) it resets the parameter passed to BeginPage and EndPage on *every* execution of setpagedevice, even "<<>> setpagedevice" I don't have access to any other Adobe interpreters to try this on.
Created attachment 10147 [details] test-pb-ep.ps This works OK before the patch, but not after, since the BeginPage and EndPage procs are always getting the same count (== 1) with the patch that resets the ShowpageCount too aggressively. Tested on Windows with: gswin32c -o nul: test-bp-ep.ps The 'After switching device' section shows that the original _did_ properly reest the ShowpageCount when the ppmraw device is selected. Note that if run with gswin32c -sDEVICE=ppmraw -o nul: test-bp-ep.ps The ShowpageCount is _not_ reset, which is probably what is expected since selecting the current device should not deactivate it.
BTW, I forgot to mention, that I am not sure that changing PageSize _should_ reset the ShowpageCount or not. Since this is not an Adobe device parameter, it isn't clear, but in reading the PLRM, I don't think it should. This should be testable with Adobe. If you want me to run a test with CPSI, let me know.
testing with CPSI shows that setpagedevice, even with an empty dictionary deactivates the device, as Ken's patch now does with gs. So, basically any N-up printing will not work if the pages perform any setpagedevice. If this is in the PLRM anywhere, I can't find it. It doesn't seem like ideal behavior if one is trying to do N-up printing, but that's how it is. Re-closing the bug as fixed. Sorry, Kens.
(In reply to comment #13) > testing with CPSI shows that setpagedevice, even with an empty dictionary > deactivates the device, as Ken's patch now does with gs. Yes, that was what I found with Adobe Distiller. Much to my astonishment I have to say. > So, basically any N-up printing will not work if the pages perform any > setpagedevice. If this is in the PLRM anywhere, I can't find it. I couldn't find anywhere in the PLRM which was specific about what would cause 'device deactivation', which is why I was experimenting with Acrobat. And how I ended up with an empty dictionary test..... > It doesn't > seem like ideal behavior if one is trying to do N-up printing, but that's > how it is. I have to agree, but it seems like this is what Adobe want to do, especially if your result on CPSI is the same. Maybe there's something I'm missing....