The underlying pdftk tool appears to fully support "qualified" field names -- those that include hierarchical parts, separated by periods, such as "section1.personal_info.first_name" -- and this NodeJS wrapper supports reading field info out of PDFs that contain such field names, but it will not FILL a PDF if the PDF's fields have this kind of naming.
This pull request adds the necessary support for filling PDFs that have hierarchical field names. I have included unit tests. Note: I've had this code in production for several years and it has worked very well. Sorry I'm only getting around now to upstreaming my changes. Please let me know if I can do anything to improve the pull req.
Note: I also included a tweak to an error handler. This was in response to a crash that happened once at runtime. Unfortunately I did not manage to capture the situation that triggered the error, although it must have had something to do with UTF8 encoding (specifically, binary sequences of bytes that could not be interpreted as valid UTF8). See the "fix bug in error handler" commit to see what I did there... it's ugly but it protects against whatever went wrong that one time.
The underlying pdftk tool appears to fully support "qualified" field names -- those that include hierarchical parts, separated by periods, such as "section1.personal_info.first_name" -- and this NodeJS wrapper supports reading field info out of PDFs that contain such field names, but it will not FILL a PDF if the PDF's fields have this kind of naming.
This pull request adds the necessary support for filling PDFs that have hierarchical field names. I have included unit tests. Note: I've had this code in production for several years and it has worked very well. Sorry I'm only getting around now to upstreaming my changes. Please let me know if I can do anything to improve the pull req.
Note: I also included a tweak to an error handler. This was in response to a crash that happened once at runtime. Unfortunately I did not manage to capture the situation that triggered the error, although it must have had something to do with UTF8 encoding (specifically, binary sequences of bytes that could not be interpreted as valid UTF8). See the "fix bug in error handler" commit to see what I did there... it's ugly but it protects against whatever went wrong that one time.