| Summary: | Changing PageSize during n-up processing by BeginPage/EndPage generates wrong output | ||
|---|---|---|---|
| Product: | Ghostscript | Reporter: | Masaki Ushizaka <masaki.ushizaka> |
| Component: | PS Interpreter | Assignee: | Ken Sharp <ken.sharp> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | christinedelight.top85, jackie.rosen |
| Priority: | P4 | ||
| Version: | master | ||
| Hardware: | All | ||
| OS: | All | ||
| Customer: | Word Size: | --- | |
| Attachments: |
Bug690667.ps
b690667_acrobat601.pdf b690667_acrobat601.log b690667_gs9906.tiff b690667_gs9906.pdf b690667_gs9906.log test-pb-ep.ps |
||
|
Description
Masaki Ushizaka
2009-07-29 07:21:00 UTC
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.... |