> Ghee.Teo at sun.com wrote: > Are there plans to make CUPS the Solaris 11 default printer management? > > The user interface to this is very simple and is the only printing system I > found to be both (1) available on Linux & Solaris X86 and (2) capable of > properly communicating with any printer I have > gotten.
On CUPS, I'll just give a pointer to: http://www.catb.org/~esr/writings/cups-horror.html It's not easy to come up with a user interface (be it GUI, curses or commandline based) where a user (who knows what he wants to achieve, but is not familiar with the implementation) can "just do" what he intents to. It's even more difficult to design this interface in a way that it reinforces correct thought models of the process and discreetly corrects those that lead to erroneous assumptions. As far as printing is concerned, it may be an interesting experiment to take a look at the MacOS X GUI to CUPS, which is doing a few things differently (while still modifying the same configuration files). >From a user point of view, I'd want a UI (User Interface, graphic or not) to: - show the status of a job I have submitted, if possible: - where is it? (in queue, submitted to printer (to what extent/page), printing (page count), in output tray x, stopped (where in the process, and why? Is my job preventing others from being printed, or is it just waiting indefinitely? What is holding my job (Quota? too large for spool filesystem? Too large for printer memory?) How long has it been waiting? Is there an estimate how long it will have to wait in that print queue?) - which printing options have been set/are necessary for the job? (paper size/specific paper slot, duplex, finisher options...) Not all printers may be able to give such a detailled feedback, but I'm just summing up what I'd like to see at a glance, if possible. Also: - other print queues available, and their processing status (busy/unavailable/idle since ... hh::mm, number of jobs, estimated time until printout if a new job gets added, estimated time until completion (speed of printer, and page count of job are known, so giving an estimate isn't exactly rocket science), capabilities of these print queues (duplexer, finisher,location, paper options,...) - with a gui: drop-and-drag movement of a job from one queue to another as long as it hasn't started printing yet. As user, I'd like to select from already defined queues, be they local or on the network, as well as add acces to those I may know that are there (even if not explicitely preconfigured by administration as long as they aren't blocked for me intentionally). It's difficult to explain to a user why he might be able to use cat and ftp to print to local or networked printers, but not the UI without prior "system administrator magic". So I think there should be a way for a user to define his own printer queues/spooling directories. If the UI gives the status of a job as clearly as described above, (and is able to show on which filesystem at which location a job in spool is lingering) I don't hava a problem with personal configurations. Some of those ideas require communication with the printer, but a surprising number of them can be achieved by just keeping a "better" track of jobs as they are submitted. This would also reduce the number of dormant jobs in the filesystem which never got printed due to errors. These are not just a minor hassle, but can turn out to be a major security problem. At a site that shall be unnamed, there had been the desktop computer from legal sent to maintenance. Once connected there, it happily started printing an impressive stack of (highly) sensitive stuff that had erronously been sent to an unavailable printer (and, lacking better feedback from the spooling system, just been resent when it never turned up). When the spooling system noticed a printer with the desired capabilities, it just started to spew out what had been hogging its spool. Therefore - better printer management (and usability in general) can be considered a security feature. It's never wrong when a user knows where his stuff went and what's happening with it. -- Tatjana This message posted from opensolaris.org
