In reply to: Martin Meze (Freelancer)
The reason is CSS. Please note the difference in the two attached images. One is with the default settings. In the other I added the "white-space: break-spaces;".
Hi Everyone,
I don't think that CSS will have anything to do with it, at least not the one from the browser, rather one from e-mail formatting, but it doesn't look like that.
It's displayed the same in preview, even after removing standard e-mail content, and just inserting two attributes. (e-mail preview/content.png)
I've created a sample form with 2 attributes - Long text, one formatted (called format), second one without formatting (called format - no). Both with append mode. Configuration in attachment. For those I've saved a sample form, to get values in database, and i read them with this query:
SELECT
WFD_AttLongX AS format,
WFD_AttLongY AS [format - no]
FROM
WFElements
WHERE
WFD_ID = {insert id}
This query returned how the data is stored, and this will get us answer what's happening. Result is available here: https://pastebin.com/1NnSTiWq.
I've opened that .json in VSCode, and turend on *Render whitespace* setting (Results - vscode.png).
If the field doesn't allow formatting, then new lines are stored as \n, so a standard new line character. That's why email preview for this field is ok - no double new lines.
If the field allows formatting, then new lines are stored twice as U+00a0 (unicode no-break space) which is wrapped in tags, creating new line. Thats one line, but we are also wrapping each line in separate tags, which are rendered as separate lines in HTML.
test1test1 -- this will be two lines, separated with br
U+00a0 -- this is an empty line
test1 -- line with text
U+00a0 -- this is an empty line
test1 -- line with text
You could create a business rule with SQL like this one:
SELECT REPLACE('{BRP}', '\u00A0', '')
{BRP} is a buisiness rule parameter, and this should fix the issue :)