Thanks for attaching the screenshot. The Flex software appears to be writing out the document with one line of output ending in a line feed character (U+000a) which looks like ↵ rather than a carriage return (U+000d) which shows as a pilcrow ¶. There is quite a bit going on so I will explain what I am seeing.
All of the lines as you say are being generated with a single space prior to either mark (line feed or carriage return). The space is not ideal for line breaking but it may be used in your case to ensure that a character style terminates. Each of the lines (e.g., ab gag zamar | rainbow | renbo | ñe modao: bel halaizomar) appears to be set in a different style, with the last and sometimes first having a pair of different styles. In the example as shown this can only be effective if character (rather than paragraph) styles are used as a line feed does not terminate a paragraph style. So that may be why a leading space precedes each newline character (line feed, carriage return, etc.)
As to why the line feed character is being treated the way it is I can surmise that Word has special handling built into it that overrides the default Unicode interpretation of these characters. An example from your screenshot which exhibits the problem (e.g., “man who is bad, physically or morally ↵ man nogut”) is essentially a single paragraph as only a carriage return is interpreted as being a paragraph terminator. In this context the line feed is simply treated as a separate character or word like “a”. The space and line feed (LF) characters both have a neutral binding so SPACE+LF occuring at line end can be broken / split. This behaviour seems consistent in LO in terms of ODT/DOC/DOCX all be treated the same way. MS Word probably treats SPACE+LF as a single unit / word i.e., as a special case.
Is it possible to get the Flex software to write out the file without a leading space, or better yet with all lines using a carriage return rather than one using a line feed?
