I have a PDF that I am using PDFTK to rip the fields out of. My problem is that the order of the fields and field names are not very clear in the field dump. For example: Checkboxes are given field name "box7", "box3", "box2". I do not know which checkboxes these are without testing.
I need to be able to pro grammatically identify these fields. Or I need to know their location on the pdf.
Ultimately, how can I properly identify these fields either through the user clicking on the field they want or pro grammatically?
Open your pdf in Adobe LiveCycle form designer (included with paid versions of acrobat from version 7 and up). You can see the form field names, rename them as needed etc... LiveCycle blows acrobat forms out of the water! I use PDFTK/PHP/LiveCycle PDFs my work to run our entire product labeling system and created a document self service portal for customers on our website.... feel free to follow up with more questions if you get stuck
Related
I have a problem, it used to work great but suddenly it isn't working anymore. I hope I'll be clear.
I have a client (real estate website) and he uploads with ACF a unique pdf brochure per blogpost(listing), on the listing pages there's a CF7 and when that's filled out the customer will a unique brochure pdf URL e-mailed to them.
As a said it worked really well, but for some reason, the ACF output changed from URL to ID and I can't seem to find a reason why. So instead of a nice link, for example, www.link.com/2021/example.pdf I now only get a file id like 65432 for example.
The output is on FILE-URL in ACF
The hidden field that I use with the Dynamic Text Extension plugin:
[dynamichidden pdf_brochure "CF7_get_custom_field key='pdf_brochure'"]
Can somebody point me in the right direction or show me a different solution on how to get the dynamic pdf URLs outputted into the form submissions?
Have a nice day!
I am trying to create a website where you can create some forms for your customers irl. I am trying to fit in function that allows you download the final version of your form (in PDf format).
I am looking for solution:
Some sort of plugin or way how you can add into PHP website function that allows you select area of website (obviously I want to convert only the form, not NAV nor footer of site, so the selected area will be everytime the same) to PDF.
Some other way that allows the user download his form as a picture.
But I need something that I can include into PHP based website, not C#.
Thank you for any solutions / advices!
I want to provide a PDF with a form on my Website. It is integrated with an iFrame. When the user has filled it out, it should be save with the user fillings (not empty) on a directory of my Webspace. Is there an elegant solution to this possibly using PHP? Thanks.
No.
Because you can't control what browser is used, you can't control what PDF viewer is used to fill the form. Some embedded PDF viewers won't even be capable of filling form fields. My recommendation is to collect the data using standard HTML, then populating the form using any one of the several PHP libraries that can populate PDF forms, then present that to the user and have them sort of "approve" it, at that point, you save it to your Webspace.
That said, there are solutions like Adobe Sign that will convert the PDF to and HTML5 rendition that allows you to fill the form in any browser then retrieve the data and/or a static PDF for storage on your Webspace.
I am using FPDM to auto-fill a PDF form fields from a MySQL database via a Wordpress plugin. This works well and the form is generated and filled correctly. However, if I download the generated and filled PDF and send it to other people the form fields are blank to some but not to others.
I am thinking that this is may be a font issue but can't seem to nail down the issue. The template text is Times New Roman. The fields use Times Roman which when I look at Fonts on the PDF Properties pages shows a Custom font (Times Roman) with actual font name TimesNewRomanPSMT. The page also shows TimesNewRoman as an embedded font, like so...
Filled PDF Fonts page
Has anyone else experienced this problem?
Thanks
It's likely the issue is that FPDM does not create something called "appearances" for annotations (fields are a type of annotation), it just populates the value. An appearance allows a PDF viewer that doesn't know about annotations to display their appearance without needing to understand how to use the annotation's properties. Some viewers will generate appearances if they are not present, some won't.
You can test my assertion. If you're seeing blanks by default but see a value when you try to edit the field, then what I describe above is the problem.
I got a form with fill-able form fields made by Acrobat, it is rather complex.
Via PHP I want to "simply" attach another page, add a barcode to the form page and add meta info.
Currently I do not manage to retain the fields fill-able or tcpdf/fpdi simply cannot read the compression of the pdf. I tried a couple of different pdf version but don't succeed so far.
I tried pdflib but work now with tcpdf and fpdi, however there seems no way to make it happen.
I can attach pdf files and use templates, just not in any format that has or retains fill-able fields.
Is tcpdf/fpdi able to do this at all?
Do you know of any other solution to achieve this? (PHP/linux based)
What you want to do is not possible.
Adobe uses an own proprietary way to create and fill PDF forms. Adobe Reader does only support to fill PDF forms...
...which were created by an Adobe product and
...which have been assigned 'extended rights' so Reader can indeed save the formdata alongside the document.
There are a number of methods, utilities, tools and programs to create and fill PDF forms nevertheless: Scribus, iText, pdflib, tcpdf, pdftk, Foxit, XSL FO, OpenOffice.org or LibreOffice and more... However, Adobe Readers will refuse to fill+save form data with documents created by these means.
The technical mechanism behind this is: Adobe digitally sign their form documents with their own key. This key is known to the Adobe Reader and all Adobe Products. And you agreed to not reverse engineer that key when you accepted the Adobe Reader EULA.... --
This means:
Most non-Adobe PDF Readers will not be able to 'fill+save' forms created with Adobe products (they can 'fill+print' them however), unless they may have licensed from Adobe said signature key.
Adobe PDF readers will refuse to 'fill+save' forms created with non-Adobe products (they will 'fill+print' them however).