> 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.
Configuring a printer from a print dialog is exactly what I am talking about.
You select color quality, line quality, print speed, stapling, collation of reports, and all that stuff. A person must decide this when printing.
If you want to be able to print anything other then plain single-sided black and white documents then the ability to edit postscript documents and insert the proper printer-specific control sequences on the fly is a absolute requirement.
Depending on the printer you can send usually postscript directly to it. Over a parrellel port or USB port or over IPP connection. It may need to be rendered into USB control sequences for cheapy ones using a proprietary daemon.
> A much saner system for graphical printing would be for applications to use some combination of shared libraries to discover what printers are available,
So you want to distill the functionality provided by CUPS and Ghostscript (and related filters, tools, and programs) into application libraries and then load that into each and every application? How would that work out well?
> 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.
So instead you want each and every application will be in the position of rendering to some baroque programming language, and loading and reinterpreting it into something printer specific.
That seems completely ass-backwards. Typically the OS wants to make things easier for programmers to do by providing common functionality instead of making it worse...