NoteFontSize skinparam for stereotype ignored

[clarkcutler]

Problem:

• Skinning the font size for a note stereotype doesn't seem to have any effect

Related features that do work as expected:

• Skinning background color and font color for note stereotypes
• Skinning the font size for a plain note (without stereotype)

Example UML illustrating the issue:

@startuml
skinparam NoteBackgroundColor green
skinparam NoteFontColor red
skinparam NoteFontSize 30
skinparam NoteBackgroundColor<<test>> yellow
skinparam NoteFontColor<<test>> blue
skinparam NoteFontSize<<test>> 50

Bob -> Alice : hello
note over Bob: test note 1
note<<test>> over Bob: test note 2
@enduml

Result:

I'd expect the text "text note 2" to be bigger than "text note 1" (50 vs 30), but it's the same size.

[arnaudroques]

Thanks for the report.
Believe it or not, this issue is not that easy to solve. Furthermore, we are developping a new style for fonts/colors (see http://plantuml.com/style-evolution ).
So we do not want to spend to many time on code that will be removed in some future.
And since we want to be backward compatible, you can enable the new style system. This way, your example is working :

@startuml
skinparam useBetaStyle true
skinparam NoteBackgroundColor green
skinparam NoteFontColor red
skinparam NoteFontSize 30
skinparam NoteBackgroundColor<<test>> yellow
skinparam NoteFontColor<<test>> blue
skinparam NoteFontSize<<test>> 50

Bob -> Alice : hello
note over Bob: test note 1
note<<test>> over Bob: test note 2
@enduml

Some day skinparam useBetaStyle true will be the default value, so you won't need the line anymore.
Is this an acceptable workaround for you ?

PS: the new syntax is:

@startuml
skinparam useBetaStyle true
<style>
sequenceDiagram {
  note {
    BackgroundColor green
    FontColor red
    FontSize 30
    .test {
      BackgroundColor yellow
      FontColor blue
      FontSize 50
    }
  }
}
</style>

Bob -> Alice : hello
note over Bob: test note 1
note<<test>> over Bob: test note 2
@enduml

[The-Lum]

Hi all,

[This is an Issue Review]
This is now fixed.

• Thanks @clarkcutler for the report.
• Thanks PlantUML team for your work.

Regards.