It is not uncommon that you may need to save the results of a form as a PDF file. In a published form, you can select from the menu:
File/ Export To/ PDF or XPS
Seems simple enough, but here’s a huge caveat:
If you have controls such as check boxes or controls for ink entry (we use tablets to capture electronic signatures,) it can drop data input near the page breaks!!!
This was a very frustrating and aggravating problem, made more so by Microsoft when they said they would not be fixing the problem until InfoPath 2010.
To try this, set up a page of controls and put either check boxes or an ink entry control at the bottom near the page break. Publish the form and then fill in the values. Now print the page. The controls that are close to the page break will have no values when they print out.
To try this, set up a page of controls and put either check boxes or an ink entry control at the bottom near the page break. Publish the form and then fill in the values. Now print the page. The controls that are close to the page break will have no values when they print out.
If you want to do this programmatically and place a button on the form, the following C# code will actually do the same action as the menu command:
string fileNamePDF = @"C:\test.pdf";
this.CurrentView.Export(fileNamePDF, ExportFormat.Pdf);
But this means you will have the same issue with controls too close to the page break.
A second caveat when exporting is that printer drivers may affect the printing.
We ran into an issue where a particular set of print drivers on our clinician tablets, when set as the default printer destination, would actually change the layout of the form.
When exporting to PDF, it enlarged the font on the printed form from what it was in the published form. Our form jumped from 2 pages to 3 pages as a result.
The cascading effect as it turned out was that it pushed controls down next to the page break, dropping the values. These are legal documents signed by patients, so we cannot allow for these values to be dropped.
We ran into an issue where a particular set of print drivers on our clinician tablets, when set as the default printer destination, would actually change the layout of the form.
When exporting to PDF, it enlarged the font on the printed form from what it was in the published form. Our form jumped from 2 pages to 3 pages as a result.
The cascading effect as it turned out was that it pushed controls down next to the page break, dropping the values. These are legal documents signed by patients, so we cannot allow for these values to be dropped.
What a mess.
What we have done is use a third party tool called PDFCreator. It attaches as a printer and when the users select the print functionality, they select the PDFCreator as the destination printer. What’s nice is it does not drop the values in the controls that are near the page break when the published form is printed. Plus we can set properties in the PDFCreator environment so our PDF can automatically go to the printer.
I have no vested interest in PDFCreator as an owner. I am simply a very happy end user.
I have no vested interest in PDFCreator as an owner. I am simply a very happy end user.
***
Another caveat when printing is that that InfoPath uses the Internet Explorer print engine. Some of your text may be altered depending on your IE Zoom setting and Font size.
We have large screens at our scanning stations and someone had changed the font size on IE. When the forms printed out, the font size was smaller than the other scanning station for only one field in our form. It turned out it was the settings in IE.
We have large screens at our scanning stations and someone had changed the font size on IE. When the forms printed out, the font size was smaller than the other scanning station for only one field in our form. It turned out it was the settings in IE.
1. Always have your IE Zoom setting at 100% of screen size.
2. Always have the IE font size setting set to medium
