Hi, Tom Tromey wrote: >>>>>>"Wolfgang" == Wolfgang Baer <[EMAIL PROTECTED]> writes: > > > Wolfgang> finally I found the time to clean up all the printing stuff > Wolfgang> on my disk. It's now in a state where I don't expect > Wolfgang> anymore to move files around. > > This patch is very impressive. Great job! > > Wolfgang> Further possible enhancements: > Wolfgang> - Implementing of a printing "About UI" (via ServiceUIFactory) > Wolfgang> - Providing extension panels to browse all printing attributes > Wolfgang> - Providing properties to specify username/password for > Wolfgang> secured cups print services > Wolfgang> - Providing properties to specify cups host > Wolfgang> (if not running on localhost) > > How possible is it to use "native" print dialogs? This definitely is > *not* a requirement for checking in your work -- I just thought I'd > ask as you're clearly the expert here. It seems to me that good > platform integration here would be a "nice to have" feature.
Well, sure it should be possible to use native printing dialogs instead of the (in patch included) swing one. However I don't know anything about gtk/qt (nor C programming) to give any advice here. But the resulting printing settings should be mappable to the IPP ones. One problem might be that the selection of printer in the native dialog must be restricted to cups printers. Other native printers (supported by native printing systems e.g. lprng) cannot be used with the java ipp/cups backend. Just for clarification the Sun way of printing dialogs: - In javax.print (class ServiceUI) always the Swing dialog is used - In java.awt.print there are 4 methods to call a print/pagesetup dialog one of the print and pagesetup dialogs always shows the Swing dialog. The other methods display native dialogs in 1.4 and in 1.5 only if no cups but only native printers are found. > Wolfgang> Beyond javax.print: > Wolfgang> - Implementation of java.awt.print based on javax.print > Wolfgang> (needs implementation of service-formatted data support) > > Last time I looked here, it looked like a couple of the methods here > could be implemented already, they just wouldn't work until your print > stuff was done. Well, I have a patch which implements most of the stuff. However as java.awt.print is only for printing *service-formatted* data this needs to be implemented in javax.print first before it will work. Currently *client-formatted* data is supported, the *service-formatted* implementation is the one I talked at FOSDEM about. There I am thinking about using iText or another Postscript/PDF generator to produce the formatted data. However this is currently only in my head - nothing tried out. > > Wolfgang> I would like to know if you are OK with the directory layout and > with > Wolfgang> the addition of the IPP component for debugging support. > > Yes, this is perfect. > > I skimmed through the source. It looks quite nice to me -- generally > documented, commented, well-laid-out, etc. > > One question I had is whether IppException should derive from > PrintException, instead of Exception as it now does. Good catch. IppException could be directly passed to the user in most cases. I will have a look into this and change if possible. > > But in any case I think this is ok to check in immediately. OK, after I had a look at the IppException. > > Wolfgang> All the stuff is currently only tested against the debian > Wolfgang> cups version (1.1.23) and a virtual pdf printer (I myself > Wolfgang> have no printer atm). > > It would be cool to have a printing demo application -- either > standalone or just by adding printing to one of the existing demos. > But again, this is just a random wish, not any kind of requirement. Its already in the patch. See last entry: gnu.classpath.examples.print.Demo Thanks, Wolfgang
