-
Notifications
You must be signed in to change notification settings - Fork 69
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Checkboxes Failing to Detect State for Valid PDFs #43
Comments
For anyone else with this issue, I have now forked this repo and added this rough fix along with a couple of other quick and dirty fixes. Performed some limited testing and so far all good. |
Hi, Always same problem |
Even when using my fork? |
Hello, this is a solution which work for me.
I add this lines :
In order to do the change with the best practices, you can extends FPDM class, and redefines copy/paste the function parsePDFEntries() and make the update here. Example :
|
The code seems to assume that the checkbox "on" definition is aways first in the "/AP" Appearance Dictionary. This causes the checkbox code to set the wrong state for any PDF where the "off" definition is before the "on" definition.
For example a PDF with this checkbox Appearance Dictionary
Will generate the following troubling data in the fpdm [infos] => Array:
I have checked the ISO 32000 and older PDF 1.4 reference and there seems to be no requirement for the "on" definition to appear before the "off" definition which would explain why a lot of PDFs have the reverse definition layout. The references do, on the other hand, seem to both state that the off-state definition must be named "Off", so this might be a better way to tell which definition is which.
Here is my horrible, rushed, hacked, redundancy filled solution.
In fpdm.php from line 1859 I replaced this
With this:
Also, just another possible minor issue. It seems that the code is looking for the definitions in the Appearance Dictionary's optional "down appearance" (/D) instead of the required "normal appearance" (/N). This seems like it might also cause issues for some PDFs if they include the "normal appearance" definitions but not the optional "down appearance".
The text was updated successfully, but these errors were encountered: