Changes like this would be a lot easier, if I had any knowledge about how the text positioning works. Up to now all such changes were made by namida. Although I suspect that it is possible to have half-line gaps, I am not even totally sure the current text-writing method actually supports this.
It does. #13 in the internal text string represents a full new line. This is expected behaviour. (Note that the code does NOT recognize #10. This is how Lemmix was written and I just never changed it. Supporting #10 as well would be easy to implement - TGameBaseScreen.DrawPurpleText, in the "case" statement, change "#13" to "#10, #13". With that being said, this does not affect files - the text-format file parser can handle any common line ending. The supporting-#13-only is ONLY relevant to the input strings for drawing menu screen text.)
However, during development of the talisman screen, I needed - and thus implemented - a "half new line", which uses #12. This works the same as a regular new line, except the text position is only moved down half a line for the next line. If you do something like "This is#12a test", there'll be a bit of overlap between the two lines. But if we have a case that's currently "This is#13#13a test", that would currently produce "This is", followed by a blank line, followed by "a test". If we change this to "This is#13#12a test" (or #12#13, doesn't matter), the result will be the same but with only a half-line gap between them.
So basically - support for half-lines is there, the preview screen's text just needs to be modified to make use of it.
In the case of the preview screen, TGamePreviewScreen.GetScreenText is where you want to look. The code that generates the talisman graphic / text is conveniently seperated into a sub-function, so you don't need to worry about breaking that.
Do note though - this function or rendering functions do NOT automatically add padding lines; they are achieved by adding extra blank lines when constructing the text.