Many customers have been upgrading to our newer EPP 10.1 & EPP 10.2 service packs, and occasionally encountering errors when printing labels that contain special or accented characters. The refactored EPP Formatter, introduced in EPP 10.1.0.0, now correctly adheres to the ‘Character set’ definitions for EPP Data Dictionary variables.
When creating new variables in an EPP Data Dictionary, the default ‘Character Set’ option is “Alphanumeric”, which only allows standard ASCII defined characters and symbols. This primarily helps prevent scenarios where label data is sent to a printer that may not be able to support non-ASCII characters, without implementing custom/external font files on the printers.
Issue Identification
When reviewing the errored/failed print job on the EPP ‘Printer and Job Monitor’ OR ‘Reprint’ pages, users may see reasons like these below.
Example 1
A print request using accented characters in a customers name.
Reason: “Invalid parameter in VariableEntryParser (Customer): Invalid data [Amélie Poulain] for AlphaNumeric”
The above error example shows the “Amélie Poulain” data used for the ‘Customer’ variable is invalid, because the variable is set to AlphaNumeric. While the error reason is not specifying which characters are specifically failing, it is pointing out that some of the variable value is not compatible with the AlphaNumeric data expectation.
Example 2
While example 1 is pretty easy to understand at a glance, sometimes the invalid data coming from a customer environment won’t be as simple to figure out right away. Group separators [GS], record separators [RS], non-breaking spaces [NBSP] and other specialty characters have been found in some customers data; though on a web page or the EPP web portal, they may look like standard spaces or not be apparent at all.
Reason: “Invalid parameter in VariableEntryParser (Customer): Invalid data [Mystery Inc] for AlphaNumeric”
If the invalid character is not immediately obvious, then you can use the ‘Save to File’ button to download a JSON file containing all of the print job data. If you open the JSON file in an application like Notepad++, you can enable the ‘Show All Characters’ option to see special characters, like in this quick example below, showing an NBSP character where a normal space ought to be:
Example 3
Other difficult to identify scenarios we have seen are the use of specialty characters like the left and right apostrophe’s, which are different from the basic ASCII apostrophe character.
Reason: “Invalid parameter in VariableEntryParser (DSC1): Invalid data [Folate 5000 60’s] for AlphaNumeric”
In this scenario, the string in this variable assignment was not as easy to identify the non-ASCII data through the Notepad++, Show All Characters method, but there are other tools like this Unicode character identifier website, which identifies the characters entered/pasted into their input field.
With instances like these, customers can manually correct their backend data to be ASCII compatible OR change the EPP data dictionary variable properties so it does not block non-ASCII characters, in the designated print request variables.
Established Workaround
Using the “Binary” ‘Character set’ option, for EPP variable definitions, will take the assigned string data as-is, without erroring/filtering from data validations. We would recommend adjusting any variables that might be assigned special/foreign characters in print requests to use the “Binary” ‘Character set’ option.
