When working with rich text components in Appian, I encountered issues with displaying special characters correctly, particularly backslashes (\) and other escape characters like tabs (\t) and newlines (\n). These characters can be misinterpreted or escaped incorrectly, leading to incorrect rendering in the interface.
\
\t
\n
Consider the following example, where you have a string containing file paths with backslashes that you want to display in an a!richTextItem component:
a!richTextItem
"File Path:\nC:\Users\tUserXyz\Documents\Project\file.txt\tAnotherPath:\nC:\Users\nUserXyz\Documents\Report\report.txt"
Actual Output: "File Path: C:\Users UserXyz\Documents\Project\file.txt AnotherPath: C:\Users UserXyz\Documentseporteport.txt"Expected Output: "File Path: C:\Users\tUserXyz\Documents\Project\file.txt AnotherPath: C:\Users\nUserXyz\Documentseporteport.txt"
The issue arises because backslashes and other escape characters are special characters used for escaping other characters. When not properly escaped, they can be misinterpreted, leading to incorrect rendering. For example:
To correctly display these special characters in rich text components, I attempted to use the substitute function to replace each escape character with its intended representation.
substitute
Here’s the approach I took:
Escape Special Characters in the Source String: Used the substitute function to replace each escape character with its intended representation.
Use the Correct Substitution Pattern: Ensure that the substitution pattern correctly handles \n, \t, and \.
Here’s an example implementation demonstrating how I tried to handle special characters, particularly backslashes, tabs, and newlines, in an a!richTextItem component:
a!localVariables( local!formattedText: substitute( substitute( substitute( substitute( ri!inputText, "\n", char(10) ), "\t", char(9) ), "\\", char(92) ), "\r", "" ), local!formattedText )
Despite implementing the above approach, I still face issues with displaying special characters in file paths fetched from an API. If anyone has encountered similar issues or has suggestions for handling these escape characters more effectively, please share your insights or solutions.
Discussion posts and replies are publicly visible
I attempted the scenario as is and its working for me. \n, \t all are visible appropriately in the rich text display field. May be just check if the variable you are passing in the richtextitem() is having file path as intented or not.
I have updated the string
Few questions:
1. In the Actual/Expected output above - looks like you want to subjectively handle \n, \t etc.
The expected output shows \t and \n in the string
File Path: C:\Users\tUserXyz\Documents\Project\file.txt
Another File Path: C:\Users\nUserXyz\Documentseporteport.txt
So my understanding is these are expected in the directory path but not before and after.
Do you want to remove just the highlighted ones from ri!inputText?
2. You mentioned API sends the file path. Can you elaborate on any operation you are doing on the API response to achieve this inputText or API is returning the file path entirely in this format
For the questionsYes, the API is returning the file path entirely in this format.
The API is returning around 10,000+ character texts, and in those, there are multiple t and n, as well as the file paths, so I have only mentioned the file path example.
But there is no fixed word before a file path, "File Path:" will not always be there.
Overall the issue doesn't lie with rich text field with respect to handling special characters. Your use case is peculiar because the response you are working with is using same characters within file path as well as before or after the paths. There is a lack of pattern in the data basis my understanding so far.
To work with this sort of data you definitely need to structure your data somehow. May be you can find a character set which can help split the paths with other texts. Then you can leave the paths as is and just perform operation on the other text strings.
Without a unique pattern identification system wont be able to keep some \n, \t and strip out others. It will either keep them all or remove them all. So identifying a pattern should be first step to conditionally handle these characters.