George asked me to look at this spoolfile. Beyond the custom page size, here is a little more information:
1. This print job was prepared with a PPD file for a Panasonic printer and so contains PS code specific to that device - it will cause an error on other devices (such as a Ricoh or maybe even another Panasonic). Posters in this thread mentioned the DP-C265, searching for some of the ProcSet names online returned DP-C405, they seem to be in the same product line. It would be nice to know for sure that the printer and PPD were properly matched, in order to eliminate that possibility.
2. This print job appears to have different settings for the same parameter; now, that's ok in theory, because the last setting simply replaces the previous setting, but it does indicate a potentially confused workflow.
line 461..........Duplex set to false
line 3239........Duplex set to true
line 598..........PageSize set to 595 x 842 (that's A4)
line 3239........PageSize set to 210 x 332 (custom page size, a little bigger than A7)
line 3245........PageSize set to 210 x 332 (again! Indicates possible multiple upstream sources for page settings)
3. There is a ProcSet for XPDF at the beginning of the file - I guess this open-source code was used to convert PDF -> PS - the procedure" pdfSetup" defined there is called on line 3239 and sets Duplex, ImagingBBox and PageSize after all other setup commands have executed, including separate commands for all three of those parameters. These parameters can have a significant effect on printer memory when changed, because a big chunk must be allocated for the frame buffer (raster memory) and the size depends on the page size and duplex setting (and resolution, and margins,...). In the case of this print file, the printer is forced to re-allocate memory several times before it even starts to draw anything. Some posts in this thread mentioned strange behavior, ghostly crashes and long print times, this all sounds a bit like a case of trashed memory, doesn't it? It was also mentioned that the duplex setting makes a difference in this case - and duplex is being set by this pdfSetup procedure - so it's all very suspicious.
4. When I remove all the Panasonic-specific feature settings and that dang pdfSetup call, this file prints very quickly (less than 30 sec.) on a Ricoh MP C2800, a relatively old and slow printer. So all of the trouble is in the setup process, which is basically an interaction between the driver and the PPD file.
5. Finally, about that PageSize setting of 210 x 332. When Acrobat is asked to print a custom page size like that, it makes that size a clipping path rectangle on a standard paper size the printer supports, such as A4 or Letter. This job is actually asking the hardware to set up a physical page size like that - something the paper path in the printer doesn't support, who knows what happens.
George asked me to look at this spoolfile. Beyond the custom page size, here is a little more information:
1. This print job was prepared with a PPD file for a Panasonic printer and so contains PS code specific to that device - it will cause an error on other devices (such as a Ricoh or maybe even another Panasonic). Posters in this thread mentioned the DP-C265, searching for some of the ProcSet names online returned DP-C405, they seem to be in the same product line. It would be nice to know for sure that the printer and PPD were properly matched, in order to eliminate that possibility.
2. This print job appears to have different settings for the same parameter; now, that's ok in theory, because the last setting simply replaces the previous setting, but it does indicate a potentially confused workflow. ......PageSize set to 595 x 842 (that's A4) .....PageSize set to 210 x 332 (custom page size, a little bigger than A7) .....PageSize set to 210 x 332 (again! Indicates possible multiple upstream sources for page settings)
line 461..........Duplex set to false
line 3239........Duplex set to true
line 598....
line 3239...
line 3245...
3. There is a ProcSet for XPDF at the beginning of the file - I guess this open-source code was used to convert PDF -> PS - the procedure" pdfSetup" defined there is called on line 3239 and sets Duplex, ImagingBBox and PageSize after all other setup commands have executed, including separate commands for all three of those parameters. These parameters can have a significant effect on printer memory when changed, because a big chunk must be allocated for the frame buffer (raster memory) and the size depends on the page size and duplex setting (and resolution, and margins,...). In the case of this print file, the printer is forced to re-allocate memory several times before it even starts to draw anything. Some posts in this thread mentioned strange behavior, ghostly crashes and long print times, this all sounds a bit like a case of trashed memory, doesn't it? It was also mentioned that the duplex setting makes a difference in this case - and duplex is being set by this pdfSetup procedure - so it's all very suspicious.
4. When I remove all the Panasonic-specific feature settings and that dang pdfSetup call, this file prints very quickly (less than 30 sec.) on a Ricoh MP C2800, a relatively old and slow printer. So all of the trouble is in the setup process, which is basically an interaction between the driver and the PPD file.
5. Finally, about that PageSize setting of 210 x 332. When Acrobat is asked to print a custom page size like that, it makes that size a clipping path rectangle on a standard paper size the printer supports, such as A4 or Letter. This job is actually asking the hardware to set up a physical page size like that - something the paper path in the printer doesn't support, who knows what happens.
-David