I used OCRTEXT() which appended a LF (0x0A) character to the OCRed string.
In the View (Form) a character was present but was transcoded as a space (0x20).
It seems that explicit comparatives also do the transcode, so that TRIM() would not get rid of the LF and ENDSWITH() did not think it was a space (as expected) but the following did (where " " contains a space):
IF (RIGHT ([OCR Text], 1) = " ",
LEFT([OCR Text], LEN([OCR Text]) -1),
[OCR TEXT]
)
The solution was to check what was being stored at the back end and put an explicit newline in a string substitution as follows:
SUBSTITUTE([OCR Text], "
", āā).
Note that Excel column filtering also identified the LF as a space but decoding the string revealed it was a LF.
Iām concerned that the SUBSTITUTE() may not have consistent behaviour on all browsers/architectures because newline might be CR, LF or CRLF (no idea what happens on real phones), so if anyone can clarify that would be appreciated.