When we create or update our popular range of PDF converters, we don't just phone it in, we talk to our customers and really go the extra mile to make sure that our software works exactly how they want it to work.
Let's take the topic of attachments as an example. For many years we have supported various file formats that may contain attachments, for example emails, InfoPath forms, and PDF files containing attached files. Historically, before release 10.0, we provided two options to deal with these attachments.
Convert all attachments to PDF, and merge them to the output PDF.
Or ignore all attachments.
This served most of our customers well, but from time to time our support desk reported 'annoying customers who wanted something not supported by the product', specifically in the area of how our software deals with attachments. We don't like to disappoint our customers - which is why we get such great reviews - so as of version 10.0 of the Muhimbi PDF Converter for SharePoint (on premise), Muhimbi PDF Converter Services, and the Muhimbi PDF Converter Online, the following facilities are available to deal with attachments.
Convert attachments to PDF, and merge them - alongside the main document - into a single PDF (Legacy behaviour).
Convert attachments to PDF, but store them in the main PDF output file as PDF attachments.
Convert the main file to PDF, but store the attachments in their original format in the PDF.
Control how unsupported or corrupt attachments are dealt with, either fail the entire conversion, ignore the attachments, or store the attachment in its original file format in the output PDF.
Control how small images are filtered out of emails. Emails tend to have loads of small attachments (twitter logo, company logos etc). As of version 10.0 the converter filters out any image based attachments (excluding TIFFs) that are smaller than 150 pixels in width or height.
To illustrate how this functionality can be used in the real world, have a look at the following video created by our Clavin. He uses MS-Flow - but it works the same for our other supported platforms - to convert emails to PDF and control how the attachments are processed.
As our software is very flexible, this new behaviour can be controlled via several mechanisms. Details can be found below.
Conversion Service's Config file
The conversion service's behaviour can be controlled globally via its config file. Any changes made here apply to all operations unless overridden at the individual request level. For details about where to find, and how to edit, this config file, see this Knowledge Base article.
The relevant config settings are as follows:
For PDF source files containing attachments
<!-- Convert, and merge, files that are attached to the PDF? --><addkey="PDF.ConvertAttachments"value="False"/><!-- What to do with attachments after conversion (Only used when PDF.ConvertAttachments is enabled). * RemoveAll - Convert and delete all files attached to the PDF, even file formats not supported by the converter. * RemoveSupported - Convert and delete all files supported by the PDF converter, but leave unsupported files attached. --><addkey="PDF.ConvertAttachmentMode"value="RemoveAll"/><!-- How to deal with the automatic generation of 'Named Destinations' using the PDF's Bookmarks. The default value is 'None'. * None - Make no change to the named destinations defined in the document. * ClearAll - Remove all named destinations. (All bookmarks pointing to existing named destinations will be fixed up
automatically) * Merge - Keep existing named destinations and add new ones based on the PDF's bookmarks. * Replace - Remove all existing named destinations and add new ones based on the PDF's bookmarks. --><!-- How to deal with attachments if the source PDF contains any. * Default - Legacy behaviour, attachments are converted to PDF and merged into the main PDF.
See PDF.ConvertAttachments and PDF.ConvertAttachmentMode. * Merge - Supported attachments are merged to the output PDF. Unsupported attachments are handled according to PDF.UnsupportedAttachmentBehaviour. * AttachAsPDF - Supported attachments are converted into PDF and attached to the output document. Unsupported attachments are handled according to PDF.UnsupportedAttachmentBehaviour. * AttachOriginal - All attachments are attached to the output document in their original format --><addkey="PDF.AttachmentMergeMode"value=""/><!-- What to do with unsupported attachments (for PDF.AttachmentMergeMode = 'Merge' or 'AttachAsPDF').
The default value is 'Error' * Error - An error is raised when unsupported attachments are found. * Remove - The unsupported attachments are ignored and not included in the output file. * AttachOriginal - Unsupported attachments are attached in their original format. --><addkey="PDF.UnsupportedAttachmentBehaviour"value=""/><!-- If 'true' then merging the attachments will return an error message in case any error occurs. If 'false' then error pages are added to the output document --><addkey="PDF.BreakMergeOnError"value=""/><!-- Control which attachment types to include. Specify either an empty value to include all or specify values in a comma separated list using standard wildcard expressions (e.g. *.docx, tmp???.xls).--><addkey="PDF.IncludeAttachmentTypes"value=""/><!-- Control which attachment types to exclude. Specify either an empty value to exclude all or specify values in a comma separated list using standard wildcard expressions (e.g. *.docx, tmp???.xls).--><addkey="PDF.ExcludeAttachmentTypes"value=""/>
For InfoPath forms containing attachments
<!-- Enable or disable the conversion of Infopath attachments. --><addkey="InfoPathConverterFullFidelity.ConvertAttachments"value="true"/><!-- How to deal with attachments if the source InfoPath file contains any. * Default - Legacy behaviour. If InfoPathConverterFullFidelity.ConvertAttachments is true then attachments are merged into the output file and unsupported attachments are removed * Merge - Supported attachments are merged to the output PDF. Unsupported attachments are handled according to
InfoPathConverterFullFidelity.UnsupportedAttachmentBehaviour * AttachAsPDF - Supported attachments are converted into PDF and attached to the output document. Unsupported attachments are handled according to
InfoPathConverterFullFidelity.UnsupportedAttachmentBehaviour * AttachOriginal - All attachments are attached to the output document in their original format --><addkey="InfoPathConverterFullFidelity.AttachmentMergeMode"value=""/><!-- What to do with unsupported attachments (for InfoPathConverterFullFidelity.AttachmentMergeMode = 'Merge' or 'AttachAsPDF'). The default value is 'Error' * Error - An error is raised when unsupported attachments are found. * Remove - The unsupported attachments are ignored and not included in the output. * AttachOriginal - Unsupported attachments are attached in their original format. --><addkey="InfoPathConverterFullFidelity.UnsupportedAttachmentBehaviour"value=""/><!-- If 'true' then merging the attachments will return an error message in case any error occurs. If 'false' then error pages are added to the output document --><addkey="InfoPathConverterFullFidelity.BreakMergeOnError"value=""/><!-- Control which attachment types to include. Specify either an empty value to include all or specify values in a comma separated list using standard wildcard expressions (e.g. *.docx, tmp???.xls).--><addkey="InfoPathConverterFullFidelity.IncludeAttachmentTypes"value=""/><!-- Control which attachment types to exclude. Specify either an empty value to exclude all or specify values in a comma separated list using standard wildcard expressions (e.g. *.docx, tmp???.xls).--><addkey="InfoPathConverterFullFidelity.ExcludeAttachmentTypes"value=""/>
For Emails containing attachments
<!-- The default value for converting attachments. --><addkey="MSGConverterFullFidelity.ConvertAttachments"value="True"/><!-- Specify whether the attachment filenames are displayed in the email header. This setting works independently from ConvertAttachments. --><addkey="MSGConverterFullFidelity.DisplayAttachmentSummary"value="True"/><!-- How to deal with attachments if the source email contains any. * Default - Legacy behaviour, attachments are converted to PDF and merged into the main PDF. See MSGConverterFullFidelity.ConvertAttachments and MSGConverterFullFidelity.BreakOnUnsupportedAttachment * Merge - Supported attachments are merged to the output PDF. Unsupported attachments are handled according to MSGConverterFullFidelity.UnsupportedAttachmentBehaviour * AttachAsPDF - Supported attachments are converted into PDF and attached to the output document. Unsupported attachments are handled according to MSGConverterFullFidelity.UnsupportedAttachmentBehaviour * AttachOriginal - All attachments are attached to the output document in their original format --><addkey="MSGConverterFullFidelity.AttachmentMergeMode"value=""/><!-- What to do with unsupported attachments (for MSGConverterFullFidelity.AttachmentMergeMode = 'Merge' or 'AttachAsPDF'). The default value is 'Error' * Error - An error is raised if unsupported attachments are found. * Remove - The unsupported attachments are ignored and not included in the output. * AttachOriginal - Unsupported attachments are attached in their original format. --><addkey="MSGConverterFullFidelity.UnsupportedAttachmentBehaviour"value=""/><!-- If 'true' then merging the attachments will return an error message in case any error occurs. If 'false' then error pages are added to the output document --><addkey="MSGConverterFullFidelity.BreakMergeOnError"value=""/><!-- Control which attachment types to include. Specify either an empty value to include all or specify values in a comma separated list using standard wildcard expressions (e.g. *.docx, tmp???.xls).--><addkey="MSGConverterFullFidelity.IncludeAttachmentTypes"value=""/><!-- Control which attachment types to exclude. Specify either an empty value to exclude all or specify values in a comma separated list using standard wildcard expressions (e.g. *.docx, tmp???.xls).--><addkey="MSGConverterFullFidelity.ExcludeAttachmentTypes"value=""/>
XML override
For Nintex Workflow, SharePoint Designer workflows, Microsoft Flow and REST API requests, it is possible to specify Muhimbi's XML override syntax on a request by request basis. As it is not feasible to have a a switch in our user interface for every imaginable tweak or setting, we allow settings to be passed in via XML.
It is this technique that is used in the video in the introduction of this post. There are literally hundreds of settings, exact details can be found in the Developer Guide.
An example, to control the conversion of email attachments during PDF Conversion, is as follows:
The on-premise version of the Muhimbi PDF Converter comes with a rich SOAP based web service, as well as plenty of sample code. For details see our GitHub repository.
The object model, classes and properties can be found in the Developer Guide.
One of the more popular features of our range of on-premise and Online PDF Converters, is the ability to automatically apply all kind of watermarks (stamps), including text, images, shapes and even QR codes. This is super popular with our customers, but one important type of watermark was missing, regular – old fashioned – barcodes.
Guess what we added in version 10.0 of to the Muhimbi PDF Converter for SharePoint Online, Muhimbi PDF Converter Services Online, and our on-premise solutions? You guessed it right… BARCODES. Loads of them Codabar, Code 11, Code 32, Code 39, Code 93, Code 128 (A/B/C), GS1-128, and QR Code, with more to come.
If you are reading this, you already know why barcodes can be extremely useful. You are probably familiar with barcodes when purchasing products in the supermarket. I still remember the time before barcode readers and let just say that the checkout experience at the supermarket was less than pleasant. But it is not just that, barcodes control how your luggage is routed when travelling, provide you with access to events, tracks lab samples, and – most importantly for our particular customers - Document Management and archiving.
Similar to all other functionality offered by our product line, being it document conversion, file merging, watermarking, applying security or OCR, this new barcode facility is accessible from all supported platforms and technologies:
SharePoint Designer Workflows (on-premise and Online)
Regardless of the platform, all SharePoint Designer workflows pretty much look and behave the same, so the following example is the same for SharePoint on-premise, Online, the SP2010 workflow Engine and the 2013 one.
The workflow action name is 'Add Linear Barcode Watermark to PDF'
Nintex Workflow
In Nintex Workflow, the barcode facility is integrated in the generic 'Watermark PDF' Nintex action. Just select the 'Linear Barcode' watermarks type and fill in the blanks. Make sure you enable the Muhimbi Nintex actions first.
Microsoft Flow (Power Automate) / Azure Logic Apps
Similar to Muhimbi's other Flow actions, there is no need to install any software. Just insert a new action in the flow and type 'Muhimbi Watermark' to surface all our watermarking facilities.
Don't be put off by the sheer number of options in the screenshot below. Most are hidden by default unless the 'Show advanced options' link is clicked. A great tutorial can be found here.
Watermark on open / XML Watermarks
Muhimbi's SharePoint products come with this awesome facility to automatically add watermarks when files are opened (See SharePoint on-premise and SharePoint Online details). As this new barcode facility behaves just like any other watermark, barcodes can now be added using our real-time watermarking facility as well.
Similar to Muhimbi's other Online facilities, the barcode watermark is also available via a REST API call. You can find details about the various actions in the API Docs. The on-premise versions of the product supports the same functionality using the built-in SOAP Webservice interface.
In the following example we use Curl to make a POST request. Note how we are passing in the source PDF file using the base64 command (Ours is called test.pdf). The output JSON is fed into the jq command (sudo apt install jq), which extracts the output file. This output file - which is Base64 encoded - is then decoded into a binary PDF file.
REST calls can be executed via most modern programming languages, including Python, Java, JavaScript, C#, and PHP. Various examples can be found in our GitHub repository.
When executing this command using Bash, or a similar shell, you may want to copy it into a text editor first. Then make sure all line endings are saved using the Unix format (LF).
Parameters
Although the syntax is slightly different depending on the platform / situation, they all support the same parameters. Everything is largely self-describing, but the key ones are described below:
Type: The barcode type including Codabar, Code11, Code32, Code39, Code39Extended, Code93, Code93Extended, Code128, Code128A, Code128B, Code128C, GS1Code128.
Content: The content for the barcode, please make sure that the specified content is compatible with the data that may be stored in the selected barcode type.
Check digit: If relevant to the barcode type, calculate and encode the check digit into the barcode.
Even though this is a pretty long blog post, it only scratches the surface of this powerful new barcode facility. Any questions? Leave a comment below or contact our support desk, we love to help.
When I recently wrote the 10 years of Muhimbi article, it gave me the opportunity to reflect on how we communicate about our products and services. We tend to focus on the hard-core technical facilities such as the ability to Convert, Merge, Watermarks, Secure and OCR files, which resonates well with our technical audience, but this doesn't answer the question of WHY you would need such functionality.
Fortunately, they let us out from time to time, especially when we go to trade shows, which is always enlightening as we get to talk to people, for real, like in face-to-face. It is at times like this that we find out what people really use our software for. Naturally our products and services are also used in the most obscure scenarios that we could never even dream of, but for the vast majority of the customers the same handful of scenarios are mentioned time and again. We have summarised these scenarios below.
Generating meeting and board packs
Although some organisations fully automate this as part of a larger workflow, many customers use our standard user interface for merging files to generate meeting or board packs. The reason for generating these packs is easy to understand. Typical meetings require a Word, Excel and PowerPoint file to be distributed to attendees. As we are no longer living in the 20th century, people want to consume these documents digitally. Up until a couple of years ago this usually meant reading the documents on a Windows based laptop, but times have moved on and people use all kind of devices including tablets, Chromebooks, and even mobile phones.
These devices all have their own strengths, but other than Windows Laptops, they tend to display Office (and other file formats) in a way that is usually a bit - and sometimes a lot - different from the way the original author intended. The only way to guarantee that the documents are displayed in exactly the same way as intended, is to convert them to PDF, and distribute everything as a single file.
Traditionally, organisations have used complex, desktop based, PDF editors for this purpose, the likes of Adobe Acrobat. This software is not particularly easy - or quick - to use and tends to end up being quite expensive if it needs to be rolled out to more than a handful of people in an organisation. It doesn't help that these meeting documents are often changed just before the meeting starts, resulting in a last-minute rush, causing all kinds of nasty errors.
Although never intended to be used specifically for this kind of scenario, Muhimbi's range of PDF Conversion products, and particularly the SharePoint versions, provides an excellent solution to create meeting packs. It requires no training, does an excellent job when converting and merging files into a single PDF, and can do so in either an automated fashion - via workflows - or simply via the SharePoint user interface. The results look perfect, on any device.
Watermarking and securing files downloaded from SharePoint
Another common scenario we hear about is watermarking, and securing, PDF files in real-time the moment they are downloaded. It doesn't really surprise me that this is popular, as we built this facility based on real-world customers asking for this exact functionality.
It is used for all kind of reasons and scenarios, but we see it most commonly used as a DRM light solution. What we mean with this is that a full-blown DRM solution (a.k.a IRM / RMS / AIP) tends to be difficult to implement and roll-out, and - no matter how powerful - has all kind of nasty side effects. What organisations need is something that is good enough, and in our case good enough means embedding the user's name, IP address and timestamp in a PDF the moment the file is downloaded from SharePoint.
Some organisations visibly display this information in the downloaded PDFs as a deterrent to prevent 'sharing' of sensitive or valuable documents. Others embed the same information in an invisible manner leaving it as a surprise - for people who 'misplaced' a document - for the yearly performance review.
We provide a lot of functionality out-of-the-box; workflows, watermarking, merging, security, OCR, but quite often people just need to take a source document, being it in Word, Excel, PowerPoint, MSG, AutoCAD, Image, or HTML format, and turn it into a PDF as that is just so much easier to share via email, websites or other medium.
Our customers especially appreciate the ability to easily turn almost any document into a PDF when it comes to Freedom Of Information requests. You cannot just distribute emails in their original MSG format, or share InfoPath forms as a combination of XML and XSN files. Not only is PDF the perfect file format for these kinds of requests, it also strips out personal information and other metadata.
Fortunately our software supports most file formats used in office environments.
Archiving files
In the Enterprise Document and Content management market we operate in, each document typically goes through a life cycle. A document is created by a person or group of people, the document is then reviewed by a manager and ultimately - if you are lucky - approved.
While a document moves through these various stages, in the background an automated workflow process organises the entire process. Emails and other notifications are sent out when certain stages are reached, people are asked to take action, reminders are sent out etc.
One of the final steps in the process is usually to take the document, regardless of the source file format, convert it to PDF, add a watermark to include status as well as other metadata associated with the document (who approved it, value, category, priority etc), and write the PDF to a records centre or other archive.
Our range of PDF Conversion products come with a set of building blocks that workflow designers can insert in whatever part of their business process they want to. We don't force a certain methodology or process upon you, just use our facilities as you see fit.
When we sit down and write the specification for whatever amazing new feature we are planning next, we always envisage these massive and complex enterprise level workflows that our software participates in. However, more often than not, the workflow only contains 2 steps
Step 1: Has the document been approved?
Step 2: Convert it to PDF.
Step 3: There is no step 3.
Keep in mind that various regulatory bodies specify standards for archiving files. More often than not the exact PDF version to use is PDF/A. Our software supports this sub-standard, one less thing to worry about.
Converting InfoPath forms
As the only serious player in the InfoPath to PDF conversion market, it doesn't surprise us that many organisations use our software to convert InfoPath forms to PDF.
InfoPath is a particularly tricky format that makes it nearly impossible to share forms with someone outside the organisation, and often even inside the organisation. In the right hands InfoPath is an excellent solution, but in many cases.... oh well, let's not dwell on that.
As so many organisations come to us to convert InfoPath forms to PDF, over the years we have added all the bells and whistles you can imagine. We even make it possible to convert files that are attached to InfoPath forms, and provide full control over which views to convert as well as which views NOT to convert.
Similar to the Archiving topic discussed above, InfoPath to PDF conversions are usually coupled with very simple workflows. Once a form reaches a certain status, e.g. approved, automatically convert it to PDF, apply a watermark as well as PDF security, then write it to an archive.
Build random stuff using workflows
As mentioned previously, most workflows that our components participate in are very basic and contain only a handful of steps. However, as the topic of automating processes using workflows is so important to our customers, we have really gone the extra mile and added support for most of the popular workflow platforms.
Why use workflows? Well there are as many reasons as there are organisations, but the key reason I always mention is the ability to automate processes and take the human error factor out of the equation. Even for the most basic workflows, including the simple 2 steps flows mentioned previously, you cannot trust humans to always get it 100% right, not even for the most disciplined teams.
Time and again we see situations where, for that last-minute change, a crucial step was forgotten, or the wrong output folder was picked. ONLY by automating business processes using workflows can you guarantee that the same steps are always carried out without fail.
Any questions on these topics, or anything else? Contact us, we love to help.
Posted at: 18:16 on 22 March 2019 by David Radford
This article is based on a post Clavin Fernandes made to his personal blog, the information in it is used with his permission. Thank you Clavin!
Ever since Microsoft announced the retirement of InfoPath, people responsible for archiving forms and maintaining their accessibility have been busy searching for alternatives to InfoPath.
Luckily, we’ve been busy with this as well! So, we started with a previous post and decided to update it here using some of the new functionality available with Microsoft Flow.
Using Flow to convert and archive InfoPath forms is a bit more involved than doing the same in SharePoint, as InfoPath uses two files to create a single form, an XML (data) file and an XSN (template) file. In this post we will create a simple Flow that is triggered whenever a form is added to a folder in a SharePoint Online Library. Once added, the form is automatically converted to a PDF stored in a OneDrive for Business folder.
This is just an example, it can easily be adjusted to use different file services (e.g. the trigger can be for files uploaded to OneDrive, Box.com, DropBox, Google Drive or can even be used to Migrate your SharePoint On-Premise InfoPath Forms to SharePoint Online etc).
Make sure you have the appropriate privileges to create Flows.
Create the Flow
From a high-level perspective, the Flow looks as follows:
Note: Converting an InfoPath form is similar to converting any other document type using Muhimbi's Flow Actions, but - as it is needed during conversion - you need to pass in the XSN file (the file content, not the URL to the file) alongside the XML file.
The Flow consists of the following elements:
Trigger - When a file is created in a folder: Specify the path to the SharePoint Online folder to monitor for new files. (To trigger a Flow for files created anywhere in a Library, use the ‘When a file is created (properties only)’ trigger, and retrieve its content using Get file content.)
Get file content: Specify the path to the SharePoint Online location where the XSN has been published to. (By default it is stored in the Forms Folder, e.g. “https://yourdomain.sharepoint.com/sites/Sitecollectionname/Library/Forms/template.xsn“
Convert document: Insert the Muhimbi PDF Convert Document action, and fill it out as follows. (see the screenshot below for details):
• Source file name: “File name” the output from the “When a file is created in a folder” trigger. • Source file content: “File Content” the output of the “When a file is created in a folder” trigger. • Output format: PDF • Template file: “File Content” the output of the “Get file content” action, which contains the InfoPath XSN file. Do not just pass the path to the XSN file into the Muhimbi Action as it doesn’t have the privileges to read that file.
Create file: Specify the path to the OneDrive folder where the converted PDF files are written to. Pass in the 'Base file name' field returned by the Convert Document action, making sure that it is suffixed with '.pdf'. In the 'File content' field pass in the 'Processed file content' returned by the Convert document action.
Voila- You’re finished! Now, publish the Flow and then save an InfoPath form in the SharePoint Online folder to test the Flow. After a few moments a PDF file will appear in the OneDrive destination folder.
When we launched the first Online version of our software in 2015, we included a completely free trial, but that is intended for evaluation purposes only. Over the years we have been approached by many companies and individuals, including charities, non-profits, and very small organisations, for which ANY price, even US$ 5 let alone our most economical US$ 99 subscription. is completely out of the question.
We pride ourselves on affordable pricing across all our product lines, but we never had a completely free offering. As we want to make our service available to the largest possible audience, we have decided to introduce a free subscription tier.
This Free subscription comes with no strings attached, other than having to notify us once a year if you wish to extend. Naturally there are some limitations; free operations are limited to 50 per month, input file types are restricted to Word, Excel, PowerPoint, HTML, TIFF, JPG, GIF, BMP, PNG, and the maximum file size per operation is 2MB. In order get access to OCR, PDF/A output as well as further file formats such as Visio, AutoCAD, MSG, EML and InfoPath, customers will need to switch to one of the commercial subscription tiers.
How to get the Free subscription? Just start using our software by installing the SharePoint Online app, or creating an account for the PDF Converter Online, and select the 'Free' option when asked. Please do not use the Free subscription for evaluating the software with the intention to purchase, for that purpose you should choose the Trial option as it provides an experience that is more similar to the commercial subscription tiers. For the difference between the Free and Trial subscription tiers see this Knowledge Base article.
Over the past 10 years, we have always made it a habit to listen to our customers, especially when kicking off the development of a new release. Once you receive a request, or bug, more than once, you'd better do something about it.
However, during the last 3 to 4 years things have changed. Naturally we still listen to our customers, but Muhimbi is now its own biggest customer. What!?
Indeed, to the best of our knowledge, no one carries out more operations in a real-word production environment than we do in-house. Why is this? Well, our popular cloud based services, the Muhimbi PDF Converter for SharePoint Online, and the Muhimbi PDF Converter Services Online, use the exact same engine that we ship alongside our on-premise products.
Because our Online customers fully depend on us, our data centres and our software, the responsibility to keep things up and running has shifted from our customers' IT departments, to our own operations team. Although our products have always been very stable and scalable, there were plenty of minor hiccups that we did not know about because it wasn't too much of a problem to our customers. However, when you run your own software at a very VERY large scale then all small things add up.
To cut a long story short, we monitor our online services like a hawk. Each and every issue, no matter how big or small, is recorded and analysed. If we can help it, we fix it. As a result we have improved and fixed dozens of issues in the new 8.4 release of the Muhimbi PDF Converter Services (on-premise).
Naturally we added some new functionality as well. The key changes are as follows:
Support for PDF/A-3b in addition to existing support for PDF/A-1b and 2b.
Optionally unhide hidden Excel columns and rows during PDF conversion.
PDF Conversion of Outlook contacts (in MSG Format).
PDF Conversion of delivery and read receipts (in MSG Format).
Support for targeting 'last page' when watermarking documents.
Many improvements to Email, AutoCAD, MS-Word and HTML converters.
New unattended installer.
A quick introduction for those not familiar with the product: The Muhimbi PDF Converter Services is an ‘on premises’ server based SDK that allows software developers to convert typical Office files to PDF format using a robust, scalable but friendly Web Services interface from Java, .NET, Ruby & PHP based solutions. It supports a large number of file types including MS-Office and ODF file formats as well as HTML, MSG (email), EML, AutoCAD and Image based files and is used by some of the largest organisations in the world for mission critical document conversions. In addition to converting documents, the product ships with a sophisticated watermarking engine, PDF Splitting and Merging facilities, an OCR facility and the ability to secure PDF files. Separate SharePoint and Cloud-based Subscription services are available as well.
Over the past 10 years, we have always made it a habit to listen to our customers, especially when kicking off the development of a new release. Once you receive a request, or bug, more than once, you'd better do something about it.
However, during the last 3 to 4 years things have changed. Naturally we still listen to our customers, but Muhimbi is now its own biggest customer. What!? Indeed, and to the best of our knowledge, no one carries out more operations in a real-word production environment than we do in-house. Why is this? Well, our popular cloud based services, the Muhimbi PDF Converter for SharePoint Online, and the Muhimbi PDF Converter Services Online, use the exact same engine that we ship alongside our on-premise products.
Because our Online customers fully depend on us, our data centres and our software, the responsibility to keep things up and running has shifted from our customers' IT departments, to our own operations team. Although our products have always been very stable and scalable, there were plenty of minor hiccups that we did not know about because it wasn't too much of a problem to our customers. However, when you run your own software at a very VERY large scale then all small things add up.
To cut a long story short, we monitor our online services like a hawk. Each and every issue, no matter how big or small, is recorded and analysed. If we can help it, we fix it. As a result we have improved and fixed dozens of issues in the new 8.4 release.
Naturally we added some new functionality as well. The key changes are as follows:
Support for PDF/A-3b in addition to existing support for PDF/A-1b and 2b.
Skip processing of 'real-time operations' for search indexer and other system accounts.
Optionally unhide hidden Excel columns and rows during PDF conversion.
PDF Conversion of Outlook contacts (in MSG Format).
PDF Conversion of delivery and read receipts (in MSG Format).
Support for targeting 'last page' when watermarking documents.
Many improvements to Email, AutoCAD, MS-Word and HTML converters.
New unattended installer.
For those not familiar with the product, the Muhimbi PDF Converter for SharePoint is a lightweight solution that allows end-users to merge, split, watermark, secure, OCR and convert common document types - including InfoPath, AutoCAD, MSG (email) MS-Office, HTML and images - to PDF as well as other formats from within SharePoint using a friendly user interface, workflows or a web service call, without the need to install any client-side software or Adobe Acrobat. It integrates at a deep level with SharePoint and leverages facilities such as the Audit log, Nintex Workflow, K2 blackpearl, localisation, security and tracing. It runs on SharePoint 2007-2019 & SharePoint Online and is available in English, German, Dutch, French, Traditional Chinese and Japanese. For detailed information check out the product page. This ‘on-premise’ version of the PDF Converter requires software to be installed on the SharePoint server. Please note that if you have no server access, there is always the option to deploy our SharePoint Online App to on-premise versions of SharePoint 2013, 2016 and 2019. For details see this blog post.
When I recently wrote the 
As the only serious player in the InfoPath to PDF conversion market, it doesn't surprise us that many organisations use our software to convert InfoPath forms to PDF. 
This article is based on a post Clavin Fernandes made to his 
Yes, you read that right, we have added a 100% free subscription tier to both the 
