Community
Participate
Working Groups
Most offices run with printers worth about $1500-$2000. Those printers have features not supported by SWT. The following very common features should be added: PageSize: (There is an industry standard fixed list of possible sizes.) Orientation: Landscape/Portait Duplexing: None/Duplex/Tumble InputBins: Numbered 1 through N OutputBins: Numbered 1 through N Of course the PrintDialog needs to support choosing these values, as it normally does on the various platforms. Also, of course, the printer driver can override any of these, they are 'hints' in the normal sense. In fact these are all parameters normally passed through the driver unchanged to the printer. SWT should not itself mess with any of them. Sun's world of Java printing seems to make this mistake. Don't go crazy on this. There are other possible PrinterData attributes, but they are far less common and very rarely used.
any chance to get better printing support in the next release?
Post 3.2
I'm writing a PrintPreview control right now. I can't tell you how much a PrinterData.orientation field would help me, especially if the Printer(PrinterData) constructor used the field while setting up the printer device. Thanks again for GTK printing support!
I was about to enter a request for enhancement when I found this. We would like to be able to suggest to the user - for example - a number of copies to print by setting this in the print dialog, then display it so the user can still change the values if he/she doesn't like it. The values we would like to set include also the features listed (orientation, duplexing, ...). Is this something that would be covered by this bug entry? Or should I enter a new enhancement request?
See bug 52789, bug 96394.
Programmatic control of Duplexing has been added. (see Bug 330512) Orientation was added for a while. We are considering adding programmatic paper size control. Regarding InputBins and OutputBins, would you be able to give a use case where someone would need to programmatically set input & output bins without the user dialog? We are trying to determine how common this use case might be in order to prioritize the work. Thanks!
The use case I had in mind when I first proposed this was automating a production print work flow. The environment was print-on-demand with a large variety of paper sizes and types which could only go through the printers reliably along certain specific paper paths. Any deviation and the printers would jam. The printer's default paths were never correct. Different jobs had different needs. Because of the unusual papers, certain jobs had to be printed in an exact certain way, no exceptions. Certain input bin, certain output bin, and certain duplexing in order to get a certain paper path and not jam the printers. The operator would be told put a certain paper stock into a certain printer bin, then push a "go" button on the computer screen. No other manual intervention was needed nor wanted. Anything as complicated as a print-dialog risked time consuming paper jams or longer term in-field product failures of the printed output. (Paper type needed to be set too, so the ink was fused correctly.) Because there was enough variety in the jobs it was nearly impossible for the human clicking the print dialog options to get these all correct every time. Since there was only one right answer for any given job type, worked out when the job was designed, it was stupid to ask the user. These needed to be set programmatically, without offering the standard print dialog, and that was it. (The dialog was custom, something to the effect of "Load paper type XYZ into bin Q, press "OK-PRINT" or "CANCEL" to abort job.) Phil
I'd like to know if there is any update on this request. Currently I'm developing a report printing routine, in which I'll have to set programmatically all the predefined printing configuration such as printer, duplexing, coping, orientation, outputbin and inputbin. Another problem that I've seen is that not all attributes set to the PrinterData object are loaded to the PrinterDialog. And it's not possible to restore a PrinterDialog to a previous state by using a pre-loaded PrinterData. I'm sorry if this is not the current thread for this kind of request. I'm been searching an answer for weeks now, and this seemed to be the right place to ask it. I was using the AWT printing API, but, as it doesn't have OS dependency, ends up not supporting some driver-specific settings that are more easily managed by SWT. Regards, Victor.
