Muhimbi

Posted at: 4:44 PM on 30 May 2012 by Muhimbi

Even though the Muhimbi PDF Converter for SharePoint is full of innovative functionality, some features are perhaps a little bit more ground breaking than others. One of these innovative features that we are particularly proud of, and we know our customers love, is the ability to apply user specific watermarks when a PDF file is opened. The SharePoint platform does not allow workflows or event receivers to be triggered when a file is opened so we had to dig deep and write our own infrastructure to make this all work in a reliable and scalable fashion.

Many of our customers are using this user specific watermarking facility for security reasons by adding watermarks that include who opened a document, from where and at what time. This all works well, but the resulting PDF file was not encrypted and it was not possible to encrypt the file before watermarking as encrypted files cannot be modified with watermarks.

To cut a long story short, with the introduction of version 6.0 of the PDF Converter for SharePoint it is now possible to apply typical PDF Security setting to a file the moment it is opened or downloaded. Security is applied after a file is watermarked so files can now have user specific watermarks and PDF security at the same time, woohooo!
 

The key features are as follows:

• Apply security after user specific watermarks have been applied.
• Apply typical PDF Security including Open Password, Owner Password, Prevent Printing, Prevent Copy, Prevent Document assembly, etc.
• Allow filters to be specified and only apply security when a condition is met, e.g. a Status field is set to Approved, or the user that is accessing the document is in a specific group.
• Apply security to files in Document Libraries as well as files attached to individual list items.
• Works on all SharePoint 2007 and 2010 versions.

 
Let’s work through an example to show how easy it is to set this up.

1. By default the Secure / Watermark on open facility is disabled so use SharePoint Central Administration to enable the Muhimbi PDF Converter - Automatic PDF Processor Feature at the relevant Web Application. Note that this is a Web Application Scoped Feature, not a Farm or Site Collection scoped one. You also need to enable the Muhimbi PDF Converter - Automatic PDF Processing User Interface Feature at either the Web Application Level (to enable the screen on all Site Collections) or at the individual Site Collection level.
2. Once enabled, a new menu named PDF security settings can be found in the Site Actions / Site Settings screen as well as the List Settings screen on each individual List and Document Library. Default security settings can optionally be specified at the Site Collection level, which can then be inherited at the individual List or Library Level, which is displayed in the following screen.
   
     
   
3. As you can see in the screenshot there are also options to enable security during Insert and Update events. However, the focus of this article is to Secure On Open. In this screenshot we have specified both an Open and an Owner Password. The Owner Password must be set when any of the PDF Security Options are selected, the Open Password is optional.
4. In the same screenshot we have also specified a filter to only secure documents when the person opening the file is in the Test Visitors SharePoint group. Please note that you can only use SharePoint Group names, not Windows Group names.

That is all there is to it. When a PDF file is opened from the Document Library, and the user opening it is a member of the Test Visitors group, then PDF Security will be applied automatically to the file without modifying the original in the List or Document Library.

Please note that securing files this way is a real-time action and adds some overhead. If there is no need to apply security in combination with user specific watermarks, or based on a user specific filter, then we recommend applying security using a SharePoint Designer or Nintex workflow the moment a file is created or modified.

Labels: Articles, News, pdf, PDF Converter

Posted at: 2:01 PM on by Muhimbi

At Muhimbi we take great pride in always going the extra mile. Not only do we add features and functionality specifically requested by our customers, but sometimes we add a ‘wildcard’ feature that no one has asked for. One of the wildcards we added to the very first version of the Muhimbi PDF Converter for SharePoint was the ability to copy meta data while converting a file and, based on customer feedback, people absolutely love it.

Over the years we have received various requests for additions and changes to this meta-data copying facility, but as we don’t want to cause any backwards compatibility issues we were unable to facilitate these requests. For example, half the requests were for copying the source file’s content type as well, while the other half wanted to default to the library’s default content type. Sigh…. customers :-).

We thought we would never be able to please everyone, but I think we have actually cracked it as, with the introduction of version 6.0 of the PDF Converter for SharePoint, we have added a new stand-alone Workflow Activity to copy meta-data and set content types in one easy step.

From a very high level the functionality is as follows:

• Standalone Workflow Activity that can be used in combination with any of Muhimbi’s Workflow Activities, or without them.
• Copy all meta-data or only selected fields.
• Copy meta-data to files in different folders or site collections.
• Change the content type to either the source file’s, destination file’s, the default content type for the library or a specific named content type.

To insert this new Activity into a workflow click the Action button in the SharePoint Designer Workflow editor and select Copy Meta Data. This inserts the following workflow sentence.
 

 
The parameters are largely self describing and use the same format as our other Workflow Activities such as Convert to PDF, Watermark PDF, Convert & Merge files, Split files, Convert HTML to PDF, Convert to non-PDF formats and Secure PDF.

• This document: The source document to copy the meta data from. For most workflows selecting Current Item will suffice, but some custom scenarios (e.g. Site workflows) may require the look up of a different item. 
• This File: The path and file name to copy the meta-data to. Please make sure that the path does not include the host name, e.g. ‘http://your site/…’., see this post for details about specifying paths.
• Fields: By default the content of all fields is copied to the destination file. However, if you wish to copy only specific fields then the field names can be specified in this list. You can separate fields using line breaks, ‘,’ or ‘;’ and you can use both internal and external field names.
• Content type: While copying meta-data you have full control over the content type of the destination file. The following options can be specified:
  • (source): The content type of the source file is applied to the destination file. Please include the round brackets.
  • (target): The content type of the destination file is not modified and remains what it was before the copy operation. Please include the round brackets.
  • (default): The default content type for the document library is applied to the destination file. Please include the round brackets.
  • Name of Content type: The destination file is set to a specific, named, content type. Please do not use round brackets around the name of the content type.
• Parameter ‘List ID’: The ID of the file the meta-data was copied to. This can later in the workflow be used to perform additional tasks on the file such as performing a check-in or out.
• Parameter ‘List Item ID’: The ID of the list that holds the file that the meta-data was copied to.

Similar to our other Workflow Activities, this new Copy Meta Data facility is both simple and powerful and works in SharePoint 2007 and 2010.

Labels: meta-data, PDF Converter, Workflow

Posted at: 4:49 PM on 28 May 2012 by Muhimbi

As of version 6.0 the Muhimbi PDF Converter for SharePoint supports cross-conversion of documents. An absolute brilliant new feature that, in addition to converting documents to PDF, makes it possible to convert between versions of file formats  (doc to docx, xlsx to xls etc) and even between completely different file types (InfoPath to Word, Excel and HTML or Excel to MS-Word). A SharePoint Designer workflow example and a full chart outlining all possible combinations can be found here.

As we are big fans of Nintex Workflow we are making sure that Nintex Workflow is supported from day one. Similar to all other Nintex Activities provided by Muhimbi, the Convert Document activity integrates with Nintex Workflow at a deep level. It supports SharePoint 2007 as well as 2010, allows errors to be handled and even supports integration with Nintex’ iterators to deal with multiple items and loops. For a comprehensive example and details about how to enable the Nintex Workflow integration see this blog post that discusses our generic Nintex PDF Conversion activity.  
 

Cross convert between document types using Nintex Workflow 2007 and 2010

Building a full example workflow is out of the scope of this post as it is very simple, especially considering it works almost identical to the existing Convert to PDF activity, with the following exceptions:

• Output Format: This field is new and allows the output format to be specified, e.g. doc, xls, pdf, txt, csv, etc.
• Output Item ID: The type of this field is Text rather than Item ID. The reason for this is that a future version of our software may return multiple, comma separated, values for certain actions.

That is all! Very straight forward, especially if you are familiar with our other Nintex Workflow Activities. Please note that you may need to make some small modifications if you intend to convert InfoPath to Excel, HTML or MS-Word. For details see this blog post.

For more details about using PDF Converter for SharePoint in combination with Nintex Workflow, see:

• Converting multiple SharePoint files to PDF Format using Nintex workflow
• Secure PDFs using Nintex Workflow and the Muhimbi PDF Converter for SharePoint
• Convert and Merge PDFs using Nintex Workflow and the PDF Converter for SharePoint
• Watermark PDFs using Nintex Workflow and the Muhimbi PDF Converter for SharePoint
• Convert HTML to PDF using Nintex Workflow and the PDF Converter for SharePoint

Labels: Articles, Document Conversion, News, Nintex, pdf, PDF Converter, Workflow

Posted at: 3:40 PM on 15 May 2012 by Muhimbi

Muhimbi’s range of server based PDF Conversion products have been developed with performance, scalability and reliability in mind. As a result the software scales from the most humble ‘everything on the same server’ environments to environments that deal with millions of conversions a day across a farm of servers. In this article I will discuss the most common deployment scenarios.

Whenever this article mentions ‘Server’ it doesn’t matter if this is a physical or virtualised server. Our software does not differentiate between the two and will work fine on either type.

Introduction – Architecture

Both the PDF Converter for SharePoint and the PDF Converter Service ship with the same central conversion engine. This engine, The Muhimbi Conversion Service, is responsible for carrying out all the work including conversion of files, watermarking, merging, splitting and security activities. Although in case of our PDF Converter for SharePoint our front end is quite comprehensive, all it really does is prepare requests for the Conversion Service and receive responses containing new or modified documents.

If you are involved in deploying any of our PDF Conversion products then it is essential to know how our software works from an architectural perspective. The Muhimbi Conversion Service is a standard Windows Service that starts automatically when Windows boots up and requires no user interaction or anyone to be logged in to the server console.

This Windows Service contains a WCF based Web Service that exposes functionality to any Web Services capable environment including Java, C#, VB.NET, Documentum, SAP, PHP etc. Typically when administrators think about web services they assume that they need to host this inside a web server such as IIS or Apache. Although that may be true for many web services, Muhimbi’s PDF Conversion software runs inside a self-hosted WCF service that does not have any external dependencies on third party web servers.

By basing the conversion service on WCF we get a lot of benefits, including:

1. No external dependencies on web servers and other 3rd party products.
2. A mature framework with support for different message and transport types, built in security and advanced features such as MTOM encoding for large attachments.
3. And most importantly, all functionality is exposed via standard HTTP based Web Service requests.

This last point about requests being HTTP based is very important as it allows the Conversion Service to be scaled across multiple servers using standard hardware or software based load balancers, including the free NLBS that ships with Windows. By utilising a load balanced environment you can achieve linear scalability and automatic failover.
 

Example based on SharePoint Front ends, but Java and .NET deployments work the same.

 
For details about tuning the various options of the Muhimbi Conversion Service, and installation in general, see the Resources section at the end of this article.

Single Server Farm

The most basic configuration possible is to install everything on a single server. Just follow Chapter 2 in the Administration Guide (including all links to Appendices) and you are ready to go. There is nothing else to configure and, if needed, the Web Service can be accessed on the following URL:

      http://localhost:41734/Muhimbi.DocumentConverter.WebService/

Small farms with a single Conversion Service

For slightly larger deployments of 2 or more servers, but with a single conversion server, deployment is very simple as well. Let’s take the following example:

• Server 1: A new or existing Application Server that will run the Muhimbi Conversion Service.
• Server 2: A server that will run either a SharePoint WFE or a custom solution.

In this particular case it is a matter of installing the Conversion Service on Server 1 as per the instructions in Chapter 2 of the Administration Guide. No further changes are required, but remember that the web service URL is now:

    http://Server1:41734/Muhimbi.DocumentConverter.WebService/

Naturally you will need to replace ‘Server1’ with the actual host name of the server.

In case of a SharePoint deployment you need to deploy the WSP file to Server 2 and enter the Web Services URL in the PDF Converter’s SharePoint Central Administration screen. If you are not running SharePoint, but your own Java / .NET / etc solution then you will need to pass the above mentioned web service URL using whatever syntax is common for your platform.

Large farms with multiple conversion servers

Now, this is where things get interesting, a farm with multiple front end servers and multiple conversion servers. Let’s take the following example:

• Server 1: A new or existing Application Server that will run the Muhimbi Conversion Service.
• Server 2: A new or existing Application Server that will run the Muhimbi Conversion Service.
• Server 3: A server that will run either a SharePoint WFE or a custom solution.
• Server 4: A server that will run either a SharePoint WFE or a custom solution.
• Load Balancer

In this scenario the Conversion Service will need to be installed on Server 1 and Server 2 as per the instructions in Chapter 2 of the Administration Guide. Once installation is complete the web service can be reached on the following 2 URLs:

    http://Server1:41734/Muhimbi.DocumentConverter.WebService/
    http://Server2:41734/Muhimbi.DocumentConverter.WebService/

Although in theory you could build functionality into your software to alternate requests between these two URLs, it is much easier and more robust to use an off-the-shelf HTTP load balancer or Windows NLBS. How this works in detail differs per load balancer, but it usually involves creating a virtual host that listens for requests and configure this virtual hosts to send requests to Server1 and Server2. In this example we assume that this virtual host is named LoadBalancer resulting in the following Web Service URL:

In case of a SharePoint deployment you need to deploy the WSP file to Server 3 or 4. it doesn’t matter which one, the installer will automatically deploy it to all WFEs.

The LoadBalancer URL needs to be added to the PDF Converter’s SharePoint Central Administration page, or your application’s configuration file. When a request is made to the load balanced URL the load balancer will automatically detect which of the servers are available and only send requests to servers that are up and running. If multiple servers are up and running it will distribute requests between all servers.

If you have multiple SharePoint Web Front End servers it may be tempting to install a copy of the Conversion Service on each WFE. Although this is a supported scenario we recommend deploying the Conversion Service on separate Application Servers to make sure that your WFEs resources are available for running SharePoint, which can be quite resource hungry by itself.

Licensing

Please make sure you are licensed for the correct number of servers. Muhimbi's software is licensed on a 'per server' basis. This means that you need a license for every server that runs our software including all Web Front End servers in your SharePoint farm and all servers running the conversion service.

For more details see this Knowledge Base Article.

Resources

For more details about deployment and configuration see the following resources:

• PDF Converter for SharePoint Admin Guide.
• PDF Converter Service Admin Guide.
• Web Services related topics in Knowledge base.
• Deployment related topics in Knowledge base.

.

Labels: Articles, Deployment, Guidelines, PDF Converter, PDF Converter Services

Posted at: 1:20 PM on 04 May 2012 by Muhimbi

Both the Muhimbi PDF Converter for SharePoint and the generic Muhimbi PDF Converter Service 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.

1. Open Muhimbi.DocumentConverter.Service.exe.config in notepad. A shortcut to the installation folder can be found in the Windows Start Menu.
2. Search for the following ‘binding’ element and add the messageEncoding attribute.
   
   

   <binding messageEncoding="Mtom" name="securedBasicHttpBinding" maxBufferSize="69905067"
            maxReceivedMessageSize="69905067" receiveTimeout="00:10:00" sendTimeout="00:10:00" 
            closeTimeout="00:02:00">
   

    
3. Restart the Muhimbi Conversion Service.
4. 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.
   
   

   binding.MessageEncoding = WSMessageEncoding.Mtom;

    

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.

.

Labels: Articles, Java, pdf, PDF Converter, PDF Converter Services

Posted at: 12:10 PM on 12 March 2012 by Muhimbi

Although all our other products have been compatible with both SharePoint 2007 and SharePoint 2010 for years, the free SharePoint Infuser never received the SharePoint 2010 treatment.

Fortunately all that was needed was to change the installer, as per the instructions in our ‘Porting a SharePoint 2007 WSPBuilder solution to SharePoint 2010’ series of articles.

Please note that all the Infuser examples posted on our blog are based on the SharePoint 2007 user interface. The principle for SharePoint 2010 is exactly the same, but you will need to add your own HTML / JavaScript code.

Download it here, check out examples here.

Labels: Infuser, News, Products

Posted at: 5:47 PM on 24 February 2012 by Muhimbi

Earlier this week I posted about the fact that the Muhimbi PDF Converter Services and the PDF Converter for SharePoint now support output to formats other than PDF. This opens up a whole new world of possibilities such as converting between DOC and DOCX, XLS and XLSX, but more importantly it also supports converting between completely different document types such as Excel to MS-Word and HTML to Excel.

This post describes another new conversion type that should be of particular interest to our InfoPath customers as it is now possible to convert InfoPath forms to MS-Word, Excel and HTML. (Please note that this new functionality requires version 6 of the PDF Converter or later, which is currently available on request.)
 

Conversion to these new formats generally works very well, but there are some limitations due to the nature of these non-PDF based destination formats. Specifically:

1. Attachments: When converting an InfoPath form to PDF we also convert all attachments and merge them to the main PDF. This is possible because you can represent almost any file format in PDF and merge them together. Unfortunately this is not possible when converting to HTML, MS-Word or Excel.
2. View Selection: We provide a number of ways to specify which view or views to convert. When converting to PDF it is possible to specify multiple views, which our converter then merges together into a single document. When converting to HTML, MS-Word or Excel it is only possible to convert a single view as these file formats don’t make merging easy. As a workaround you can create a ‘conversion specific view’ and combine the content of multiple views in it.
   Print Views are also ignored when converting to HTML, Word or Excel. Instead you will need to use Muhimbi’s View Selection facilities if you wish to convert any view other than the default View.
3. Formatting: PDF is a super flexible format that allows any content to be placed pretty much anywhere on the page. MS-Word, Excel and HTML are not necessarily this flexible. For example, Excel uses a ‘cell based approach’ to display content. If your InfoPath form is not specifically designed for export to Excel, e.g. it uses nested tables or different column widths across a page, then you may need to optimise your InfoPath form for conversion, or create a ‘conversion specific view’.

Detail about how to convert to these new document types (as well as to PDF) can be found here.

InfoPath to HTML (MHT)

When converting InfoPath to HTML the resulting file is a self contained MHT file that most modern browsers can display. All information including images, HTML and style sheets are included in this single file.
 

From left to right, the same Form in InfoPath, converted to PDF and converted to HTML Click to enlarge

 
As you can see in the image above, InfoPath data can be represented in HTML really well so it is usually not needed to make any changes.

InfoPath to MS-Word

Depending on how an InfoPath form has been designed, some work may be required to make things look better when converting to MS-Word. This is mainly due to the fact that MS-Word does not like dimensions that are expressed in percentages, while it is common in InfoPath to create a table grid and populate that grid with controls that take up 100% of the available cell space.
 

Results when converted to MS-Word before optimisation (left) and afterwards (right). Click to enlarge.

 
Looking at the ‘before optimisation’ conversion results in the image displayed above, there are 2 things that are not quite right:

1. Dimension of text fields: The dimensions of most text fields are not quite right. This can easily be changed by opening the form in InfoPath Designer and changing the width of the various fields from ‘100%’ to the actual dimensions in cm or inches.
2. Missing ‘year’ in date picker fields: Due the way the Date Picker is structured internally, modifying its width does not translate properly when displayed in MS-Word. To solve this change the date picker field to a regular text field either by creating a conversion specific view, or using a display rule.

The InfoPath to MS-Word facility can generate output in doc, docx, rtf, txt, html and odt formats.

InfoPath to Excel

InfoPath to Excel conversion for existing forms, which are not optimised for conversion to Excel, are probably the trickiest ones to get right. If you don’t care about the ‘look and feel’ of the Excel sheet then no change is required, but if the Excel forms need to ‘look good’ then you may need to rethink the way the form is designed.
 

Results when converted to Excel before optimisation (left) and afterwards (right). Click to enlarge.

 
Looking at the ‘before optimisation’ in the image above things don’t look too bad, but clearly it is not the same as the original. The main issues are as follows:

1. Column Widths: As Excel uses a cell / grid based approach it is not possible to mix different column widths. The information in the form’s header requires different column width and spans than the columns used in the repeating table further down the page. By changing the horizontally oriented fields in the header to individual rows we no longer have this problem.
2. Number formats: Depending on a cell’s content Excel sometimes tries to be ‘clever’. Most of the time this works great, but in this case a field with value ‘007’ is changed into a ‘7’. This could be fixed by changing the content of the InfoPath field into a formula and concatenating an apostrophe in front of it.

The InfoPath to Excel facility can generate output in xls, xlsx, csv and ods format.

In conclusion these new file formats work very well, especially if you are willing and able to make some tweaks. If you have any questions, or would like to receive a pre-release, then either contact us or leave a comment below. We’d love to hear from you.

.

Labels: Articles, Document Conversion, InfoPath, Java, News, pdf, PDF Converter, PDF Converter Services, Products

Posted at: 4:44 PM on 22 February 2012 by Muhimbi

We have known for a long time that this day was coming, but the PDF Converter for SharePoint is no longer limited to generating just PDFs. So now we have a product that doesn’t quite describe what it does…GREAT! Oh well, the good news is that once again we have added some excellent new functionality that allows documents to be converted to types other than PDF. (Available in version 6.0 and newer, currently available on request)

So, how is this useful? Well, let’s say that you have a large amount of legacy Office 97-2003 files, but your company now requires all files to be saved in the more modern, and open, Office 2007-2010 formats. By using the Muhimbi PDF Converter you can convert between these formats automatically using a SharePoint workflow or a simple web service call using Java or .NET.

Naturally you can go in the other direction as well. For example many users in your company may still be on Office 2000 or 2003, but those fancy guys in IT are saving documents in Office 2010 format. No-one else in the organisation can open these shiny new files using their geriatric versions of MS-Office / Open Office. A simple SharePoint workflow will automatically take care of this and convert the file to the desired format.

Naturally we have to be realistic about which files to convert between. Going from AutoCAD to Excel makes no sense, but from Excel to Word and Word to Excel could be useful. The table listed below shows which file formats can be converted between.

Some points of interest:

1. It is now possible to convert InfoPath files to MS-Word, Excel and HTML (PDF and XPS was already possible).
2. Although not displayed in this chart, it is also possible to convert PDF (and any other file type) to PDF/A.
3. It is even possible to ‘convert’ to the same format as the source, e.g. docx to docx, but specify additional settings such as a password on the document.

Convert using Web Service calls

Converting files to non-PDF formats using web service calls works identical to converting files to PDF. The only difference is that the Format property on the ConversionSettings object must be set to the file type you are converting to. For details see the existing Convert to PDF sample code for Java and .NET.

Convert using SharePoint Workflows

Converting a document using SharePoint Designer workflows (Nintex version here) works similar to converting to PDF. The main difference is that you now use the Convert Document Workflow Activity rather than the Convert to PDF one.

After adding the new activity to your workflow you will see the following Workflow Sentence.
 

 
The workflow sentence is consistent with our other Workflow Activities (e.g. Converting / Watermarking / Splitting / Merging), and is largely self-describing.

• This document: The document to convert. For most workflows selecting Current Item will suffice, but some custom scenarios (List or Site workflows) may require the look up of a different item. 
• This File: An optional filename (and path) to write the converted document to. When not specified, the same name as the document that triggered the workflow will be used, just with a different extension. Please make sure that the path does not include the host name, e.g. ‘http://your site/…’., see this post for details about specifying paths.
• Select file type: Select the type to convert to from the drop down menu.
• Include / exclude meta data: In case of sensitive documents you may want to strip any custom SharePoint columns from the file. For example, if your document library contains a column named ‘Yearly sales forecast’ then you may want to select ‘Exclude’.
• Optional parameters: Reserved for future use.
• Parameter ‘List ID’: The ID of the list the converted file was written to. This can later in the workflow be used to perform additional tasks on the file such as performing a check-in or out.
• Parameter ‘List Item IDs’: At the moment this workflow activity will always generate a single output file. However, in the future it will be possible to generate multiple output files in one go, in which case this parameter will return a string with ‘;’ separated values of the generated item IDs. This list can then be used by other (custom) activities, e.g. the ones created by our Workflow Power Pack, to process the individual files further.

A basic sample workflow is included below, by attaching this workflow to a Forms Library any InfoPath form saved in it will automatically be converted to an MS-Word 2007 file.
 

Similar to all other functionality provided by the PDF Converter for SharePoint, this new Workflow Activity works on all SharePoint 2007 and 2010 editions.

For a more complex scenario see the existing blog post about the PDF Conversion Activity.

If you have any questions, or would like to receive a pre-release, then either contact us or leave a comment below. We’d love to hear from you.

.

Labels: Articles, Document Conversion, Java, News, PDF Converter, PDF Converter Services, Workflow

Posted at: 12:02 PM on 23 January 2012 by Muhimbi

At the end of last week we released version 5.2 of the PDF Converter for SharePoint, which ships with an improved version of our popular PDF Conversion engine. Today we are releasing an update to the standalone version of the Muhimbi PDF Converter Services that includes all new functionality and fixes including the ability to convert MSG (email) files and output in PDF/A format.

The list of new features and improvements is considerable but the main ones are as follows:

• Convert Outlook MSG files to PDF including all attachments.
• Splitting PDF Files using Java or .NET .
• PDF/A Post processing for all supported file formats.
• Support for the 64 bit version of Office 2010

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 and .NET based solutions. It supports a large number of file types including MS-Office and ODF file formats as well as HTML, MSG (email) 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 and the ability to secure PDF files. A separate SharePoint specific version is available as well.

 

New, PDF Conversion of MSG based emails
 

In addition to the changes listed above, some of the main changes in the new version are as follows:

 
For more information check out the following resources:

• Product Page.
• Brochure.
• Release Notes.
• Administration Guide.
• User & Developer Guide.
• FAQ.
• Discussion Forum.
• All PDF Converter Services related Blog Posts.

As always, feel free to contact us using Twitter, our Blog, regular email or subscribe to our newsletter.

Download your free trial here (10MB). .

.

Labels: AutoCAD, Java, MSG, News, pdf, PDF Converter Professional, PDF Converter Services, PDF/A, Products, Splitting

Posted at: 2:01 PM on 20 January 2012 by Muhimbi

Over the past 4 months our engineers have been hard at work on a number of brilliant new facilities resulting in the new 5.2. release of our popular Muhimbi PDF Converter for SharePoint.

The list of new features and improvements is considerable but the main ones are as follows:

• Convert Outlook MSG files to PDF including all attachments.
• Splitting PDF Files using SharePoint workflows.
• PDF/A Post processing for all supported file formats.
• Support for the 64 bit version of Office 2010

For those not familiar with the product, the PDF Converter for SharePoint is a lightweight solution that allows end-users to watermark, merge, split, secure and convert common document types - including InfoPath, AutoCAD, MSG (email) MS-Office, HTML and images - to PDF format 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, localisation, security and tracing. It runs on WSS 3, MOSS as well as SharePoint 2010 and is available in English, German, Dutch, French, Traditional Chinese and Japanese. For detailed information check out the product page.

New, PDF Conversion of MSG based emails

In addition to the changes listed above, some of the main changes in the new version are as follows:

For more information check out the following resources:

• Product Page.
• FAQ.
• Release Notes.
• Installation & Administration Guide.
• User Guide.
• Screenshots.
• Discussion Forum.
• Related Blog Posts.

As always, feel free to contact us using Twitter, our Blog, regular email or subscribe to our newsletter.

Download your free trial here (14MB). .

.

Labels: AutoCAD, InfoPath, Merging, MSG, News, pdf, PDF Converter, PDF Converter Professional, PDF/A, Products, Splitting, Workflow