🚀 go-pugleaf

Oliver, 

Most non-GDI applications that generate their own PostScript actually let the driver et.al. handle the "setpagedevice" paper handling issues (collation, input trays, duplexing, output trays, copy count, etc.) in terms of PostScript generation. 

The interactions between the application, driver, and spooler are more complex than you realize. In GDI printing, there is something called EMF spooling. The interactions between the application and GDI (i.e., GDI commands) are initially spooled with some driver interaction, but PostScript is NOT generated or spooled at that time. When the printer is available, the spooler despools GDI and generates PostScript "on the fly" via the PostScript driver and sends that directly to the printer. When there is collated copies, the spooler despools it "n" times. 

For non-GDI applications, the spooler and driver are used in RAW spooling mode in which case, PostScript is spooled and when the printer is ready, that fully generated PostScript is simply despooled without any further intervention. For such jobs, the spooler has no way of intervening in terms of collated copies. 

For GDI applications with spooling OFF, such as for "to FILE" printing or spooling to network queues, PostScript is generated immediately by the driver. Since the spooler is not involved, collation via repeated sending of PostScript jobs is not available. 

As far as we know, it doesn't work any differently in Windows XP. 

I don't think it is a matter of "fixing" a problem, but rather determining what the desired behaviour would be in these other cases. 

If you print "to FILE" with collated copies, what should it mean if the designated printer device doesn't support the setpagedevice collation key? Pages 1 through "n" repeated "m" times if the copy count is "m" as part of the same job? That would require major changes to the protocols of how GDI, the spooler, and the driver interact. Concatenate "m" identical PostScript jobs in the same file? That is even more problematic because it violates the rule of one PostScript job = one file. 

As I said, there is no easy "fix" to this. (And as far as we know, there is no alternative spooler available and if there was, the protocols don't exist to "fix" the problem.) 

- Dov 

PS: When you refer to LPT port, the same behaviour occurs with any spooled port including AppleTalk ports, USB ports, and direct TCP/IP ports.