Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

label positioning wrong in linetype ortho #11

Open
LimitlessGreen opened this issue Oct 16, 2018 · 31 comments
Open

label positioning wrong in linetype ortho #11

LimitlessGreen opened this issue Oct 16, 2018 · 31 comments
Labels
bug Something isn't working

Comments

@LimitlessGreen
Copy link

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:

contextdiagram

Now the labels are far away from the lines and label 5, 6, 11 and 12 aren't there.
@albert-github
Copy link

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.

image

@Godsmith
Copy link

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
Copy link

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
Copy link

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

@flerro
Copy link

flerro commented Jun 8, 2020

@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
Copy link

DaHoC commented Aug 3, 2020 •
edited
Loading

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

image

@Iron-E
Copy link

Iron-E commented Sep 17, 2020

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.

@chilippso chilippso mentioned this issue Sep 24, 2020
Open
@devantler
Copy link

devantler commented Oct 26, 2020 •
edited
Loading

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

Test

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

@johnholliday
Copy link

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

@mbajolek
Copy link

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
Copy link

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

@rtuin
Copy link

rtuin commented Mar 22, 2021

Is there a work-around available for this?

@paulooliveira
Copy link

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

@BuzzwordChief
Copy link

+1

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

@swmatisa
Copy link

swmatisa commented Mar 30, 2021 via email

@arnaudroques
Copy link
Contributor

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
Copy link

swmatisa commented Apr 5, 2021 via email

@VladimirAlexiev
Copy link

@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.

@VladimirAlexiev VladimirAlexiev mentioned this issue Jul 30, 2021
Open
@arnaudroques
Copy link
Contributor

@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
Copy link

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

@coxley
Copy link

coxley commented Nov 30, 2021

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

LarsMichelsen referenced this issue in Checkmk/checkmk Apr 29, 2022
@LarsMichelsen
Change line type to a non buggy one
348e08c 
We used ortho linetype before but it is buggy with the current versions
of PlantUML. It renders unconnected lines for interface nodes.

See also:
https://crashedmind.github.io/PlantUMLHitchhikersGuide/layout/layout.html#linetype-polyline-ortho
https://github.com/plantuml/plantuml/issues/149#issuecomment-716593390

Change-Id: I9d7c96b393a9fd578feeed8dd4a011d4ac060dc3
@arnaudroques arnaudroques added the bug Something isn't working label Mar 19, 2023
@arnaudroques arnaudroques transferred this issue from plantuml/plantuml Mar 19, 2023
@joel-loewenstein
Copy link

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

@malys
Copy link

malys commented Mar 24, 2024

Hi exactly the same issue. Any solution? workaround?

@VladimirAlexiev
Copy link

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
Copy link

malys commented Mar 25, 2024 •
edited
Loading

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
Copy link

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
Copy link

VladimirAlexiev commented Mar 26, 2024 •
edited
Loading

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
Copy link

JDMKSZ commented Mar 26, 2024 •
edited
Loading

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
Copy link

malys commented Mar 26, 2024

Making line longer doesn't work.

@Jinwoo0503
Copy link

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
Copy link

JDMKSZ commented May 2, 2024

To temporarily solve the problem, try:

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Something isn't working
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests