Both the Muhimbi PDF Converter for SharePoint and the generic Muhimbi PDF Converter API and Server Platform use a WCF based web service under the hood. This is absolutely brilliant as it allows any modern Web Services capable development environment - including C#, VB, Java, PHP, SAP, Documentum - to use our web service to convert, split, merge, secure and watermark all kind of files.
To make sure that our conversion service also works with dumber less capable languages we have to target the lowest common denominator, which means Base64 encoding for all attachments. Unfortunately Base64 adds 33% overhead, so a 1MB file takes up 1.3MB worth of bytes when sent over the wire. In most situations you will never notice this unless you are processing a particular high volume of data or you….just…have…to…squeeze…out…every…last…byte.
Fortunately the WCF framework that the Muhimbi Conversion Service has been built on is very flexible and switching encoding is almost trivial. Listed below are the steps to switch from Base64 to MTOM, which has almost no encoding overhead. For the time being you should not apply these changes to the PDF Converter for SharePoint as our SharePoint front end has no knowledge of MTOM (scheduled for 6.1), but you can safely apply the following changes to the PDF Conversion Service if you control all interaction with this web service using your own code.
Open Muhimbi.DocumentConverter.Service.exe.config in notepad. A shortcut to the installation folder can be found in the Windows Start Menu.
Search for the following ‘binding’ element and add the messageEncoding attribute.
Restart the Muhimbi Conversion Service.
In your client side code you will need to enable MTOM encoding as well. How this is done depends on your platform of choice. In case of C# / .NET it is a matter of setting the messageEncoding property on your binding.
That is all there is to it. Naturally you can make this more complex by adding bindings for both encoding types, but that is an exercise I'll leave to the reader.