-
Notifications
You must be signed in to change notification settings - Fork 364
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
Form field names incorrect in resulting PDF #42
Comments
I didn't think of that use. The problem is that non ascii characters are only allowed in the mapping name. I suspose we could use the name if it is valid and warn and revert to a slugified name, if not. What do you think? |
I think that sounds reasonable |
Needs more testing and a cleanup but basic tests seem to be working.
It turns out the restriction on non-ascii characters was lifted in Acrobat 6.0 so that's alright. I've done the basic implementation and will test further tomorrow. It's important to point out that in PDFs fields can be terminal or non-terminal only, not both. So this would fail because <input type="text" name="parent"/>
<input type="text" name="parent.child"/> |
Also, names must now be unique for each control (except radio button groups). So this would produce incorrect output: <input type="checkbox" name="gender" value="male"/>
<input type="checkbox" name="gender" value="female"/>
<input type="checkbox" name="gender" value="other"/> |
I think this is fixed so closing for now. Feel free to reopen if you have any further problems. |
the PDField partial name is being set to an internally generated name like "OpenHTMLCtrl1" and only the mapping name is being set to the name in the HTML. This causes lookup from PDAcroForm.getField(String) to fail when looking up by the name in the HTML because the mapping name is not used in that lookup.
The text was updated successfully, but these errors were encountered: