New line in table built with variables broken [from 1.2020.20]

0 votes
asked Nov 23, 2020 in Bug by The-Lu (60,440 points)

Hello PlantUML team,

Here is an issue reported (by Jesper) on:

with a broken example from 1.2020.20:

[See on PlantUML server]

Thanks for your support,

commented Jan 20, 2021 by
Not good. It destroyed a lot of existing code.

2 Answers

0 votes
answered Nov 26, 2020 by plantuml (293,520 points)

We have added a function %newline() that output a new line :-)

So now you should use :

!global $table = "|= Field1 |= Field 2 |"
!procedure $row($value1, $value2)
%set_variable_value("$table", %get_variable_value("$table") + %newline() + "| " + $value1 + " | " + $value2 + " |")

$row("1", "2")
$row("3", "4")

rectangle r [
<i>on rectangle:

commented Nov 26, 2020 by The-Lu (60,440 points)


That is good.... but this new feature is not so so good...

That broke also all the new line on multi-line label!

Here are some other similar issue:

1/ Minimal example

node n [

2/ Example with procedure...

Where for example, we does not manage the argument value directly... and the presence of newline on the argument...

!procedure $foo($as, $label)
  node $as [
    The label is:
    other data

$foo("a", "<color:red>aaa\nbbb")
$foo("b", "label without newline")

See also other broken examples:

I understand the difficulty about newline management... between inline and multi-line... but...

→ What are changes since last version ?

Thanks for your support...

commented Nov 28, 2020 by plantuml (293,520 points)

I understand the difficulty about newline management... between inline and multi-line... but...

Yes, it's a mess :-)

In hindsight, it was a bad idea to interpret "\n" as "newline". We did so because it was the usual way but it has become an issue when users want to actually print \n.

So, as advice, do not use it too much : it's probably going to be removed in the future.

We are still looking for a replacement for "\n" as "newline". What about <+newline> or <U+newline> or <U+NL> ? This is completely non standard, but this way, there will be not confusion between PlantUML language and all other programming language.

We are also thinking about implementing triple quote string.Do you thing it's a good idea ?

commented Dec 2, 2020 by The-Lu (60,440 points)

Hello PlantUML,

Thanks for your answer.

In fact, the main issue is that when we does not know on which context a string or a variable will be used, as:

!$var=" aaa \n bbb \n <u:blue>ccc \n <color:green>ddd <U+000A> eee"

node "$var" as a

node b [
on multi-line context

node c [

[See on PlantUML server]

For the question:

What about <+newline> or <U+newline> or <U+NL> ?

Why not use ... the normal Unicode  <U+000A> ('LINE FEED (LF)' (U+000A))
But on the example, the value is not evaluate. Why ?

Then implementing:

are perhaps a good news... in order to suppress the evaluation of  '\n'...
And I think that is similar question/issue on ‘JSON’ side (where ‘\n’ is an escaped value for newline, and must be evaluate [or not]...)!

See also discussion on the same subject:

If that can open an open discussion,

commented Dec 9, 2020 by anonymous
Why not just saying that '\' is an escape character, so if you write '\n' the n is escaped and interpreted as a new line:

foo\nbar is always rendered as



and if you do not want it to be interpreted escape the backslash with a second backslash '\\n'

foo\\nbar is always rendered as

commented Mar 14 by anonymous

Escape the backslash with another backslash if you do not want it to be read as such.

commented Jul 7 by Allen (100 points)

If the new line in a table built with variables appears broken, ensure that the variables containing the table content are properly formatted with appropriate line breaks or HTML tags. Verify that the table structure and formatting are correct to ensure the desired line breaks are displayed correctly within the table.

0 votes
answered Jun 14 by anonymous

In actuality, the biggest problem arises when we are unsure of the context in which a string or variable will be utilised.

commented Jul 17 by Allen (100 points)

On the "JSON" side, I believe there is a related query or problem (where "n" is an escaped value for newline and must be evaluated [or not]).