Details
Bug
Major
Description
Changes in the print dialog don't have an effect on the currently printed document but only on next the following documents.
The org.icepdf.ri.common.PrintHelper.java class holds two member member attribute sets that are not functional independent.
private HashDocAttributeSet docAttributeSet;
private HashPrintRequestAttributeSet printRequestAttributeSet;
both are initialized in the
PrintHelper(DocumentViewController,
PageTree
MediaSizeName
PrintQuality)
constructor.
Into both of these attribute sets arte initialized to hold a MediaSize and a MediaPrintableArea Attribute.
Both initial values are set to NA_LETTER if no persisted properties are found or to whatever is defined in the properties file.
Before printing is started a printing dialog is opened.
But if the media size is changed in this dialog, the result is not transferred into the docAttributeSet so these attribute sets are no longer consistent. For rendering the PDF in PrintHelper.print() a PageFormat is given which is taken from the docAttributeSet and the media change in the print dialog is ignored.
It is either necessary to synchronize the Media and MediaPrintableAreaSize attributes in the docAttributeSet and the printRequestAttributeSet after the printDialog returns or not to define these attributes in the docAttributeSet in the first place. So the user has the possibility to change the media size in the print dialog.
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
To recap the points to be addressed:
1. Proper parsing of config files
2. Ensure that selected page format is used for print request
3. Keep selected print settings in print dialog when called the next time
4. Check whether default value for paper format can be taken from document if there is no value in config file specified
Updated PrintHelper to no longer uses the docAttributeSet object when creating a new SimpleDoc. This avoid the synchronization of the docAttributeSet and printRequestAttributeSet objects when the print dialog updates the printRequestAttributeSet object.
Create bug PDF-255 so that we can go back and touch up the API and documentation if docAttributeSet is really not needed by the end user.
Notes from customer:
1. Paper format is persistently saved now - but during my tests I found that the media formats seem to be limited to a certain set of size (e.g. A5, A4 and letter work but A0 is not saved even if supported by the printer). Is there a reason for this?
2. Scenario when there's no property file still causes problems: Remove the .icesoft directory in your home dir and start IcePDF viewer, open a document and press print --> multiple dialogs with parse problems popping up.
1) There is currently no way to save a paper size by name. It can only be saved by size. When size properties are reread they are passed into the class MediaSize.findMedia():MediaSizeName. This method appears to be returning the first paper size name that matches the specified dimensions. My Guess is that the any discrepancies are do to a media size that has multiple names.
2) the ICEpdfDefault.properties has ';' at the end of the paper sizes and units which is incorrect and causing the parsing error.
Created PDF-259 to capture the parsing error.
Likely not the greatest idea to have one Jira encapsulating so many issues but may as well continue this way. Two observations from the customer that need correcting:
1. Paper format persistency doesn't work for all paper formats. One example B5 paper format will be selected the second you open the dialog for B4 it won't. For user this can be pretty annoying. This also is true for other formats.
2. As previously mentioned our PDF viewer runs in an embedded environment where there is no property manager defined per default. Could you provide the default property manager also for this kind of scenario and if not provide me with the details how to implement it in a holistic way - holistic because as a container I'm not interested what kind of content is currently loaded and which specific settings I might have to do.
Resolving issue as original issue was fixed for 4.1.4. Reference code was sent to client to show use of PropertyManager within a parent application.
If a new issue comes out of the reference code a new issue should be created.
Customer has asked if we can also review adding the properties defined in the document.