Created attachment 164829 [details]
Screenshot of the table in LO64

Created attachment 164830 [details]
Screesnhot in LO5

Created attachment 164831 [details]
Abiword

Created attachment 164832 [details]
Wordpad in Windows 10 (1909)

Created attachment 164833 [details]
Correct rendering in MSO Word

Created attachment 164834 [details]
Problematic File

Created attachment 164835 [details]
somewhat fixed file using an old LibreOffice version

Confirm with
7.1

Also in
LibreOffice 3.3.0 
OOO330m19 (Build:6)
tag libreoffice-3.3.0.4

@Miklos
Is there some way to validate RTF files; the bug rtf doc here is dubious quality wise.

I'm not aware of anything like that. If Word opens the file, we're expected to do the same.

(In reply to Miklos Vajna from comment #10)
> I'm not aware of anything like that. If Word opens the file, we're expected
> to do the same.

For the record: The file can be opened.. point is more how everything is presented on screen

Oooh, I just realize: the problem is not the content itself, it is tab character!

If it is replaced by a whitespace using search and replace it is /mostly/ correctly displayed. 

So basically it is in the file itself: \u8198\'20 which reads in the latest RTF spec 1.9.1 as following:

------------------------------------
\uN This keyword represents a single Unicode character that has no equivalent ANSI representation
based on the current ANSI code page. N represents the Unicode character value expressed as a
decimal number.
This keyword is followed immediately by equivalent character(s) in ANSI representation. In this
way, old readers will ignore the \uN keyword and pick up the ANSI representation properly.
When this keyword is encountered, the reader should ignore the next N' characters, where N'
corresponds to the last \ucN' value encountered.
As with all RTF keywords, a keyword-terminating space may be present (before the ANSI
characters) that is not counted in the characters to skip. While this is not likely to occur (or
recommended), a \binN keyword, its argument, and the binary data that follows are considered
one character for skipping purposes. If an RTF scope delimiter character (that is, an opening or
closing brace) is encountered while scanning skippable data, the skippable data is considered to
end before the delimiter. This makes it possible for a reader to perform some rudimentary error
recovery. To include an RTF delimiter in skippable data, it must be represented using the
appropriate control symbol (that is, escaped with a backslash,) as in plain text. Any RTF control
word or symbol is considered a single character for the purposes of counting skippable characters.

An RTF writer, when it encounters a Unicode character with no corresponding ANSI character,
should output \uN followed by the best ANSI representation it can manage. Often a question
mark is used if no reasonable ANSI character exists. In addition, if the Unicode character
translates into an ANSI character stream with a count of bytes differing from the current Unicode
Character Byte Count, it should emit the appropriate \ucN keyword prior to the \uN keyword to
notify the reader of the change.
Most RTF control words accept signed 16-bit numbers as arguments. For these control words,
Unicode values greater than 32767 are expressed as negative numbers. For example, the
character code U+F020 is given by \u-4064. To get -4064, convert F02016 to decimal (61472)
and subtract 65536.
Occasionally Word writes SYMBOL_CHARSET (nonUnicode) characters in the range
U+F020..U+F0FF instead of U+0020..U+00FF. Internally Word uses the values U+F020..U+F0FF
for these characters so that plain-text searches don’t mistakenly match SYMBOL_CHARSET
characters when searching for Unicode characters in the range U+0020..U+00FF. To find out the
correct symbol font to use, e.g., Wingdings, Symbol, etc., find the last SYMBOL_CHARSET font
control word \fN used, look up font N in the font table and find the face name. The charset is
specified by the \fch

------------------------------------

So as LibreOffice /seems/ not to identify \u8198 it should only display a whitespace.

I guess 8198 is that character https://www.codetable.net/decimal/8198 ("Six-Per-Em Space", but isn't this \u2006?!?).

So why do we not recognize that character? *g*

I forgot to mention: replacing the Unicode character + whitespace using search and replace (to whitespace) it looks nearly as good as in MSO Word!

Next question which come to my min: why is that six-per-em space not recognized as character separator? (yeah, I do know: another ticket!)

still broken / repro with

Version: 24.2.5.2 (X86_64) / LibreOffice Community
Build ID: bffef4ea93e59bebbeaf7f431bb02b1a39ee8a59
CPU threads: 4; OS: macOS 11.7.10; UI render: Skia/Raster; VCL: osx
Locale: de-DE (de_DE.UTF-8); UI: de-DE
Calc: threaded