For example, to achieve the best possible conversion fidelity our product requires InfoPath to be installed on the conversion server. This works great, but in some (mainly externally hosted) environments, this is not always possible. Fortunately the 4.0 version of the PDF Converter for SharePoint now comes with support for converting InfoPath forms to PDF format using InfoPath Forms Services, which is included with the Enterprise version of SharePoint 2007 & 2010.
Update (July 2013): We have noticed that some of our customers are under the impression that what is described in this blog post is the recommended way to convert Forms Services forms. That is not the case, the recommended way is to use our standard InfoPath converter to convert these kind of forms. The HTML Conversion option described in this blog post is merely a last resort if all other options fail. Please contact our support desk at firstname.lastname@example.org if you have any questions.
This can be very useful for some environments, but there are some limitations with this technique:
InfoPath Forms services is required so it doesn’t run on the base WSS3 or SharePoint Foundation versions.
It only works with Forms that are Browser enabled.
Dynamic View Selection and conversion of Attachments features are not available, although it is possible to specify the name of the View to convert.
Our traditional approach that uses InfoPath on the server does not have these limitations.
From Browser based form (left) to PDF Document (right). Click image to open the full PDF file.
Let’s show how to use Form Services in combination with the PDF Converter for SharePoint to convert InfoPath Documents. Some familiarity with both InfoPath and SharePoint is assumed. If you have any questions after reading this then leave a message in the comments section at the end of this post or contact us.
Make sure you have the appropriate privileges to create workflows on a site collection.
Start InfoPath, select Customize a Sample and double click on Sample – Expense Report.
From the File menu select Publish and go through the usual steps to publish the form to a new SharePoint Library named Expenses.
In the new Expenses document library, fill out a form and save it as Form1.xml.
Create a new workflow using SharePoint Designer.
On the Workflow definition screen associate the workflow with the new Expenses list, tick the boxes next to both ‘Automatically start….’ options and proceed to the next screen.
Add the Convert HTML to PDF action, click this url / html and enter the path to your site collection followed by Muhimbi’s InfoPathPrint.aspx page, e.g. http://moss/sites/Finance/_layouts/Muhimbi.PDFConverter/InfoPathPrint.aspx
Don’t close the String Builder dialog yet. Add the xmlLocation querystring parameter, click the Add Lookup button and select the Server Relative URL field for the Current Item. The final result should look like the following screenshot.
Close the String Builder and click the this file option. Assuming we want to write the converted PDF file to the Shared Documents library enter Shared Documents/[%Expenses:Name%].pdf. (Insert the underlined text using the Lookup button. Just typing it in will not work).
Optionally change the orientation of the page to Landscape. There should be no need to specify the username and password as by default the credentials the Document Conversion Service runs under will be used for authentication with the aspx page.
Close the workflow to save and activate it.
Add a new form to, or update an existing one in, the Expenses library. After a few seconds the Workflow Status should change to Completed. Once complete the converted PDF document can be opened from the Shared Documents library.
If your InfoPath form contains multiple views then you can select which view to convert by concatenating &ViewName=your_view_name to the URL of InfoPathPrint.aspx.
In summary, if it is not possible to install InfoPath on the server in your environment, or if your forms look better in Forms Services compared to the full InfoPath client (it does happen), then use the technique described in this post to convert InfoPath documents to PDF format using InfoPath Forms Services.
As always, upgrades are completely free. Don’t hesitate to leave a comment below if you have any questions or contact us to discuss anything related to our products.
As one of the leading vendor in the SharePoint PDF Conversion market, we are frequently asked about how our products can be used to convert a SharePoint List into a PDF file. Up until now we have never had a good answer to this question as we mainly deal with the conversion of Office Documents and InfoPath forms.
OK, let’s get going. In this example we use a simple Tasks list, so open your SharePoint site and create a Tasks lists if one doesn’t already exists.
Next up we need to create a page that displays all items in the list with as little of the SharePoint User Interface around it as possible. We could just use the list’s default view, but that would convert the Quick Launch menu to PDF as well, which doesn’t look very clean. To create a new page without the Quick Launch menu follow these steps:
Navigate to the View All Site Content screen and click the Create button.
In the Web Pages column select Web Part Page.
Name the page PDFTasks.aspx, choose the Full Page, Vertical template and click the Create button.
On the newly created page click Add a Web Part and add the Tasks list.
Click the newly inserted Web Part’s Edit button and select the Modify Shared Web Part option.
Click Edit the current View and select the columns you want to be included in the PDF file. For example % Complete, Due Data, Start Date and Status. Do not close the screen yet.
Under the Item Limit section set the limit to an appropriately large number. We don’t want to page through the data in batches as we want to include all items in the PDF file.
Click OK to save the changes.
Save the page’s URL as we need it later. E.g. http://moss/sites/Management/FormServerTemplates/PDFTasks.aspx.
This new page will be used as the underlying layout of the PDF document. Feel free to modify it further in SharePoint designer / JQuery and remove more parts of the SharePoint user interface. You could also consider creating a minimalistic master page and applying that to the new PDFTasks page.
With the page in place the next thing we need to do is setup the automatic PDF Conversion using a SharePoint Designer workflow. In this example we generate a PDF file whenever the Tasks list is modified. The generated PDF file is stored in the Shared Documents library. Create the workflow as follows:
Make sure you have the appropriate privileges to create workflows on a site collection.
Create a new workflow using SharePoint Designer.
On the Workflow definition screen associate the workflow with the Tasks list, tick the boxes next to both ‘Automatically start….’ options and proceed to the next screen.
Add the Convert HTML to PDF action and click on this url and enter the URL to the page that was created in a previous step, e.g. http://moss/sites/Management/FormServerTemplates/PDFTasks.aspx.
Click this file and enter the path and file name where the PDF file will be generated, e.g. Shared Documents/Tasks.pdf.
Optionally change the generated page’s orientation from Portrait to Landscape.
The user name and password are optional. By default the credentials the Muhimbi Conversion Service runs under will be used to open the web page. For now leave it empty.
Click the Finish button to activate the workflow.
As a test enter one or more tasks. Every time a task is added or updated a PDF file is written to Shared Documents/Tasks.pdf. Open the PDF file to see the results.
In summary, the HTML conversion capability of the new version opens up a whole array of new possibilities. As always, upgrades are completely free. Don’t hesitate to leave a comment below if you have any questions or contact us to discuss anything related to our products.
Being able to select which views to export is very useful as quite often different views are used for exporting a form to PDF. Sometimes using the Print View is good enough, but other times you need to export a different view or multiple views to PDF format. There are even occasions where different views are exported depending on the state of the data entered in the form.
As always, the best way to illustrate this is by example.
Use a special view for exporting to PDF
In this scenario we have an Employee Review form with the following 3 views:
Data entry view: A view used for populating data using the InfoPath client or Forms Services. This is the default view.
Print View: A special view that is optimised for printing to a network laser printer. This is specified as View 1’s Print View.
PDF Export view: A separate view that is used to export the InfoPath form to PDF format as it contains some information that should only show up in exported PDF files.
As View 1 is the default view and View 2 is the Print View for View 1, under normal circumstance the 2nd view is used for exporting to PDF. However, we want to use View 3 for this purpose. We can achieve this by starting the name of View 3 with “_MuhimbiView”. The Muhimbi PDF Converter will automatically detect all views that start with this name, export them all and merge them together into a single PDF file. Naturally these views can be hidden from the end user by marking them as such.
This is a great solution if you know beforehand that you will always be exporting the same view(s) to PDF format.
Determine at runtime which views to export
The previous solution, using view names that start with “_MuhimbiView”, works great. However, sometimes you need to export a different view depending on the state of the data.
For example, our Expense Claim form consists of the following Views:
Data Entry View 1: Used by the employee to report expenses.
Data Entry View 2: Used by the manager to add comments and additional information.
PDF Export View 1: The view that is used to export the form to PDF format before the manager has reviewed the form.
PDF Export View 2: The view that is used to export the form to PDF format after the manager has reviewed the form.
OK, so how are we going to deal with this? Well, here comes the Muhimbi PDF Converter to the rescue! By adding a (hidden) text box named “_MuhimbiViews” (case sensitive and using the default ‘my’ namespace) to any of the views and populating it with the name of one or more comma separated view names, the Muhimbi PDF Converter will automatically pick up these names and export them to PDF format. If multiple views are specified then they are automatically concatenated together.
In addition to adding the “_MuhimbiViews” text field to the form, all the developer of the form needs to do is to add a little bit of logic to the Submit event of the 2 data entry views that specify the correct view name to export in the “_MuhimbiViews” field.
For details about how to dynamically specify which views to convert from your workflow see this post.
View prioritisation rules
To determine which view or views to export, the Muhimbi PDF Converter uses the following prioritisation rules:
Regardless of how a view or views are selected for export, if the selected view has a Print View specified than that view is given priority.
If a field named “_MuhimbiViews” is found anywhere in the InfoPath form then the content of this field is used to determine which views to export.
If the previous field does not exist, is empty or the specified view name does not exist then the converter looks at all view names that start with “_MuhimbiView”.
If none of the previous options apply then the view marked as the Default View is exported.
Do not use Muhimbi’s View selection features in combination with InfoPath's 'Print multiple views' facility. The latter is given priority when converting to PDF.
When the final PDF file is assembled then all selected views are included first, followed by any converted attachments.
Rules when converting to formats other than PDF
As of version 6.0, Muhimbi’s PDF Converter can also convert InfoPath forms to MS-Word, Excel and HTML. There are some exceptions to the way View Selection works for these output formats. For details see this post.
In summary, the new version of the PDF Converter adds flexible View selection features to make the life of InfoPath developers easier. As always, upgrades are completely free. Don’t hesitate to leave a comment below if you have any questions or contact us to discuss anything related to our products.
Please note that this article mentions SharePoint as well as .NET a number of times. Rest assured that, as the PDF Converter Services is Web Services based, it works just as well from Java, C#, Ruby and other web services capable environments.
We anticipate that most of our customers will use this functionality to convert SharePoint pages, including lists, to PDF format. However, rather than displaying a boring old SharePoint site, let’s show how well this works with a real website, in this case one of our landing pages.
The following image shows the original HTML page on the left hand side and the converted PDF file on the right. As you can see this works very well.
Example of the original web page (left) and the converted PDF file (right)
A summary of the new HTML features are as follows. Although this new functionality is available in both the PDF Converter Services as well as the PDF Converter for SharePoint, some of the more SharePoint centric features in the list are obviously exclusive to the SharePoint version.
Built on top of Muhimbi’s rock solid service platform. No need to worry about runaway or orphaned processes. Everything is nicely controlled and scales over multiple CPUs and conversion servers.
Supports conversion by URL as well as manually specified HTML fragments. Ideal for creating PDF based reports using generated HTML tables.
Convert HTML documents stored inside SharePoint document libraries.
Convert SharePoint pages to PDF format from the user’s Personal Actions menu.
Convert web pages to PDF format from SharePoint workflows. Works great in combination with publishing sites.
HTML to PDF Conversion is accessible via the web services based interface as well. Listed below is a simple C# example of how to carry out a conversion from your own code. The code is not complete as it calls into some shared functions from our main C# example to keep things short.
Our existing Java based examples can easily be extended to carry out the same type of conversions. Contact us if you need a hand, we love to help and are very responsive.
/// Simple sample to convert either a URL or HTML code fragment to PDF format
///<param name="htmlOnly">A flag indicating if an HTML Code fragment (true)
In today’s post I will explain the new functionality that allows files attached to InfoPath forms using the File Attachment control to be converted to PDF together with the main InfoPath form. All files will be merged into a single PDF file that contains both the InfoPath form and all attachments.
This all works amazingly, in summary the functionality is as follows:
Automatic attachment conversion is enabled by default. Change the InfoPathConverterFullFidelity.ConvertAttachments setting in the Muhimbi service’s config file to False to disable conversion of attachments.
You don’t need to know anything about the form that is being converted, nor do you need any programming knowledge, this functionality is truly universal. All attachments located on the views that are being converted are automatically picked up, including attachments in Repeating Sections and Repeating Tables. Attachments located on views that are not being converted are automatically skipped.
All document types supported by the Muhimbi PDF Conversion engine are recognised. Files that are not supported are automatically skipped. For a full list of supported file formats see the Specification tab on the main product page.
Naturally attached PDF files are merged in as well, which is great for such attachments as scanned receipts or received faxes.
Do not attempt to attach an InfoPath form inside another form. This will result in an error.
This functionality works hand-in-hand with the new Export Multiple Views functionality that I will outline in an upcoming post.
As all this work is carried out inside Muhimbi’s core conversion engine, any additional conversion settings such as watermarks and security settings are automatically applied to all pages of the combined PDF file.
Convert Expense Reports with attached receipts to a single PDF
So, a very useful new feature that provides powerful new functionality to our customers. As always, upgrades are completely free. Don’t hesitate to leave a comment below if you have any questions or contact us to discuss any of our products.
We get a lot of questions from customers about what happens to hyperlinks in InfoPath documents when the documents are converted to PDF format using the Muhimbi PDF Converter for SharePoint.
We ran the possible combinations through some tests with the following results:
InfoPath TextBox elements with the type set to 'text' become hyperlinks when a URL is entered in it (or at least the PDF Reader navigates to that URL when clicked).
InfoPath TextBox elements with the type set to 'URL' become hyperlinks when a URL is entered in it (or at least the PDF Reader navigates to that URL when clicked).
Entering a URL in an InfoPath Rich Text Box and pressing the Enter key automatically generates a blue hyperlink. When a document containing this link is converted to PDF format then the link can be clicked in the converted document as well.
Entering text in an InfoPath Rich Text Box, selecting it and using the Insert Hyperlink command creates a clickable link in the InfoPath Document. However, after converting this document to PDF format this link is not clickable.
InfoPath Hyperlink Fields are correctly converted and remain hyperlinks in the PDF document.
Due to the manner SharePoint 2010 deals with lookup fields in custom activity validators, any custom code that contains lookup values (e.g. [%Current Item:Transaction Date%]) will not be validated when a workflow is published. We believe this to be a bug in SharePoint 2010 as this works fine in SharePoint 2007.
If this is a big problem for you then consider passing in the lookup field as either parameter 1 or parameter 2 and refer to it using MyWorkflow.Parameter1. For details on how to use the MyWorkflow object in your own code, see the User Guide Series.
Code that does not contain lookup fields is validated properly. Regardless of the scenario, the code does execute correctly.
SharePoint 2007 environments are not affected by this bug.