One of our key principles is that no one is left behind when it comes to our customers and their SharePoint versions. No matter how old your version of SharePoint is, we will continue to support it by making sure every new feature, where feasible, is made available on all SharePoint versions.
When the PDF Converter for SharePoint was first released, SharePoint 2007 was state of the art. Over the years SharePoint 2010 adoption has grown as expected, but a surprising number of organisations still use older SharePoint 2007 versions. We will not leave them behind.
Naturally we have to look at the future as well, so ever since SharePoint 2013 was released our developers have been working flat out to make sure we provide a first class experience, adopt the SharePoint 2013 look and feel and naturally integrate with other 3rd party SharePoint 2013 solutions such as the brilliant Nintex Workflow.
After all this effort I am happy to announce that as of version 7.0 SharePoint 2013 is fully supported. It can be download from the generic download page. The download contains the SP2007, 2010 and 2013 versions, the installer will automatically deploy the correct version for your environment.
Including support for Nintex Workflow is probably one of the best additions we have ever made to our popular PDF Converter for SharePoint. The number of organisations, both large and small, that have come to depend on the combination of these two products is considerable.
Shortly after Nintex released Nintex Workflow for SharePoint 2013 our team started the process of making our existing Nintex Workflow Activities for SharePoint 2007 and 2010 compatible with this new version. As a result we are happy to announce that as of version 7.0 the Muhimbi PDF Converter for SharePoint is compatible with Nintex Workflow 2013. Any workflows created using previous versions of Nintex Workflow will continue to work as expected.
All our workflow activities, including PDF Conversion, Cross Conversion, Watermarking, PDF Securing, PDF Merging and Copying of content types / meta-data are available on the new platform. For details about enabling the PDF Converter’s Nintex Workflow Integration see this Knowledge Base Article.
Nintex Workflow 2013 Workflow Activity for Cross-converting Documents.
We will continue to support SharePoint 2007 and 2010, as well as the versions of Nintex Workflow available for those platforms, for the foreseeable future.
If you have any questions then leave a comment below or contact us directly.
In this article we explain how to use PHP to convert MS-Word, Excel, PowerPoint, HTML and other common file formats to PDF as well as to other formats. Read on to learn more about the Muhimbi PDF Converter and how it can assist with the Conversion, Merging, Watermarking, Splitting, Securing and OCR of documents.
Please note that the example provided in this post requires our software to be deployed to at least one Windows based server in your environment, after which you can access it from PHP using Windows and non-Windows based systems. If this is a problem for your project then please use our REST based cloud service, which requires no custom software deployment. For details see the examples on GitHub .
One of the interesting aspects of developing a platform independent product such as the Muhimbi PDF Converter Services is that you get to deal with many different programming languages and environments. Many of our customers use Java and .NET, but we are seeing an increased interest in PHP, especially from customers with very large, non-Windows, web farms and those using PHP based products such as Drupal, Joomla, WordPress and TYPO3.
We ship a good amount of sample code with the product, but so far our customers have had to figure things out for themselves when using PHP. That all changes today as we now officially provide PHP sample code. Read on for details.
For those not familiar with the product, the Muhimbi PDF Converter Services is a server based SDK that allows software developers to convert and manipulate typical Office files, including MS-Word, Excel, PowerPoint, Visio, Publisher, AutoCAD, HTML, emails and InfoPath, to PDF and other formats using a robust, scalable but friendly Web Services interface from Java, PHP and .NET based solutions.
As you are reading this, you probably already have a running PHP environment. If not, and you are running Windows, then you can install PHP as follows:
Using the Muhimbi PDF Conversion Services in combination with PHP requires a standard installation. If PHP is running on the same system as the Muhimbi PDF Converter Services then you can skip steps 2, 3 and 4.
Open Muhimbi.DocumentConverter.Service.exe.config in your favourite text editor (notepad works as well). A handy shortcut to the configuration / installation folder can be found in the Windows Start Menu Group.
Search for baseAddress and change localhost to the DNS name or IP address of the server running the Conversion Service.
Restart the Conversion Service as follows:
Net stop "Muhimbi Document Converter Service"
Net start "Muhimbi Document Converter Service"
Although out-of-the-box PHP comes with a SoapClient class to interact with web services, it is much easier to pre-generate proxy classes to talk to the web service.
Many tools are available for generating PHP proxies. The one that we are using in this tutorial is wsdl2phpgenerator. Starting with version 7.0 Pre-generated proxies are included in the Muhimbi PDF Converter Services’ Sample Code folder. You can also generate your own proxies using the following steps:
If you are experiencing any problems with our sample code, e.g. warning messages such as Missing argument 1 for OpenOptions then please read the comment dated 15 November, 2013 09:12at the end of this post.
If you cannot make our Windows’ based solution work, please consider our Cloud based REST service, which requires no deployment of Windows software.
SOAP / Web Service Debugging
The Muhimbi Conversion Service is a Windows Service based on the Microsoft Windows Communication Foundation (WCF) framework. This comprehensive framework is used to expose a standards based Web Services interface that can be consumed by many different platforms including .NET, Java, PHP, SAP, Documentum and many others.
Even though WCF Web Services are standards based, standards are not interpreted the same by everyone so from time to time you may need to do some troubleshooting when programming against the PDF Converter Web Service, especially from non-Microsoft platforms.
Unlike setting the PDF Viewer Preferences, the facilities described in this post require a license for the PDF Converter Professional, an add-on license for the PDF Converter Services and PDF Converter for SharePoint.
The following Post Processing settings are available in the new OutputFormatSpecificSettings_PDF class:
FastWebView: Enable Fast Web View / Linearization to optimize the PDF for output on the web.
EmbedAllFonts: Embed all fonts into the PDF. Certain fonts may not allow embedding and will therefore never be embedded. Specifying ‘false’ will remove all fonts from the PDF.
SubsetFonts: Specify if font-subsetting is enabled or not. Font subsetting embeds only those characters that are used in a document, instead of the entire font. This reduces the size of a PDF file that contains embedded fonts, but may make future content changes problematic.
You can send these settings to the web service by passing a reference to an instance of OutputFormatSpecificSettings_PDF to the ConversionSettings.OutputFormatSpecificSettings (or MergeSettings.OutputFormatSpecificSettings) property. For details see the following class diagram.
Post processing is enabled by setting the OutputFormatSpecificSettings_PDF.PostProcessFile property to true. Please make sure that the Ghostscript prerequisite is installed and configured as described in this Knowledge Base Article. In order to make use of FastWebView Ghostscript 9.07 or newer will need to be installed.
When Post processing is enabled the PDF Profile / Version specified in ConversionSettings.PDFProfile will automatically be applied to the output file. This includes downgrading the content of the PDF where necessary.
As of Version 7.0 the PDFProfile property supports the following PDF Versions and Profiles:
Default: Use whatever PDF version comes out of the underlying converter / source PDF file.
PDF_A1B: Use the PDF/A1b standard for long term archiving.
PDF_A2B: Use the PDF/A2b standard for long term archiving.
PDF_1_1: PDF 1.1 output (Compatible with Acrobat 2.0 (1994) and later).
PDF_1_2: PDF 1.2 output (Compatible with Acrobat 3.0 (1996) and later).
PDF_1_3: PDF 1.3 output (Compatible with Acrobat 4.0 (2000) and later).
PDF_1_4: PDF 1.4 output (Compatible with Acrobat 5.0 (2001) and later).
PDF_1_5: Use PDF Version 1.5. For legacy reasons, out-of-the-box this is treated the same as 'Default', but post processing to 1.5 can be forced using the Config Value "PDF.PostProcessPDF1.5". When post processing is enabled the PDF file will be made compatible with PDF 1.5 (Compatible with Acrobat 6.0 (2003) and later).
PDF_1_6: PDF 1.6 output (Compatible with Acrobat 7.0 (2005) and later).
PDF_1_7: PDF 1.7 output (Compatible with Acrobat 8.0 (2006) and later).
Please note that when FastWebView or PDF/A is enabled you cannot specify any PDF Security settings.
If you are developing in Java then please use Axis2 (example) as wsimport (example) does not deal well with web service properties that derive from a common base class (You need to jump through a lot of hoops, seriously, don’t use wsimport in this case).
If you have any questions then leave a comment below or contact us.
Viewer Preferences are hints for the application that is used to view the PDF file, e.g. Adobe Acrobat. These hints are embedded in the PDF file and control such things as the visibility of the Menu and Toolbars, the various panels such as Bookmarks / Attachments, or even viewing the PDF in full screen mode. Please be aware that these are merely hints and not every PDF Reader supports all of them.
The following Viewer Preferences are supported by the Muhimbi PDF Converter:
CenterWindow: Position the document window in the center of the screen.
DisplayTitle: Display the Document Title in the PDF Reader's window.
FitWindow: Resize the PDF Viewer's window to fit the size of the first page.
HideMenubar: Hide the PDF viewer's menu bar.
HideToolbar: Hide the PDF viewer's tool bars.
HideWindowUI: Hide the user interface elements in the document windows and only display the document's content.
PageLayout: The page layout to use for the document.
NavigationPane: The navigation pane to display when the document is opened.
HideEmptyNavigationPane: If there is no content in the pane then hide it. E.g. when the bookmarks (Outlines) pane is selected, but there are no bookmarks defined, then the pane is hidden.
PageScalingMode: Default scaling option when printing the document.
FullScreen: Display the PDF in full screen mode.
At Muhimbi we pride ourselves at going the extra mile so we have implemented a flag that we believe to be unique, HideEmptyNavigationPane checks if any bookmarks or attachments are present and hide those panes if there is no content. This prevents a cluttered user interface when end users view your PDFs.
Viewer Preferences can currently only be specified when using the Web Services interface by setting ConversionSettings. OutputFormatSpecificSettings (or MergeSettings.OutputFormatSpecificSettings) to an instance of OutputFormatSpecificSettings_PDF and populating the ViewerPreferences property. Confused? Here is a class diagram.
If you are developing in Java then please use Axis2 (example) as wsimport (example) does not deal well with web service properties that derive from a common base class. (You need to jump through a lot of hoops, seriously, don’t use wsimport in this case).
If you have any questions then leave a comment below or contact us.