Open dgutson opened 2 years ago
Not sure if related to #61
When the given example is reduced to a Short, Self Contained, Correct example:
@startuml
(A) -> (B): "one\ntwo"
(C) -> (D): "<b>one\ntwo"
(E) -> (F) : "<color:#707070>one\ntwo"
@enduml
One can see that the difference is not the font weight (i.e. "bold") but the font color (i.e. "black").
As far as I am aware, the font style reverting to default after a newline/linebreak is expected behaviour.
(I could be wrong, that is for @arnaudroques to decide).
The solution for the second line also being colored #707070
is to declare the color again for that line:
@startuml
(A) -> (B) : "<color:#707070>one\n<color:#707070>two"
@enduml
Or using a stereotype:
@startuml
skinparam arrowFontColor<<gray>> #707070
(A) -> (B)<<gray>> : "one\ntwo"
@enduml
Regarding
Not sure if related to https://github.com/plantuml/plantuml-stdlib/issues/61
Although the source of the issue is the same, the behavior described in #61 is a bug in the downstream project.
I have created an issue to address the problem in C4-PlantUML in that repo: https://github.com/plantuml-stdlib/C4-PlantUML/issues/255
As far as I am aware, the font style reverting to default after a newline/linebreak is expected behaviour.
(I could be wrong, that is for @arnaudroques to decide).
You are right, that's the point. The font style is reverting to default after a newline. I realize that is not a standard behaviour. The initial intention (10 years ago?) was to keep syntax as short as possible so that people that actually type diagrams on keyboard do not have to close tags. The implementation was also simpler.
Now changing this would have too many impacts so I'm afraid we have to live with it. I hope this is not a major issue, since the workaround is, as you said, to repeat color definition.
Thanks folks for the explanation, the workaround, (and the link for self contained.. :) ). I must admit that this is completely unexpected for the terrestrial user, which unless comes here and reports this and have nice maintainers to explain, it would have been never solved.
May I propose a function call to disable this behavior? Like HIDE_LEGEND()
but for this one, and have this documented somewhere?
Maybe something like KEEP_STYLE_ON_BREAKS()
That would preserve compatibility, avoid the verbosity of repeating the tag after each \n (or \l or \r, all things I tried).
BTW CC @simonbrowndotje because I think the workaround should be implemented in the exporter of structurizr.
Given
Output is:
Note that
two
is darker thanone
.