As suggested by @josephcsible in #296:

If we're going to make \n be a newline, we should also make \\ be a literal backslash so that it's possible to display a literal \n.

It is also advisable to add a new line alignment symbol.
(This alignment inherits the next line)
"\n\<" for "New Line Align Left"
"\n\|" for "New Line Align Center"
"\n\>" for "New Line Align Right"
"\t" for "Tab"
Ex:

Test Text:\nline1\n\>line2\nline3\n\|line4

Test Text:
line1
     line2
     line3
  line4

\t makes sense, but the others don't.

I want display

--Summon--
  Zombie

--Summon--
   Cow

What is the problem?

It was a bad idea as originally written due to how escape sequences work, but it's reasonable now that it's edited.

Do not use escaped symbols instead of using string format variable card?

Are you saying we should add a "format" operator, and process escape sequences there instead of in displays? I like that idea. It makes it less likely for a name or something to accidentally trigger an escape sequence.

@Flithor Supporting custom alignment would be very tricky to do, because we're using Vanilla's FontRenderer, which has no support for this. So this won't be on the roadmap in the near future, perhaps when I get around to implementing some kind of advanced display panel.

Consider working with RFTools?
Its screen supports alignment.
In addition to not support the newline, the other performance is quite good

• Or require RFTools to add "ID Proxy model". (Recommend)
• Allows the screen to connect to the ID network.

@Flithor That's easier said than done ;-) But yes, that would be a nice feature, I don't think I'll ever be able to implement that though.

So you still insist realization it on the original ID?
Not consider linkage with RFTools ?
(My English not good, maybe misunderstood what you mean.)
Its seems that have no conflict between them.
If both can be achieved, it will be very great.
(In fact, I think, you are same as the RFTools' author, are the "Data Nut(Crazy about data)".)