> Cups will take the postscript from your application and then insert additional instructions to it based on the PPD file (aka 'driver') and your configuration dialogs. Instructions on how to handle ink, line speed, stapling, duplex, etc etc.
This is evidence of a dedicated printer mentality. Why in the world should a typical user configure a 'printer' in order to get a specific print job to print the way he wants it to? Users should have the ability to control all of that from within some sort of print dialog in the application.
>This is why you need things like Ghostscript, because CUPS must have the ability to tear down postscript 'documents' and then rebuild them for specific printer models.
A much saner system for graphical printing would be for applications to use some combination of shared libraries to discover what printers are available, what properties they have, allow the user to configure the specific print job, render (ultimately) through a standard API directly to a printer driver loaded in-process, and send the output of the printer driver to the spooler on a local or remote system.
Then the system wouldn't be in the position of rendering to some baroque programming language, and loading and reinterpreting it into something printer specific. X style process separation for the printer driver could be kept if necessary, but the idea that Postscript should be the lingua franca for communication to a printer driver is positively perverse.