I have a business with about 50 clients. SO much of my time is wasted filling out the same paper forms by hand over and over again. It'd be nice if there was a way to auto-populate these forms with data I have in my client database. But I have no idea on how to go about implementing this. The data is in FoxPro. I forms I guess I would just scan in and turn them into images. Is there a program or a way anyone knows of to write text over images in some automated fashion?
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations sizbut on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Autopopulate scanned PDFs with data in database
- Thread starter sweetcow
- Start date
You could set up a report format with an image field and a text field that references a cursor with 1 memo field that you load with the data fields in text format. You would have to set the font for the text field to something like Courier so that you can calculate where the text is going to print within the memo field. You would then bring the text field to the front of the image field so that it overlays the image.
The courier font is monotype size so you can load the text memo field with the form lines data....
I've used this technique to overlay plan dimensions over the plan image (blueprint/drawing)
Andy Snyder
SnyAc Software Services Hyperware Inc.
AmTech Software Inc.
The courier font is monotype size so you can load the text memo field with the form lines data....
I've used this technique to overlay plan dimensions over the plan image (blueprint/drawing)
Andy Snyder
SnyAc Software Services Hyperware Inc.
AmTech Software Inc.
Olaf Doschke
Programmer
The ideal solution is you would not have paper forms but PDF Forms, which can be manually and electronically filled. VFP would then need a PDF suite capable to support this PDF feature, a PDF printer would not be sufficient, but here are libraries, eg Amyuni, that can make this feature available for VFP.
Bye, Olaf.
Bye, Olaf.
Olaf - "a PDF printer would not be sufficient"
I don't know why you say that.
On a daily basis we generate over 100 PDF forms using a VFP application to write data into a VFP Report Form and utilizes a PDF 'Printer' for the final output.
The only 'trick' is to find a PDF print driver which allows you to either pass parameters to it (example: an ActiveX) or, in our case, allows the 'printer' to be pre-configured as to where to output the resultant PDF file and what to name it.
This 2nd option is preferable to us in that it allows the VFP application to 'know' what the resultant file is named and where it 'lives'. In that way after creating the resultant PDF document, it can then move the file to the intended final destination and rename it along the way (if necessary).
Sweetcow - Good Luck
JRB-Bldr
I don't know why you say that.
On a daily basis we generate over 100 PDF forms using a VFP application to write data into a VFP Report Form and utilizes a PDF 'Printer' for the final output.
The only 'trick' is to find a PDF print driver which allows you to either pass parameters to it (example: an ActiveX) or, in our case, allows the 'printer' to be pre-configured as to where to output the resultant PDF file and what to name it.
This 2nd option is preferable to us in that it allows the VFP application to 'know' what the resultant file is named and where it 'lives'. In that way after creating the resultant PDF document, it can then move the file to the intended final destination and rename it along the way (if necessary).
Sweetcow - Good Luck
JRB-Bldr
Olaf Doschke
Programmer
JRB-Bldr,
any PDF printer will just do that - print PDFs, make output PDF files.
PDF _Forms_ are PDF files, which will have an niput interface for the user to manually fill in values in sections of the PDF. And you can do so programmatically too, but you need a library that can work with such PDF forms as input files.
Take a look here for example:
They offer a sample PDF Form here:
The difference of this kind of PDF is the smae as the difference of some static HTML with empty areas you can print and then fill in compared to HTML containing a HTML form, which you can input into within the browser.
And such PDF Files can not only be manually filled in, you can automate that process and fill in data from a database, then need no OCR or that kind of processes.
Bye, Olaf.
any PDF printer will just do that - print PDFs, make output PDF files.
PDF _Forms_ are PDF files, which will have an niput interface for the user to manually fill in values in sections of the PDF. And you can do so programmatically too, but you need a library that can work with such PDF forms as input files.
Take a look here for example:
They offer a sample PDF Form here:
The difference of this kind of PDF is the smae as the difference of some static HTML with empty areas you can print and then fill in compared to HTML containing a HTML form, which you can input into within the browser.
And such PDF Files can not only be manually filled in, you can automate that process and fill in data from a database, then need no OCR or that kind of processes.
Bye, Olaf.
Olaf - I missed the PDF Forms and read it as PDF "document".
In fact I am not sure why they would need to use a PDF Form at all.
They could quite easily create a VFP Report Form which displayed the data in the desired manner and then merely printed it out to the PDF 'printer' as a PDF document.
Sweetcow - Good Luck
JRB-Bldr
In fact I am not sure why they would need to use a PDF Form at all.
They could quite easily create a VFP Report Form which displayed the data in the desired manner and then merely printed it out to the PDF 'printer' as a PDF document.
Sweetcow - Good Luck
JRB-Bldr
Olaf Doschke
Programmer
Well, if sweetcow can convert the paper forms to PDF Forms, then there would be no need to merge data into images. It depends on what is done with the hand filled forms, if the OP could replace the paper forms by the resulting filled in PDF files or needs to print them out.
Anyway it's surely easier to fill in a PDF form, than to merge data into a scenned in image of the empty paper form and it would be much more selfcontained and sophisticated. If the layout changes, I'd say a PDF form is easier to adjust.
Bye, Olaf.
Anyway it's surely easier to fill in a PDF form, than to merge data into a scenned in image of the empty paper form and it would be much more selfcontained and sophisticated. If the layout changes, I'd say a PDF form is easier to adjust.
Bye, Olaf.
- Thread starter
- #8
Stella740pl
Programmer
What is the final output that you need, a paper printout or a PDF document?
I agree with JRB-Bldr here, there is no need for PDF forms here if you already have a VFP database (while it might be nice to have them, depending on what you need/want at the end).
You can set up a report form that would look just like the form you need to populate; no need to scan it, just recreate it with what FoxPro has, and you can populate it with data from the database quite easily. You might want to also create a screen form to gather additional information, if you need to, before calling a report.
Then either print out your filled form straight from VFP onto the paper, or to PDF document, using a Distiller or some other PDF printer driver.
- Status
Similar threads
