Subscribe to News feed

Dealing with attachments when converting emails, InfoPath forms and merging documents

Posted at: 17:42 on 22 November 2019 by Muhimbi

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? -->
  <add key="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. -->
  <add key="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 -->
  <add key="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. -->
  <add key="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 -->
  <add key="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).-->
  <add key="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).-->
  <add key="PDF.ExcludeAttachmentTypes" value=""/>

 

 

For InfoPath forms containing attachments

  <!-- Enable or disable the conversion of Infopath attachments. -->
  <add key="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 -->
  <add key="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. --> <add key="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 --> <add key="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).--> <add key="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).--> <add key="InfoPathConverterFullFidelity.ExcludeAttachmentTypes" value=""/>

 

 

For Emails containing attachments

  <!-- The default value for converting attachments. -->
  <add key="MSGConverterFullFidelity.ConvertAttachments" value="True"/>
  <!-- Specify whether the attachment filenames are displayed in the email header. 
This setting works independently from ConvertAttachments. -->
<add key="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 --> <add key="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. --> <add key="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 --> <add key="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).--> <add key="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).--> <add key="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:

<Override>
    <ConversionSettings>
        <ConverterSpecificSettings type="ConverterSpecificSettings_MSG">
            <ConvertAttachments>true</ConvertAttachments>
            <AttachmentMergeMode>Merge</AttachmentMergeMode>  
            <DisplayAttachmentSummary>true</DisplayAttachmentSummary>
        </ConverterSpecificSettings>
    </ConversionSettings>
</Override>

 

 

Via SOAP API

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.

 

As always, if you have any questions leave a comment below, or contact our friendly support team.

.

Labels: , , , , ,

Add Barcodes to documents using SharePoint, Workflows, Office 365 or API

Posted at: 18:20 on 21 November 2019 by Muhimbi

barcodeOne 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.
 

Barcode Examples

  
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:

 
Wow, that is quite the list, but let's have a look at what this actually looks like for SharePoint Designer workflows, Nintex Workflow, Microsoft Flow, Muhimbi Watermark On Open & XML Watermarks, and for APIs.

 

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'
 

SharePoint Designer Workflow - Barcode

 

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.
 

Nintex Workflow - Barcode

 

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.
 

Microsoft Flow - Barcode

 

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.

Barcode watermarks must be added using Muhimbi's XML based watermarking syntax. An example is provided below:

<watermark 
    hPosition="right" 
    vPosition="top" 
    width="200"
    height="100"
    zOrder="1"
    opacity="100"
    printOnly="false"
    pageOrientation="both">
    <linearBarcode
      width="200" 
      height="100" 
      text="1234567890"
      barcodeType="Codabar"
      omitStartStopSymbols="false"
      disableCheckDigit="false"
      showCheckDigit="true"
      textLocation="Bottom"
      barcodeToTextGapHeight="3"
      fontFamilyName="Arial"
      FontSize="8"
      fontStyle="regular"
      textAlignment="Center"
      margin="5" />  
</watermark>
  
 

REST / API

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.

Make sure you enter your API_KEY in the example below. You can get one for free by signing up for the Muhimbi PDF Converter Services Online
 

curl "https://api.muhimbi.com/api/v1/operations/linear_barcode_watermark" \
  -X POST \
  -d "{\"source_file_name\":\"Testing.pdf\",\"use_async_pattern\":false, \
     \"source_file_content\": \"$( base64 -w 0 test.pdf)\" ,\"content\":\"1234567890\", \
     \"barcode_type\":\"Codabar\",\"omit_start_stop_symbols\":\"false\",\
     \"disable_checkdigit\":\"false\",\"show_checkdigit\":\"true\",\"margin\":\"5\", \
     \"font_family_name\":\"Arial\",\"font_size\":\"8\",\"font_style\":\"Regular\", \
     \"label_placement\":\"Bottom Center\",\"position\":\"Top Center\",\"width\":\"200\", \
     \"height\":\"100\",\"opacity\":\"100\",\"start_page\":0,\"end_page\":0,\"page_interval\":0, \
     \"page_orientation\":\"Portrait\",\"print_only\":\"false\",\"fail_on_error\":true}" \
  -H "API_Key: [INSERT_YOUR_API_KEY_HERE]" \
  -H "Content-Type: application/json" \
  | jq -r '.processed_file_content' | base64 --decode > watermarked.pdf
  

 
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.

.

Labels: , , , , , , , , , , , ,

Need support from experts?

Access our Forum

Download Free Trials