New Patch Release – Please see release notes in Dashboard Update Utility

Headlines:

New: Ability to exclude a font when extracting text from a PDF.

Behaviour Change: Tidy up of XML field names when displayed in Layout Text item, text properties

Memory Optimisation.

New Feature Release – Please see release notes in Dashboard Update Utility

Headlines:

JSON supported as a new spoolfile type, with dedicated scripting commands.

Taskfire() allows a second task to be triggered from the first. Task type and scripting commands added.

XMLfromString() – allows a fully formed XML data structure to be read from a variable into a document model, such as a response from a web service accessed via a plug-in. (equivalent JSON command also available.)

Try/Catch Exception handling coding structure added to scripting engine

+ Various minor bug fixes

MS Visual Studio demo project added to help with development of custom Plug-ins.

Font use and availability can be affected by how they are installed and how they are licensed. In these 2 posts will we comment upon their installation, and their distribution.

Fonts for use in eVo generated documents should be installed for “All Users”, and the license should allow for embedding or distribution within a document such as a PDF. In this, the second of these, we will look at distribution.

If you look at the details of fonts in the Font Folder, or look at the details of Font’s Properties you will see an entry for “FONT EMBEDDABILITY”

This determines if the of font is licensed to be distributed by being embedded in a parent document, such as a PDF. Fonts need to be embedded in a document, such as a PDF to ensure it is displayed as intended on a designation device that may not have that font installed. This is explained here, better than I could;

Font redistribution FAQ – Typography | Microsoft Learn

About font license restrictions – Microsoft Support

But basically, unless it says restricted, you can embed and therefore distribute the font purely for the purpose of correct display of the parent document. Such as;

Print and Preview – allows a recipient to view and print the document (no change or edit is licensed)

Edit – document can be printed, viewed and edited by recipient.

Anything with “Restricted”, will have its own license which should be consulted, as a fee may be payable to allow distribution, or it might be prohibited.

Font use and availability can be affected by how they are installed and how they are licensed. In these 2 posts will we comment upon their installation, and their distribution.

Fonts for use in eVo generated documents should be installed for “All Users”, and the license should allow for embedding or distribution within a document such as a PDF. We will address the second of these, distribution in a second post.

The correct way to install a custom font for use with eVo is, copy the font.ttf source file to a local temporary location, and then right click for the context menu. Do not simply choose install, as this will install the font for the logged on user only. Choose “More Options”, and then “Install for All users”.

The result is that the .ttf file is copied to the C:\Windows\Fonts folder, and the font is installed for all users of the server.

If we had chosen the “Install” option, it would have been installed to the user folder for the profile for the user in question, and only be available for that user, in this case me;

” C:\Users\Phil.Castle\AppData\Local\Microsoft\Windows\Fonts\”

Beware, as always with Windows there is a complication. If you simply navigate to Windows\Fonts in Explorer you will see all fonts, that your user has access to as if they were all contained in the folder. This is because the Font Folder is special. Here you see 2 fonts shown as a part of a family in Windows Explorer, one, Roboto Thin, installed just for me, and Roboto Regular, installed for all users.

but, as you can see they live in different places, and therefore have different usage permissions.

Service messages from Microsoft

19 September 2023 at 21:32 BST

Title: We’ve detected an increase in email message rejections from multiple providers

User impact: If action isn’t taken, bulk messages sent with large BCC recipients may be rejected.

Current Status: We’ve detected an increase in rejections of bulk messages from multiple email providers. Please review the above recommendations and documentation to adhere to the bulk messaging best practices.

21 September 2023 at 22:18 BST

Title: Reminder to authenticate outbound email with SPF, DKIM, and DMARC User impact: If your organization hasn’t already taken action, bulk messages sent with large BCC recipients may be rejected.

Current status: Based on customer feedback, we’ve refined our messaging to better reflect that we’ve learned of multiple email providers (Gmail, Yahoo, and others) rejecting bulk email sent from Microsoft 365 for some organizations, though not necessarily from your organization. This is a reminder that to increase deliverability of legitimate email to external recipients, it is important to authenticate your outbound emails. Information on how you can get started with email authentication in Microsoft 365 can be found in the corresponding link listed in the Additional diagnostics section of this message. Additionally, the non-delivery reports (NDRs) from these providers include details and best practices on how to deliver email to them. Please remember that Microsoft 365 is not to be used for bulk email relay, but in case the receiving email providers perceive your email as such, please read the limitations and guidelines for outbound spam protection listed in the Additional diagnostics section of this message.

Reminder to authenticate outbound email with SPF, DKIM, and DMARC

O365 admins can see full details here Service health – Microsoft 365 admin center

Further advice on successful sending of email via Exchange online (O365) from 21st September 2023 as issued by Microsoft – see link above for full content

Message Authentication, Reporting, and Conformance (DMARC) in Domain Name System (DNS), and you’re not sending a large rate or volume of email that exceeds the sending limits of the service, you’re not impacted and there’s no action required by your organization.

Senders will receive Non-Delivery Reports (NDRs) when sending messages that exceed the sending limits of the service. We recommend that senders don’t send a large rate or volume of email that exceeds the sending limits of the service. This recommendation also includes not sending email to a large list of BCC recipients. 

Avoid using addresses in your primary email domain (for example, contoso.com) as senders for bulk email. Doing so can affect the delivery of regular email from senders in the domain. Consider using a custom subdomain exclusively for bulk email. For example, use “m.contoso.com” for marketing email and “t.contoso.com” for transactional email. 

We recommend configuring any custom subdomains with email authentication records in DNS (SPF, DKIM, and DMARC). Many email service providers (for example, Gmail, Yahoo!, and Outlook.com) are configured to reject messages that don’t meet email authentication standards. 

Additional diagnostics
For additional reading and documentation on best practices, please review the links below.

Email authentication in Microsoft 365

Outbound spam protection

Prevent mail to Gmail users from being blocked or sent to spam