Bug Hunting Session
Bug 126642 - Allow PDF form export with different defaults based on Archive setting
Summary: Allow PDF form export with different defaults based on Archive setting
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Printing and PDF export (show other bugs)
Version:
(earliest affected)
6.3.0.1 rc
Hardware: All All
: medium major
Assignee: Jan-Marek Glogowski
URL:
Whiteboard: target:6.4.0 target:6.2.7 target:6.3.1
Keywords: filter:pdf
Depends on:
Blocks:
 
Reported: 2019-07-31 16:40 UTC by Jan-Marek Glogowski
Modified: 2019-08-08 11:13 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jan-Marek Glogowski 2019-07-31 16:40:20 UTC
I've been trying to fix the PDF form export dialog w.r.t. the Archive (PDF/A) setting. Currently we disallow form exports for PDF/A-1, but allow it for PDF/A-2.

see filter/source/pdf/pdfexport.cxx line ~600

case 1: // PDF/A-1
  mbExportFormFields = false;
case 2: // PDF/A-2
  // no mbExportFormFields setting

According to all my sources there is no difference in form restrictions / allowances between PDF/A-1 and PDF/A-2, so that doesn't make any sense.

OTOH according to http://blog.soliddocuments.com/2012/12/pdfa-1-vs-pdfa-2.html there is a difference for comments, which we doesn't seem to handle, but that can be an other bug…

Still normally you actually don't want to keep the form controls in a PDF/A. And since PDF/A is for archiving, in the very most cases it doesn't make any sense to create a form when selecting PDF/A, as people shouldn't change the form values. So the document just contains something that looks like a form, but doesn't allow the user to change it.

All this stems from the changes made to fix bug 62728, which explicitly allowed forms for the new PDF/A-2 support.

So here are some proposals to fix this:
1. Allow form export for all PDF types
2. Have different "Create form" settings depending on the "Archive" checkbox.

I have two different ideas to handle this:
1. keep the dialog but change the string of the "Create PDF form" checkbox to "Create PDF form (Archive)" depending on the "Archive" setting
or
2. just add a 2nd checkbox named "Create PDF form (Archive)" and handle it the opposite of the "Create PDF form" checkbox.

Currently I'm in favor of the 2nd checkbox.

If we don't allow the string change, we could simply disable form export for PDF/A for older releases, as this is the most common use case. We had a lot of users creating "wrong" PDF/A document after creating normal PDF forms. This is even more annoying, as LO defaults to "Create PDF form" on export.
Comment 1 Jan-Marek Glogowski 2019-07-31 17:03:54 UTC
Simple workaround patch disable PDF/A form export at https://gerrit.libreoffice.org/#/c/76765/
Comment 2 Jan-Marek Glogowski 2019-07-31 17:45:28 UTC
I just verified the "Create form" is enabled per default.

And I fixed an other error in the updated patch. If you export a PDF/A and the export a PDF/A again, the "Submit format" and "Allow duplicate field names" used to be enabled.

And if you export a PDF/A and then a 2nd one and unselect the Archive checkbox, the "Create form" would still be insensitive.
Comment 3 Heiko Tietze 2019-07-31 17:56:21 UTC
Dislike another checkbox with almost the same name. Why not disable/uncheck for A1 likewise its done for Tagged PDF?
Comment 4 Thorsten Behrens (CIB) 2019-07-31 18:07:43 UTC
First, confirm - this inconsistency is there.

Secondly, as A/2 definitely permits forms - why remove the functionality, now that it's fixed and even validating? Why not give users the option to export (or not)?
Comment 5 Jan-Marek Glogowski 2019-08-01 14:34:30 UTC
(In reply to Thorsten Behrens (CIB) from comment #4)
> First, confirm - this inconsistency is there.
> 
> Secondly, as A/2 definitely permits forms - why remove the functionality,
> now that it's fixed and even validating? Why not give users the option to
> export (or not)?

Ok - so the updated patch will actually enable form export for any PDF, but still fix the handling of the overriding value of UseTaggedPDF, if PDF/A is selected.

I've done a backport for pre-6-3, which will just disable PDF/A form export.

(In reply to Heiko Tietze from comment #3)
> Dislike another checkbox with almost the same name. Why not disable/uncheck
> for A1 likewise its done for Tagged PDF?

I don't follow you here. The disabling is done for Tagged PDF,  because PDF/A requires the document to be tagged. My problem is different. Per default LO generates PDF forms, which are changeable by the user. PDF/A is used for archiving, so you almost always want to generate PDF/A without active form elements. For example a checkbox will be replaced by an image of the required state, so a user can't change it, even by accident.

Still PDF/A also allows a valid PDF to contain active form elements. That's why Thorsten says the decision should be up to the user, now that PDF/A export with active forms works correct.

My point is just that the very most of the users want to generate normal PDF forms but no PDF/A forms for archiving. And I thought it might be a good idea to offer two distinct "Create form" settings. Maybe in the end this is not needed, or the usability is even worse, as now the user has to remember to manually switch the "create form" setting based on the selected target PDF type.
Comment 6 Jan-Marek Glogowski 2019-08-01 16:55:41 UTC
PDF/A form disable workaround for LO 6.2, based on the master patch: https://gerrit.libreoffice.org/#/c/76820
Comment 7 Commit Notification 2019-08-07 08:44:50 UTC
Jan-Marek Glogowski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/+/c864d894a90141f6d73ed80c1035909986b17074%5E%21

tdf#126642 always allow PDF/A form export

It will be available in 6.4.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 8 Commit Notification 2019-08-07 08:45:04 UTC
Jan-Marek Glogowski committed a patch related to this issue.
It has been pushed to "libreoffice-6-2":

https://git.libreoffice.org/core/+/aac306e7ea42eeac3d6c1860f25061148ba2f547%5E%21

tdf#126642 correctly handle the PDF/A settings

It will be available in 6.2.7.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 9 Jan-Marek Glogowski 2019-08-07 10:54:58 UTC
The committed patches just fix the general dialog and UNO handling. This doesn't include any changes to the UI to address my suspected usability problem. Maybe that should move to a 2nd bug report. Backport for 6-3 is pending in Gerrit as https://gerrit.libreoffice.org/#/c/77092/
Comment 10 Commit Notification 2019-08-07 21:30:15 UTC
Jan-Marek Glogowski committed a patch related to this issue.
It has been pushed to "libreoffice-6-3":

https://git.libreoffice.org/core/+/76fcd878da1624e73f1eb9d9405485d4faf66edf%5E%21

tdf#126642 always allow PDF/A form export

It will be available in 6.3.1.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 11 Samuel Mehrbrodt (CIB) 2019-08-08 11:13:38 UTC
Let's have this bug closed and handle additional problems in separate bug reports.