To create PDF or Word documents we use a Document Generator Engine that generates these documents based on whatever it is you created in the WEM User Interaction Editor. What you create in the editor, is being translated by WEM into HTML so it can be displayed in your browser. The Document Generator Engine uses this generated HTML as input to translate that into either PDF or Word.

To get the best results it helps a lot if you get a “feel” for the quirks that you might run into, and how to address them. BTW, the PDF-engine is slightly richer than the Word engine.

The WEM Master Template works with rather complex css for responsiveness and Bootstrap (remember: all WEM applications are based on Bootstrap). Which is great for browsers, but can be challenging for Documents, which do not support Bootstrap and responsiveness quite as well (as there is no need to).

For a specific project that requires it (and has a lot of document creation), we can create a specific PDF-MasterTemplate-CSS file to have a more optimized starting point, but this is not by default available.

So by default, the Document Generator uses the standard CSS definitions that are primarily used for the browser.

Especially when you use Bootstrap-elements (like columns, panels, alerts, table in bootstrap display mode) for Document output, you will run into issues.

For PDF and Word output, it is best to avoid Bootstrap elements. The Word Engine does not support most of those elements (no background colors, no rounded edges, no shading etc); PDF suffers mostly from the sizes, paddings and margins. It is best to use simple container elements (table with default display mode, not bootstrap; basic blocks, custom html in script blocks).

However, you CAN use the bootstrap elements, but then you'll need to tweak them.

1. Avoid running off page: use a standard html container (a div or a simple-not-bootstrap table ) with a width of "98%", this will help quite a lot!

2. Use custom style definitions for the elements. You will need to work with css elements and classes and override some of the standard settings of existing elements.

Most of the used html-elements have specific styling, based on bootstrap using variable settings and complex structures. To change font sizes or paddings or margins, you really need to know which html-element you want to tweak, and override the standard css-settings of that element with local custom css definitions.

WEM does not create "interactive" PDF documents. Instead you should display the values/fields as labels, where the result depends on the type of field: is it boolean, then yes/no, is it a multiselect based on concept set, then only those concepts selected will be displayed with their respective display names.

TIP: Using Chrome and the functionality to inspect element (right-click on a specific element) or view page source, will help you find out what the elements and their class-definitions are and how they are nested and structured, so you can use that information to tweak the settings with your custom bit of css. This is not possible on a generated document directly, so you need to have a normal User Interaction node in WEM with the same template contents as the pdf processnode.

I usually make template fragments, so I can create them once and then put them on the normal interaction node as well as in the PDF process node. I use the interaction node to investigate the html structure and tweak the elements. When I'm satisfied about the result in the PDF, I disconnect the interaction node (unless it has its use within the flow anyway).

Summarizing:

• You really need to try and understand the resulting html for your specific pdf, find out where it needs tweaking and then do the tweaking with inline css and html.

• Avoid using bootstrap elements, but if you do, place them within another container that has a width of 98% to avoid running off page. Or tweak them specifically.

• Define your own main container <div class="pdfcontainer"> here goes the rest of the document contents </div> you can define a style element on top <style>div.pdfcontainer table {width: 98%;}</style> and define the custom pdf styles for all used elements as a child or descendant of this div.pdfcontainer

• Be aware that the PDF cannot handle user interactions, so remove the Page size for paging on a datagrid or repeater and set panels to not collapsed.

• page breaking: a useful css-snippet for avoiding page-breaking (does not alway work, depends heavily on inner content):

{
    page-break-before: avoid; 
    page-break-after: avoid; 
    page-break-inside: avoid;
}
Possible values:
auto|always|avoid|left|right|initial|inherit

Tips for correct and responsible use

Sending emails with WEM is pretty easy. It only requires a configuration for SMTP Server to use and a proper sender address.

Here are a few pointers to use the Email Process responsibly:

1. Always provide correct and complete contact information within the body of your message, especially when external recipients are used. Make sure your recipients can understand where the message is coming from and how to get in contact if necessary. Use Template Fragments to easily re-use standard email content parts like contact information.

2. Preferably use a specific sender address, recognizably linked to the organization or the application, so recipients can easily and correctly link the message to the proper application/organization - even when they have no prior information or knowledge about it. This will yield a higher trust level in your recipients and will help to avoid spam situations. Read about SMTP Settings here to make this work correctly.

3. In case you want to use a "no-reply" account as sender, you should provide a correct Reply-To address, so recipients can send a direct reply which will actually get to someone that can follow up. Without the reply-to setting, replies from recipients will be sent back to the no-reply account and then may not be followed up.

4. When you test your project (in Preview or Staging), make sure to test with actual and existing recipient addresses that you or your team have access to. Only then you can test the e-mail feature properly (check if messages get delivered properly with correct contents).

5. AVOID the (deliberate) use of dummy email recipient addresses that go nowhere - this will lead to Non-Delivery-Reports and unnecessary server-traffic and may even lead to blacklisting of your SMTP Mail Server. If you do not need to send an email, then don't send the email.

6. Build functionality in WEM around the Email Process Node so you can SKIP sending e-mails if that is not really part of the test: when you do not really care if and how messages are sent - then don't send them. Use Decision Nodes with IsPreview(), IsStaging() and/or IsLive() expressions to control the situation, and perhaps provide an overlay or a setting to specifically send or skip sending emails during tests.

7. Be careful when using loops and sending bulk emails, too many messages can cause blacklisting or can trigger the mailserver to stop sending. You can add a Wait process node to add some waiting time between sending messages.

SMTP Settings

Please make sure you have the proper settings in place when you are sending emails from your own domain... The From-address used to send messages must be an account that is allowed to send messages from the selected SMTP server (same domain or otherwise configured to be allowed)

Configure the connection to your own SMTP server For message to be sent through your mail server, you can add your SMTP server's information to the SMTP settings of your Workspace in WEM (go to My Workspaces, select the workspace and click SMTP settings). Add host, port, username and password [optional but recommended]. On a workspace, you can add multiple SMTP servers. See SMTP Settings. In your portal settings, you can choose your SMTP server for the specific portal - from the list of SMTP Server Profiles setup and made available for the Workspace.

Image in E-mail

After some trials and tests, the current conclusion is that the Outlook Desktop email client is not properly rendering html tags and always shows images with their original dimensions. No matter what you try to do with html containers and styles and settings to change dimensions, Outlook Desktop will ignore all.

Generally the idea is to create a container (preferably a basic html-table with <tr> and <td>), set its width using static size in pixels, this should work for most html-based email clients. Just not Outlook.

If you want to display images in e-mail body in Outlook using a specific size, you really need to resize the image. An online image resizer service can be used in WEM (using http get request node), like https://imageresizer.io/ (Which original poster Arthur has found and used). WEM has its own Process Node to Resize Image that you can also use for this purpose.

With the Create ZIP Archive Process Node, you can create a zip-file containing a compressed version of the original file (as provided in the input parameter).

The Input File parameter may let you think that you can only put 1 file into the ZIP archive. But this parameter expression also accepts a list of File Fields, enabling you to add multiple files into the ZIP Archive in one go. As displayed in the example above:

• Have a list with a File field ([Products] with [Products.Images] in the example);

• In the Input File Parameter expression, use ([Products.Image] of [Products]) to add the images of all products to the ZIP Archive.

• Obviously, you can add a where-clause to limit the records of the list (Products where Name contains ...) or you can use a (transient) List with only one File field, and in your flow before the ZIP process, add any file from your project to that (transient) list and then use the above mentioned expression: ([FileField] of [List])

• If you have multiple file fields that are not in a single list but just a few "stand-alone" file fields, you can combine them with the following expression:

  Copy

  List([Attachment1], [Input.Files.File01], [Input.Files.Image01])