Community
Participate
Working Groups
is realy needed to get a list of paper formats for a printer!!!
I'll need to add new API to fix this and I can't add new API at this point of the release cycle. I'll look at this problem after 3.1.
3.2 will be released in a few days/weeks. some news about that? it's VERY frustrating that printing is implemented so bad in swt (and java)!!!
sorry, but at this point there is no chance. It is a way too late (see Eclipse 3.2 End Game Plan). I'll add this to the plan for the next release.
Do you mean 'legal', 'letter', 'A4', etc. ?
yes (with the bounds of every format)
what's up with this bug? no 3.3 has released and nothing happens. is there a chance to get it into 3.4? for me it's realy a stopper.
Changing the severity. This is an enhancement request. Do we believe that it will ever be possible to implement this?
Yes, it is possible to implement this, and I intend to, but not for 3.4. (Not sure why I was not the owner of this bug, but I'll take it now <g>). It will be implemented together with several other requests for a more powerful printer API. One example is set/get "orientation", i.e. people want to seed the print dialog with a specific orientation (landscape/portrait), and then they want to find out which orientation the user selected. When the printer is created with the printer data from the print dialog, the new orientation should be honoured. So all 3 printing classes are involved: PrintDialog, PrinterData, Printer. There are maybe about 7 or 8 of these enhancements requested. They should all be implemented together so that we can make decisions like perhaps to store them in a java properties class or something.
Created attachment 158751 [details] GTK Printer Patchv01 This GTK patch contain the changes required for setting various printer fields through fields from PrinterData along with retrieving the various list of paper size names available on the platform. Since Mac doesn't support direct use of printQuality, paperSource, outputBin and meidaType, I haven't added these fields as APIs. However, since they are available on GTK and Win, I make sure that these values are persisted and restored after using the print dialog. Car, can you please review the patch and post your comments. Mac and Win patches will follow soon. Thanks.
Created attachment 158841 [details] Mac Patchv01 Car, Please review and post your comments for the Cocoa patch. Prior to my previous GTK patch, I have added a new field 'resolution' in PrinterData and handled it in PrintDialog class. Thanks.
Created attachment 159788 [details] Windows Printer Patchv01 There are couple of issues in this Windows Printer patch - 1) When Custom size is set - the changes are momentary. Due to unknown reasons, the paper size is overriden by the default paper size. I tried using add a new form, but it doesn't work - comments included in the code describing the issue. 2) There is no direct way of accessing/modifying Nup field through any structure. I tried sort of hack to update Nup through it's private data extending devmode, but it doesn't reflect the change in dialog. Car/Felipe, it would be great if you can shed any light on this. Thanks.
I had a quick look at the Windows patch. I couldn't run it because the PI isn't correct. When that is fixed, please submit a new Windows patch, and I will run it and think further about the API. Here are some notes I took: Always use the platform's parameter names (straight from the platform doc) when you declare a function. For example, in DeviceCapabilities, use pDevice instead of device, and fwCapability instead of capability, etc. Watch out for the difference between A (ascii) and W (unicode, or 'wide') character parameter types. Usually, you need to change the cast from a 'T' chatacter type to a 'W' character type. You can find the actual function prototypes that will be used in the compile by looking at S:\swt-builddir\MSSDKs\Windows Server 2003 SP1 SDK\Include\WinGDI.h and ...\WinSpool.h. For example: DeviceCapabilitiesW(LPCWSTR pDevice, LPCWSTR pPort, WORD fwCapability, LPWSTR pOutput, CONST DEVMODEW * pDevMode); In GetDefaultPrinter, the 2nd parameter (which should be named pcchBuffer, not 'length') should be cast to (LPDWORD). Please look at all of the Console output when you build libraries, and correct all errors and warnings that are generated as a result of your new changes. You may need to look in generated files, like os.c, in order to interpret the Console output. (Use Ctrl+L to 'goto line number'). The cast for the 2nd parameter in OpenPrinter (which should be called phPrinter not 'handle') should be (LPHANDLE) and not (LPHANDLE*). OpenPrinter needs an OpenPrinterA and an OpenPrinterW. Look in WinSpool.h for the function prototypes. The final parameter in SetFormA (pForm) should be cast to (LPTSTR) and in SetFormW it should be cast to (LPWSTR). You need a FORM_INFO_1A and a FORM_INFO_1W, and the pName field needs to be cast to (LPSTR) in FORM_INFO_1A and (LPWSTR) in FORM_INFO_1W. The x and y resolution do not need to be type 'double'. They are 'short' on Windows (dpi = 300, 600, 1200, ...). What are they on the other platforms? Printer.getPaperNameList needs @since 3.6 PrinterData.paperSizeName field javadoc references Printer.getPaperSizeList which is private. (should it be getPaperNameList?)
Car, Thanks a lot for your suggestions. (In reply to comment #12) > > Always use the platform's parameter names (straight from the platform doc) when > you declare a function. I agree with you completely. I will keep this in mind. > Watch out for the difference between A (ascii) and W (unicode, or 'wide') > character parameter types. I will rectify all the Unicode differences and casting warnings. > The x and y resolution do not need to be type 'double'. They are 'short' on > Windows (dpi = 300, 600, 1200, ...). What are they on the other platforms? Mac accepts resolution as double. So, I had to declare them double initially. But, since Gtk (as int) and Win (as short) are different, I will consider changing it to 'int'. > Printer.getPaperNameList needs @since 3.6 > PrinterData.paperSizeName field javadoc references Printer.getPaperSizeList > which is private. (should it be getPaperNameList?) Thanks for catching this. Seems I have missed/typo-error it on Win patch. I will incorporate changes along with preparing Carbon patch. Any other suggestions on other platform patches please ?
Created attachment 161015 [details] Cumulative patch Car, I have modified the code according to your suggestions and the cumulative patch contain code changes for all the platforms - win, gtk and cocoa. Please review it and post your comments. Thanks.
Created attachment 161111 [details] Testcase Testcase to test the newly added fields of Printer. Couple of thoughts for optimizing the code changes - * While setting the fields of printerData into printer through native APIs/structures, the performance might be improved at instances if we check whether the user has set any value or not. Something like - before setting the paperName to Printer, check if (data.paperName != null)...then process it. Otherwise, it mean that User has not set any name programatically. * Is it OK to have only one field for resolution instead of resolutionX and resolutionY ? Car, Could you suggest anything for these changes ?
Created attachment 162862 [details] patch with api, comment, and 64-bit changes In reply to comment 15: >check whether the user has set any value or not Yes, please - wherever possible. >Is it OK to have only one field for resolution I think we should keep 2 fields - there are some printers that use both. SSQ and I reviewed the API and we decided to defer this to 3.7 because it is such a large submission and we were not comfortable with the API yet. We need to go back and forth a few more times, and then the final API should go into 3.7 M1 or M2. I have attached an updated patch taken from your cumulative patch. There are many random changes in the patch. I will explain some of them in my notes below. We looked at and ran your patch on all platforms, but I only made changes on Windows platform. You will have to propagate the changes to the other platforms. Note #1: please run with the jnigen tool enabled in order to catch 64-bit problems every time you save (I could not compile your patch in my workspace because there were 64-bit problems). Here's how: click on org.eclipse.swt project in package explorer, then context menu -> SWT Tools -> Report 64-bit Problems (the menu item should be checked). This might make compilation slower because it is running the 64-bit preprocessor. If it is really slow for you, then uncheck it, but be sure to check it before submitting a patch or committing code. Note that the tool does not process int[] /*long*/ so you need to use int /*long*/ [] instead. PrinterData API: - scale should be int - the X and Y resolution should be int - paperSizeName can't default to A4 because the default in North America is typically LETTER, so don't default to anything (i.e. default is null) - delete PAPER_CUSTOM constant and customPaperName field. If the paperSizeName is an unknown string, then it must be custom, so then you can use the paperHeight, paperWidth, and paperDisplayName fields. (although maybe these fields should always be valid when the dialog returns, i.e. the dialog fills in the values even for standard paper sizes). PrintDialog: - please don't use (string1.intern() == string2) Please use (string1.equals(string2)) instead. - you need to use FORM_INFO_2 to set/get paperDisplayName in the print dialog Printer: - getPaperNameList() should not be static (it should be an instance method since it is specific to the printer) * we are not sure if this API is needed... however, if it is, it should probably return more information for each paper size, i.e. the name, display name, height, and width (you might need a little data object for this... we're not sure if we like adding another new object, but it might not be too bad. The alternative is an array of objects, which isn't great either). - Note that you need to implement all of the new settings in Printer also, not just PrintDialog. (See Printer.create(data) on Windows and Cocoa, and Printer.init() on GTK).
Created attachment 162867 [details] TestSetPrinterData.java Here is the test case I was using. I did not test fully. Note that with this test case, anything the user does, in any order, needs to work. All defaults need to work, and the printed page needs to look correct even if the PrintDialog is not used (i.e. all PrinterData settings need to be reflected in what is printed out). The user's PrinterData values need to be set in the PrintDialog when it is opened, and the user's PrintDialog settings need to be correct in the returned PrinterData. Play with the test case first to see how it works. Please keep this test case up-to-date, i.e. if you change the API, you will need to change the test case accordingly (add new PrinterData field or whatever). Please send the test case back to me when you are done, because I find this test case useful for testing various aspects of printing.
Car, Thanks for the updated patch. I would completely agree with most of your comments/suggestions. However, I think PAPER_CUSTOM constant is required. The reason being - if a user selects any paper size (other than SWT PAPER constants), then we should be able to restore the same paper size instead of creating custom paper for that. So, there has to be a way of identifying whether the user has selected existing paper or custom paper size. For that reason, I would recommend to have PAPER_CUSTOM constant, and allow user to specify if they want to create custom paper. Regarding getPaperNameList() - is there any further discussion on this to finalize the type of results that has to be returned from this method - whether String[] containing paper names, or a different Type itself containing paper info ? I shall upload the updated patches soon.
Add me to CC list to be announced the progress of the patch.
