Hi all! I'm wondering if anybody can shed some lig...
# adobe
m
Hi all! I'm wondering if anybody can shed some light on part of the documentation for `<cfhtmltopdf>`:
Limitation: If you use cfhtmltopdf to convert an HTML page, that contains a form, to PDF, the resultant PDF will not contain the form fields. This is a limitation of the PDFg service, if PDFg is configured to run as a service. If you run PDFg from the command line, then the form fields will work as expected.
Am I understanding correctly that, when rendered as a pdf, the inputs will not contain the #form.value# assigned? The values appear correctly when the pdf is opened in Firefox, but not in Chrome OR Adobe Reader.
e
The metadata for fields is lost in the HTML to PDF conversion from what I have found. The workaround I use is to build a PDF with all the form fields in it, then pass the data you want to populate the pdf with - to the pdf template file. It renders faster than trying to convert an entire webpage into a pdf.
m
But the fields are there when we open the PDF in firefox, so something seems off. I've never worked with a PDF template. Maybe I'm not understanding the "limitation" correctly, but why would the form fields be different than any other cf variable?
maybe it's not the
form
variables that are causing my issue; now I'm seeing many help posts describing how inputs in the rendered PDF are showing up blank until clicked on. 🤦‍♀️
e
Myka, you are correct; it's not the form; it's how the HTML is converted to PDF that breaks something inside the different browsers. Since each browser has taken it upon itself to view pdf files and none of them have all the features Acrobat has, formatting quickly becomes an issue from one browser and browser version to the next.
m
I can understand browsers having differences, but you would think that opening it in ADOBE Acrobat Pro would work as expected.
e
Lol, yeah.. If you want it to work exactly like it should in Adobe Acrobat, design it in Adobe Acrobat, then label each field or label you wanted filled in with some name. Then your code to create the filled out pdf is just cfpdfform action = populate with cfpdfformparam name =x value =Whateveryouwanted"
🤔 1
It gets maddening Here is what I end up doing with far too many of these items. Create the HTML version and print it to pdf in Adobe Acrobat, version 4X (its a print option under extended saving options). Then go back through the PDF, label, and markup every place I need a fillable value. Then make a simple page that takes form data, wraps it against a PDF template, and then outputs that back to the user. 😕
m
Thanks for the idea. My final PDF needs to be static, but it's easiest (AFAIK) to use the same code for the fillable html form and the final document. My other thought is to write a function that will output form inputs in the html version and stylized divs or spans in the PDF.