label positioning wrong in linetype ortho

[LimitlessGreen]

Pls correct the label positioning in the orthogonal line mode.

---

For example:

@startuml
skinparam linetype ortho

(Pro-\nzess) as proc
rectangle "Komponente1" as k1
rectangle "Komponente2" as k2
rectangle "Komponente3" as k3
rectangle "Komponente4" as k4
rectangle "Komponente5" as k5
rectangle "Komponente6" as k6

proc -up-> k2: Datenfluss1
proc <-up- k2: Datenfluss2

proc -up-> k1: Datenfluss3
proc <-up- k1: Datenfluss4

proc -right-> k3:Datenfluss5
proc <-right- k3:Datenfluss6

proc -down-> k4: Datenfluss7
proc <-down- k4: Datenfluss8

proc -down-> k5: Datenfluss9
proc <-down- k5: Datenfluss10

proc -left-> k6: Datenfluss11
proc <-left- k6: Datenfluss12

@enduml

Outputs:

---

Now the labels are far away from the lines and label 5, 6, 11 and 12 aren't there.

[albert-github]

Looks like it has to do with skinparam linetype ortho When this is disabled the 5,6,11,12 labels are shown and the other labels are on the same place but due to the disabled skinparam linetype ortho they are next to the line. Looks like the calculation of the label position is done for the 'non-ortho' line type.

[Godsmith]

I'm also affected by this bug.

This thread here seems to indicate changing from GraphViz labels to xlabels might help: http://forum.plantuml.net/1608/is-it-possible-to-only-use-straight-lines-in-a-class-diagram

I don't know enough about neither PlantUML nor GraphViz to test this out however.

[droogmic]

The location in code is: https://github.com/plantuml/plantuml/blob/4cad5546ac72871deca19e0fb4a43953ce6a473e/src/net/sourceforge/plantuml/svek/Line.java#L413

But I don't know what the if condition is checking for.

[Benjosh95]

Would be amazing, if this bug could be fixed asap. +1 Pls correct the label positioning in the orthogonal line mode.

[flerro]

@droogmic graphvizVersion.useXLabelInsteadOfLabel() will always return false

https://github.com/plantuml/plantuml/blob/301fd18b2fe87e3482bd48b0e9670e827a836b20/src/net/sourceforge/plantuml/cucadiagram/dot/GraphvizVersionFinder.java#L95-L99

Changing the return value to true will alleviate problems with labels, but it will easily break something else.

In addition dotMode will be equal to DotMode.NO_LEFT_RIGHT_AND_XLABEL only if error occurs (if I understand well)

https://github.com/plantuml/plantuml/blob/301fd18b2fe87e3482bd48b0e9670e827a836b20/src/net/sourceforge/plantuml/svek/CucaDiagramFileMakerSvek.java#L104-L117

[DaHoC]

This is even worse for ER diagrams, as it is swapping the cardinality label:

@startuml
skinparam linetype ortho

Entity01 "m" }|..|| "1" Entity02
Entity03 "0..m" }o..o| "0..1" Entity04
Entity05 "1" ||--o{ "0..m" Entity06
Entity07 "0..1" |o--|| "1" Entity08
@enduml

yields

[Iron-E]

Like @DaHoC, I am also running into this issue. It frequently swaps which positions the label is on, and also doesn't show in the correct position, rather it floats off in space where the line would be if ortho weren't specified.

[devantler]

I think this is related to weird arrows as well. I experience this when using the lollypop notation interfaces:

When making bigger diagrams, this is much, much worse! Sometimes there are like 1-2 centimeters between the interface and the arrow.

[johnholliday]

Struggling with this for quite a while. Any progress on this issue?

[mbajolek]

As far as I understand in many cases using XLabel mode would help. I'm thinking if it would be possible to provide xlabel on/off toggle via e.g.: java property or pragma directive? This would be opt-in feature that one can enable for particular diagram[s].

[SirHodlington]

Also struggling with this. It's a real problem in larger charts.

[rtuin]

Is there a work-around available for this?

[paulooliveira]

Same problem here, this makes "skinparam linetype ortho" nearly unusable, any work around? Tnx.

[BuzzwordChief]

+1

Please add at least a note to the documentation that this feature is not usable for complex diagrams and named connections.

[swmatisa]

Dear PlantUML team, Could you give a class name or something to try to find the problem and solve it? The problem is well defined and reproducible: https://forum.plantuml.net/12543/label-position-not-correct-in-entity-diagram Thanks for your support

Le lun. 29 mars 2021 à 19:31, David May @.***> a écrit :

+1

Please add at least a note to the documentation that this feature is not usable for complex diagrams and named connections.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/plantuml/backlog/issues/11, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALGQADBSFGAS7KGB7AGEB4LTGDBQJANCNFSM4F4J3E2A .

[arnaudroques]

This bug is complex and difficult to understand. It's probably a mix of GraphViz issue and/or PlantUML issue.

If you want, you can help us to investigate :-)

You know that PlantUML is based on GraphViz. If you run PlantUML locally and if you add the special directive !pragma svek_trace on PlantUML will generate in your local folder two intermediate files:

• svek.dot : intermediate file in "dot" language provided to GraphViz
• svek.svg : intermediate result file which is going to be parsed by PlantUML to retrieve element positions.

So if you run this locally:

@startuml
!pragma svek_trace on
skinparam linetype ortho

(proc) as proc
rectangle "Komponente1" as k1
rectangle "Komponente2" as k2
rectangle "Komponente3" as k3
rectangle "Komponente4" as k4
rectangle "Komponente5" as k5
rectangle "Komponente6" as k6

proc -up-> k2: Datenfluss1
proc <-up- k2: Datenfluss2

proc -up-> k1: Datenfluss3
proc <-up- k1: Datenfluss4

proc -right-> k3:Datenfluss5
proc <-right- k3:Datenfluss6

proc -down-> k4: Datenfluss7
proc <-down- k4: Datenfluss8

proc -down-> k5: Datenfluss9
proc <-down- k5: Datenfluss10

proc -left-> k6: Datenfluss11
proc <-left- k6: Datenfluss12
@enduml

You will get the following result.

Notice that there are only 8 black rectangles, corresponding to the 8 labels of the original post. Since PlantUML is parsing this SVG file, labels are missing.

Now if you remove splines=ortho; in the dot file, you've got this.

Now you have 12 black rectangles: the bug is gone.

So I think it's a GraphViz issue, because changing splines mode should not remove labels.

However, if you find a workaround in manually editing the "dot" file keeping splines=ortho so that all 12 labels are displayed, we will be glad to modify our own code to generate a working "dot" file.

[swmatisa]

Thanks for the time to explain the problem and for your help. I do some tests and you are right: it is a Graphviz problem.

Graphviz has a lot of problems with ortho and nobody knows how it should work... In my tests I discover that there is crashes with simple diagram like digraph unix { nodesep=0.486111; ranksep=0.833333; remincross=true; searchsize=500; splines=ortho; sh0004 [shape=rect,label="",width=1.041667,height=0.666667,color="#000004"]; sh0005 [shape=rect,label="",width=1.041667,height=0.666667,color="#000005"]; sh0006 [shape=rect,label="",width=1.041667,height=0.666667,color="#000006"]; sh0007 [shape=rect,label="",width=2.013889,height=0.666667,color="#000007"]; sh0007->sh0004[arrowsize=0.5,minlen=1,color="#000008",label=<<TABLE BGCOLOR="#000009" FIXEDSIZE="TRUE" WIDTH="28" HEIGHT="34">>,taillabel=<<TABLE BGCOLOR="#00000A" FIXEDSIZE="TRUE" WIDTH="7" HEIGHT="16">>,headlabel=<<TABLE BGCOLOR="#00000B" FIXEDSIZE="TRUE" WIDTH="7" HEIGHT="16">>]; sh0007->sh0005[arrowsize=0.5,minlen=1,color="#00000C",label=<<TABLE BGCOLOR="#00000D" FIXEDSIZE="TRUE" WIDTH="21" HEIGHT="18">>,taillabel=<<TABLE BGCOLOR="#00000E" FIXEDSIZE="TRUE" WIDTH="7" HEIGHT="16">>,headlabel=<<TABLE BGCOLOR="#00000F" FIXEDSIZE="TRUE" WIDTH="7" HEIGHT="16">>]; sh0007->sh0006[arrowsize=0.5,minlen=1,color="#000010",label=<<TABLE BGCOLOR="#000011" FIXEDSIZE="TRUE" WIDTH="61" HEIGHT="18">>,taillabel=<<TABLE BGCOLOR="#000012" FIXEDSIZE="TRUE" WIDTH="7" HEIGHT="16">>,headlabel=<<TABLE BGCOLOR="#000013" FIXEDSIZE="TRUE" WIDTH="7" HEIGHT="16">>]; }

https://gitlab.com/graphviz/graphviz/-/issues/1658 I am very worried about the future of Graphviz. We need to find someone who can understand these algorithms and fix these bugs. This will be a problem in the future.

Le mar. 30 mars 2021 à 19:12, arnaudroques @.***> a écrit :

This bug is complex and difficult to understand. It's probably a mix of GraphViz issue and/or PlantUML issue.

If you want, you can help us to investigate :-)

You know that PlantUML is based on GraphViz. If you run PlantUML locally and if you add the special directive !pragma svek_trace on PlantUML will generate in your local folder two intermediate files:

• svek.dot : intermediate file in "dot" language provided to GraphViz
• svek.svg : intermediate result file which is going to be parsed by PlantUML to retrieve element positions.

So if you run this locally:

@startuml !pragma svek_trace on skinparam linetype ortho

(proc) as proc rectangle "Komponente1" as k1 rectangle "Komponente2" as k2 rectangle "Komponente3" as k3 rectangle "Komponente4" as k4 rectangle "Komponente5" as k5 rectangle "Komponente6" as k6

proc -up-> k2: Datenfluss1 proc <-up- k2: Datenfluss2

proc -up-> k1: Datenfluss3 proc <-up- k1: Datenfluss4

proc -right-> k3:Datenfluss5 proc <-right- k3:Datenfluss6

proc -down-> k4: Datenfluss7 proc <-down- k4: Datenfluss8

proc -down-> k5: Datenfluss9 proc <-down- k5: Datenfluss10

proc -left-> k6: Datenfluss11 proc <-left- k6: Datenfluss12 @enduml

You will get the following result http://www.plantuml.com/plantuml/uml/jPNlQwCm6CVVzw-Gt5klUwAnHjO8Q-lMmc3GyxZZnhrm6cQOZH8Tkn_S_txERJrwiAPW4b1v4lBDz_F49od4lSgQqdcKueVpUoBhWhUyOJ0bT8OnFf-eJ3wyz53_kVKzV2TahkgsPPrwvEUJbcSgBrlnYxC0e8-RIaZUibfrPTs79G06vxOjiuOpnVFEhR8xNZ64t2THT2N3qm2UcrjoSLzs_Lg1v_c1v-PrLIk6FWoZ5-Yx1J48nei5TiHcuyLcTiJ8ntZuXhUPKlNJiFNz77SdPCKbWuDvU85UrvlFqul5TU8ihfOtrpVRj_4bSYutNvFLfystXA5q-pb1pfVDAbqp509oridcQfqoX2cAv-csVrRn_EpbrKTdWsOSl-EjoqJ5-AxfVhf3NFAiOBAMt2s4OdTP_k2Umd1vdC43ammONXc8IGRVFyxWaoCCuLW6ZRTGuusQz0RahHXuLOccvV_N0qpfB0AW_-g1U967oM4za7qzXEEBAzoBqV5YT2yMZHUBzc8pCxybFjJN70zWzdWuPD1vqvGz1gFU0XlvnRw6WTXaq7WBDTwebQk1dkBDq-JD8tQycTnxBzGmsCblT59-5nflIvlU3ELNSpxuOEhQclpv2m00 .

Notice that there are only 8 black rectangles, corresponding to the 8 labels of the original post http://www.plantuml.com/plantuml/uml/RT3FQWCX4CVnkqyXERM7G7N_j0sbvD1RdqAIINPPTnITfVJjYnriL_4cVFZAZpb7Ce6srOgupEXDCAkqCm9zUv0kqEI4UF31NHwbYJ8zH80B6RnRa8TFjtg7W0Jga7nHRTMikgqTQzVMdhLlwy0wj7La7OL8o-LnyyTtkUYJ_304UBDRZ8hfBLb5kipKtheYAwZFMPZl4wMoE_tha4FM4l-6NjqNfhBVV_oSqr-jy4NKxR3drx8jKJtbriADKZiMd6_4NAiMPy3hjjeV. Since PlantUML is parsing this SVG file, labels are missing.

Now if you remove splines=ortho; in the dot file, you've got this http://www.plantuml.com/plantuml/uml/jPLTQzim68Nl_IkCTkjbaYp7CebCcyHj0eL2vh6niWlL5hMeFupiq7sm_pxNRHCoQ1ImR8X297HodbS-howQbgjsL-HMAXyKhpDxLygVzX-hh5BHY9h12Q5JXD3CKhnyV9cXxlFJpOX2becgceQrQYTcLYEuIh96_XRCWt1cMKq68OBsNPFnMZ0bajR9-Rt86G3EaqpRZA691vyV9nFo8MixTGzZryDEKkMLOk13lte9VipCYq5lk9WtZjXqkDXq737oCUo__JkkLFNK7tQtnobacOkImQDzQ05U_sy-ZoyNDv6zk5xUtjnktzQNmBxQV8jMdpVV8mRYxPS8s5ytgtZDW0-1lOusr-kO0KH1E8-ttMSLpZ-z3Djkw3N3y1rlBPSv4qNT_dBwtvdWAIkhKZYfLEoU9u_EEGnNfnamDCc0u2i3CSdWkgSPN7A2mH_4eFVcQxnHazuWUGk3o7DPD-B_FC09dGOGqaCU20um8iTv8Fiy-CF3vU_5w70nkXSBXei5XnvYvhL4n_gQzW1DjeTZ1hqtJUmHDEhD6wE-oDKmaD4OzDvyZJSwojL0p_66DNN3P4nlPiuU-ng6SUeRd5LVJUxnSanlXkghwGykD7LjMN-j2r6ckoB_1m00 .

Now you have 12 black rectangles http://www.plantuml.com/plantuml/uml/RT3DIWCn4C3nUvuYzA8U2YRxeHQH7hpv5A6TTfVDJa8oY_Zs4iRW9kGsyEC_37EEP09jgnKFSPdHcs1MQMS4-l4WNQ392V7eWxiyIHDb6aI02ncyMv27BxTwXu04wf1yKMtLhBgj7MlNrfwrR-l0EhHrP1s5I9VBu-QF7tBH9_bf2F1cjnWLqtkoYdIPgRrrHLPGdxCmtoTAPNVwro67h2MEERswRqnblr_yyfUoLlWgwdROyrlPbgYUSslXHgaT2yu_OgvLYpFWTLljBm00: the bug is gone.

So I think it's a GraphViz issue, because changing splines mode should not remove labels.

However, if you find a workaround in manually editing the "dot" file keeping splines=ortho so that all 12 labels are displayed, we will be glad to modify our own code to generate a working "dot" file.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/plantuml/backlog/issues/11, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALGQADHXJ7BXX6SVXGNEAZLTGIA6XANCNFSM4F4J3E2A .

[VladimirAlexiev]

@arnaudroques I don't think complex debugging is needed, and @swmatisa I don't think we need to worry about the future of graphviz.

I think the solution was described in 2016 at https://forum.plantuml.net/1608/is-it-possible-to-only-use-straight-lines-in-a-class-diagram

When adding '!pragma svek_trace', converting the svek.dot file with GraphViz yields the following error:

Warning: Orthogonal edges do not currently handle edge labels. Try using xlabels.

and the label seems to be misplaced, just like in the PlantUML output. Changing 'label=' to 'xlabel=' in the Dot file seems to fix this (for GraphViz) at least. Maybe PlantUML could also generate 'xlabel=' instead of 'label=', possibly only when orthogonal linetype is in effect ?

See https://graphviz.org/docs/attrs/xlabel/. I would also add forcelabels=true.

[arnaudroques]

@VladimirAlexiev Thanks for the tip about forcelabels=true

So here is a new beta http://beta.plantuml.net/plantuml.jar that does output forcelabels=true and use xlabel when skinparam linetype ortho is set.

Tell us if results are better!

Thanks

[christophercurrie]

Unfortunately the beta jar doesn't help, because the lines are now too short to fit the label.

[coxley]

+1 Here. The latest version has extremely short arrows in ortho mode, causing labels to be unreadable.

[joel-loewenstein]

Hello, i see similar issues when using entity diagrams with linetype ortho. Is there some ongoing work right now? How could one help?

[malys]

Hi exactly the same issue. Any solution? workaround?

[VladimirAlexiev]

Hi @christophercurrie @coxley @LarsMichelsen @joel-loewenstein @malys ! Can you please post some examples (preferably on https://plantuml.com/plantuml) so we can see the problem? (I don't use linetype ortho)

[malys]

Hi @VladimirAlexiev example

source

full source example

it seems that when the segment is too short, the position of the label is wrong

I hope that will help.

[joel-loewenstein]

Hi @VladimirAlexiev, from my point of view this is not only about the labels but ortho being not fully usable in plantuml, specifically class and entity diagrams. Is there another issue in the backlog refering to this?

Examples as asked:

Based on PlantUML Documentation Entity Example, just added attribute to attribute connection and connection names: Without Ortho: PNG, Code With Ortho: PNG, Code

Another diagram created by myself based on classes: Without Ortho: PNG, Code With Ortho: PNG, Code

[VladimirAlexiev]

Thanks @joel-loewenstein ! In some diagrams you can add dashes to make the arrow longer. But I tried this with your second diagram and it doesn't work (ortho or not): TS "1" ----[dashed]r---------- "n" TSO : Parent \nAttribute <

[JDMKSZ]

Please find here another example with a state diagram. Making the line longer doesn't work

@startuml
skinparam linetype ortho

state Admissibility #lightblue {
    state New
    state Admissible
    state Inadmissible

    New -d-> Admissible
    New ------r-------> Inadmissible : invalid requirements
    Inadmissible --> Admissible
}
@enduml

[malys]

Making line longer doesn't work.

[Jinwoo0503]

To temporarily solve the problem, try:

skinparam linetype ortho
skinparam nodesep 500

Adjust the value of nodesep appropriately

for example, like this:

@startuml
skinparam linetype ortho
skinparam nodesep 230
'skinparam ranksep 50

(Pro-\nzess) as proc
rectangle "Komponente1" as k1
rectangle "Komponente2" as k2
rectangle "Komponente3" as k3
rectangle "Komponente4" as k4
rectangle "Komponente5" as k5
rectangle "Komponente6" as k6

proc -up-> k2: Datenfluss1
proc <-up- k2: Datenfluss2

proc -up-> k1: Datenfluss3
proc <-up- k1: Datenfluss4

proc -right-> k3:Datenfluss5
proc <-right- k3:Datenfluss6

proc -down-> k4: Datenfluss7
proc <-down- k4: Datenfluss8

proc -down-> k5: Datenfluss9
proc <-down- k5: Datenfluss10

proc -left-> k6: Datenfluss11
proc <-left- k6: Datenfluss12
@enduml

[JDMKSZ]

To temporarily solve the problem, try:

Unfortunately, this doesn't work for my nested state diagram above. When I remove the nesting, it works.