Details
-
Type:
New Feature
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 4.0 - Beta
-
Fix Version/s: 4.0 - Beta, 4.0
-
Component/s: Viewer RI
-
Labels:None
-
Environment:All
-
Assignee Priority:P2
Description
Need to show a File Save As dialog to get the path to save the altered PDF to. Then invoke saveAs(File) on the Document object.
- May have to use SwingUtilities.invokeLater() so that the ui will repaint after the dialog is closed, before doing the save operation.
- Might want to save on another thread, so that user can continue viewing or PDF. Might not want another thread, so user can't continue altering PDF while it's saving. Specifically thinking about when saving large files, or when saving to network share, how it might take a long time.
- Might want to show progress while saving.
- Might want to detect if PDF changed, and if PDF saving supported (might be pro feature), and then un-grey save-as user interface elements.
Have to decide, if:
A. Block all access to PDF while save as
B. Allow read-only viewing, while temporarily disabling further edits, while save as happening
Have to decide if want to show progress, and means of doing so:
A. Don't show progress
B. RI have progress callback, so it calls Document.saveAs(File, ProgressCallback), which it can then use to update some user interface, like the javax.swing.ProgressMonitor mechanism.
C. Same as B, except instead of ProgressMonitor popup dialog, have something more unobtrusive in the status bar, to facilitate if we use read-only viewing, from the section above.
D. RI adapt the javax.swing.ProgressMonitorInputStream into an OutputStream, and call Document.saveAs(OutputStream)
- May have to use SwingUtilities.invokeLater() so that the ui will repaint after the dialog is closed, before doing the save operation.
- Might want to save on another thread, so that user can continue viewing or PDF. Might not want another thread, so user can't continue altering PDF while it's saving. Specifically thinking about when saving large files, or when saving to network share, how it might take a long time.
- Might want to show progress while saving.
- Might want to detect if PDF changed, and if PDF saving supported (might be pro feature), and then un-grey save-as user interface elements.
Have to decide, if:
A. Block all access to PDF while save as
B. Allow read-only viewing, while temporarily disabling further edits, while save as happening
Have to decide if want to show progress, and means of doing so:
A. Don't show progress
B. RI have progress callback, so it calls Document.saveAs(File, ProgressCallback), which it can then use to update some user interface, like the javax.swing.ProgressMonitor mechanism.
C. Same as B, except instead of ProgressMonitor popup dialog, have something more unobtrusive in the status bar, to facilitate if we use read-only viewing, from the section above.
D. RI adapt the javax.swing.ProgressMonitorInputStream into an OutputStream, and call Document.saveAs(OutputStream)
Issue Links
- blocks
-
PDF-72
PDF incremental updates
-
- Closed
-
Activity
| Salesforce Case | [] | |
| Description |
Need to show a File Save As dialog to get the path to save the altered PDF to. Then invoke saveAs(File) on the Document object. - May have to use SwingUtilities.invokeLater() so that the ui will repaint after the dialog is closed, before doing the save operation. - Might want to save on another thread, so that user can continue viewing or PDF. Might not want another thread, so user can't continue altering PDF while it's saving. Specifically thinking about when saving large files, or when saving to network share, how it might take a long time. - Might want to show progress while saving. - Might want to detect if PDF changed, and if PDF saving supported (might be pro feature), and then un-grey save-as user interface elements. Have to decide, if: A. Block all access to PDF while save as B. Allow read-only viewing, while temporarily disabling further edits, while save as happening Have to decide if want to show progress, and means of doing so: A. Don't show progress B. RI have progress callback, so it calls Document.saveAs(File, ProgressCallback), which it can then use to update some user interface, like the javax.swing.ProgressMonitor mechanism. C. RI adapt the javax.swing.ProgressMonitorInputStream into an OutputStream, and call Document.saveAs(OutputStream) |
Need to show a File Save As dialog to get the path to save the altered PDF to. Then invoke saveAs(File) on the Document object. - May have to use SwingUtilities.invokeLater() so that the ui will repaint after the dialog is closed, before doing the save operation. - Might want to save on another thread, so that user can continue viewing or PDF. Might not want another thread, so user can't continue altering PDF while it's saving. Specifically thinking about when saving large files, or when saving to network share, how it might take a long time. - Might want to show progress while saving. - Might want to detect if PDF changed, and if PDF saving supported (might be pro feature), and then un-grey save-as user interface elements. Have to decide, if: A. Block all access to PDF while save as B. Allow read-only viewing, while temporarily disabling further edits, while save as happening Have to decide if want to show progress, and means of doing so: A. Don't show progress B. RI have progress callback, so it calls Document.saveAs(File, ProgressCallback), which it can then use to update some user interface, like the javax.swing.ProgressMonitor mechanism. C. Same as B, except instead of ProgressMonitor popup dialog, have something more unobtrusive in the status bar, to facilitate if we use read-only viewing, from the section above. D. RI adapt the javax.swing.ProgressMonitorInputStream into an OutputStream, and call Document.saveAs(OutputStream) |
In the RI have it use core Capabilities class, which knows if pro font engine and pro incremental update features are available. Before saving, it will see if incremental updates are available, and if they're not, then show a popup dialog explaining that, and requesting if the user wishes to do a copy of the original pre-existing PDF sans edits, or cancel. This will be shown regardless of whether they've actually edited annotations or not.
Show
Mark Collette
added a comment - In the RI have it use core Capabilities class, which knows if pro font engine and pro incremental update features are available. Before saving, it will see if incremental updates are available, and if they're not, then show a popup dialog explaining that, and requesting if the user wishes to do a copy of the original pre-existing PDF sans edits, or cancel. This will be shown regardless of whether they've actually edited annotations or not.
| Salesforce Case | [] | |
| Fix Version/s | 4.0 [ 10212 ] | |
| Assignee | Patrick Corless [ patrick.corless ] | Carlo Guglielmin [ carlo.guglielmin ] |
| Salesforce Case | [] | |
| Assignee Priority | P2 |
On other thing to consider is the document permissions if encrypted. The Swing controller has few utility method that can be used to check various security properties; havePermissionToPrint(), havePermissionToExtractContent(), and havePermissionToModifyDocument().
I suspect the save as menue item should be disabled if havePermissionToModifyDocument() returns false. Alternatively the 'save as' would stay enable but its functionality would switch over to just saving a copy of the document rather then saving an incremental update.
Show
Patrick Corless
added a comment - On other thing to consider is the document permissions if encrypted. The Swing controller has few utility method that can be used to check various security properties; havePermissionToPrint(), havePermissionToExtractContent(), and havePermissionToModifyDocument().
I suspect the save as menue item should be disabled if havePermissionToModifyDocument() returns false. Alternatively the 'save as' would stay enable but its functionality would switch over to just saving a copy of the document rather then saving an incremental update.
| Repository | Revision | Date | User | Message |
| ICEsoft Public SVN Repository | #19899 | Wed Dec 09 10:11:20 MST 2009 | carlo.guglielmin | |
| Files Changed | ||||
MODIFY
/icepdf/trunk/icepdf/viewer/src/org/icepdf/ri/common/SwingController.java
MODIFY
/icepdf/trunk/icepdf/viewer/src/org/icepdf/ri/resources/MessageBundle.properties
MODIFY
/icepdf/trunk/icepdf/viewer/src/org/icepdf/ri/common/FileExtensionUtils.java
|
| Repository | Revision | Date | User | Message |
| ICEsoft Public SVN Repository | #19904 | Wed Dec 09 11:23:42 MST 2009 | carlo.guglielmin | |
| Files Changed | ||||
|
MODIFY
/icepdf/trunk/icepdf/viewer/src/org/icepdf/ri/common/SwingController.java
MODIFY
/icepdf/trunk/icepdf/viewer/src/org/icepdf/ri/resources/MessageBundle.properties
ADD
/icepdf/trunk/icepdf/examples/component/ViewerPropertiesExample.java
MODIFY
/icepdf/trunk/icepdf/viewer/src/org/icepdf/ri/common/SwingViewBuilder.java
|
| Repository | Revision | Date | User | Message |
| ICEsoft Public SVN Repository | #19908 | Wed Dec 09 12:33:50 MST 2009 | carlo.guglielmin | |
| Files Changed | ||||
|
MODIFY
/icepdf/trunk/icepdf/viewer/src/org/icepdf/ri/common/SwingController.java
|
Marking as fixed as this code was put in a few days ago to handle the various use cases involving Pro / No Pro, ca save / can't save, etc. Also forced the user to choose a unique filename that is different than the original, and also conveniently providing this for them on the first save (as Filename-new.pdf).
Show
Carlo Guglielmin
added a comment - Marking as fixed as this code was put in a few days ago to handle the various use cases involving Pro / No Pro, ca save / can't save, etc. Also forced the user to choose a unique filename that is different than the original, and also conveniently providing this for them on the first save (as Filename-new.pdf).
| Status | Open [ 1 ] | Resolved [ 5 ] |
| Resolution | Fixed [ 1 ] |
| Fix Version/s | 4.0 [ 10222 ] |
| Status | Resolved [ 5 ] | Closed [ 6 ] |
We're going to block all input, and show an hourglass while saving.