The problem is in the Sütterlin font.
I opened it with FontForge and I immediately got warnings and errors. Minor warnings are about discrepancies in copyright notice and various names between Mac and Windows table entries (since these are rather comments, they can be ignored).
More serious “errors” involved the dictionary of glyph name and their encoding. This is how I interpret them.
The font is copyrighted 1995 to R. G. Arens. At that time, Unicode was not yet universally adopted by all OSes and computers. It is then likely this is an 8-bit font in ISO-8859-like encoding (the famous Windows page codes).
This suspicion is confirmed by the fact that the font contains less than 256 glyphs (max capacity in 8 bits minus the C0 and DEL controls which are omitted). What makes me confident in this guess is that the C1 controls series has been used to stuff more graphic characters because the standard areas 0x20-0x7E and 0xA0-0xFE were already full. The encoding led to a name in the dictionary (and reciprocally) which in turn provides a pointer to the glyph (for rendering).
This font has been “Unicode-ised” in a quick’n’dirty way. The Unicode dictionary (like SPACE or LATIN CAPITAL LETTER A) has been tweaked so that SPACE is no longer associated with U+0020 but with U+F020 (and so forth for the other characters). The normal behaviour of any font rendering engine is to use a character in some adequately font for missing glyphs (Serif or Sans families according to the advertisement in the font tables). Thus you type Russian text while in Sütterlin and get Cyrillic letters.
Unfortunately, the dictionary offsetting for “standard” characters seems to be an unsupported practice. FontForge warns against this dictionary abuse and very likely not all font renderers can manage such non-conforming font. I suppose that the one used in AOO preprocesses the font so that the glyph at U+F020 which is referred to with the SPACE name is in fact repositioned to the standard SPACE index of U+0020.
Strangely enough, the U+F000 to U+F0FF private use area is qualified “Microsoft Symbol Area” by FontForge when editing this font.
I don’t think there is a bug in LO, nor in its font engine (Harfbuzz?) when presented such a distorted font.
I suggest you contact Herr Arens if you can to ask him to change his font to some more conformant encoding. Only a few “extra” characters should be sent to the private use area (only those which cannot be considered as a graphical variant of the corresponding LATIN [CAPITAL] LETTER x like long-s (or round-s if preferred) so that you type with the usual keyboard to encode the usual letter, the font being responsible only for the shape).
Another fix would be to use a font editor (like FontForge under Linux) to reallocate the glyphs in ASCII and Latin-1 areas. I have tested it, it works. However, before doing this task, you must think about the glyphs which have been allocated to the C1 range (0x80-0x9F). These are strictly controls in Unicode and can’t be used for displayable shapes. They must be allocated to available locations in Unicode, probably in private use areas. This means you must carefully plan this because it involves maybe not-so-user-friendly typing sequence to access them. This may also break already typed tetx.
To show the community your question has been answered, click the ✓ next to the correct answer, and “upvote” by clicking on the ^ arrow of any helpful answers. These are the mechanisms for communicating the quality of the Q&A on this site. Thanks!
In case you need clarification, edit your question (not an answer) or comment the relevant answer.
