I've hauled around a incredibly ugly and messy, but fully functional, native gnome print dialog patch for quite a while.
Just some points, and do tell me if I've missed anything or have gone down the wrong path. The "classic" printing (on unix at least) has the printer detection stuff in psprint, and if possible uses cups to make that list or printers, and prints using the cups api, otherwise falling back to the classic lp family of commands. The "classic" dialog then has the usual "standard" options, no of pages etc, and the possibility to set various options described by the printers' ppd file, i.e. what I'll call the "ppd" options. So what I did was to add a gtk-unix-print dialog implementation in tools for PrintDialog execute. The simple options like no-pages, which pages to print etc are easily converted back to their classic equivalents. The "ppd" options are also easily done. Then a number of wrinkles appear: a) The first is that there is always an "export to pdf" pseudo-printer in the gtk-unix-print dialog. So we detect that case and instantiate a com.sun.star.document.PDFFilter to export the current selection/document/set of pages to a file. b) The second is that there is always a "print to file" pseudo-printer in the UI even if there are no printers. Here I begin the messiness as we'd want to use the same ppd if there are printers, or no printers for this feature. So the hack was to consider the "generic printer" a special printer in CUPSManager::initialize so that it always exists, and use it as the printer when the "print to file" pseudo-printer in the UI was selected. c) The third is that the printer dialog refreshes the list of printers when e.g. a new one has been has added, so the dialog can become aware of a printer before the rest of OOo has become aware of it if the printer is e.g. plugged in while the dialog is open, leading to the possibility of trying to print to a printer unknown by OOo. The next miserable hack was to make public ImplDeletePrnQueueList, and to split out the ctor and dtor code of CUPSManager as "stopsearch" and "startsearch" and when an unknown printer was selected in the UI we can rescan for printers and force vcl to reread the freshly detected new list and then continue with the now known printer. d) The fourth is that in the gtk-unix-print dialog as well as the "standard" options, and the "ppd" options there are the "cups" options. These are features that cups handles like "2 pages in one" and "print this document at 10pm on tuesday". So we extend the JobSetup and friends to have an additional SetCupsKey sort of api to collect those settings and spit them out when printing through cups. e) There are a number of minor difficulties, such as the gtk print dialog can be configured to just to non-cups, and pure lpr stuff. In which case the "custom print command" is a setting which the dialog provides. And then we have all those per-application "special options" dialogs, which I've simply left as they are and placed a button to launch the classic "special per-app options" dialogs for stuff like "print notes only" in impress, though I'd like to instead get them converted into an additional tab page in the printer dialog instead. I expect that the mac printing dialog has a similar feature-set, which is no surprise as they both sit on top of the same basic set of technology and thinking. In an ideal world what would be nice is an api uno or otherwise, to stick in a printer dialog implementation where the result of a print operation is a destination printer known to OOo, a set of "standard" options, a set of ppd options and a set of cups options which can propogate down to psprint to be given out to cups "as-is". With support for an always existing "generic printer" for print to file and extensible to handle a "print to pdf" non-printer destination. I guess, at this point what would be interesting is to know about the mac print dialog features and if there are additional ones over and above the type of features described above. FWIW I can make up a set of screenshots if there's any interest. C. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
