Unfortunartely it’s much more complicated, and there are many details I also don’t know. In addition there were case where I “researched” into the details, and had to accept that some were changed later without notice. There are bug reports and enhancement requests concerning the field (some reported by myself). A very old one concerning RegEx in Calc and also the special control \n
is tdf# 43107. The actual (7.4.1) behavior is even worse in a detail: The young REGEX() function doesn’t replace with \n
, but with n
, and by that cover the tracks. The mentioned bug, however, never was assigned or marked “RESOLVED”.
“Why can’t Calc do something, Writer easily can?”
Well, neither Calc nor Writer do the labor. Concerning the handling of Unicode
LibO generally doesn’t work with routines of their own development, but use tools provided by ICU
. The different and partly erroneous behavior depending on the component class and other aspects, however, is actually LibO-made.
This was a kind of challenge, and I therefore didn’t only invent a workaround using the old Feynman trick, but also wrote code (accompanied by some tools from my Basic-box)
- to give a possible solution for those ready to resort to user code
- to demonstrate the rather deep cause of the issue - as I see it.
See this attachment: replaceRegExFindingsWithLineFeeds.ods (22.2 KB)
My best advice: Omit Line breaks in spreadsheet cells.