The dashPattern of KLineStyle is set to unique values, but should not

[NiklasRentzCAU]

The ECore model of KRendering defines that every element in the dashPattern List of KLineStyle needs to be unique. That causes custom patterns like '3 1 1 1' to not work as expected (it should create a dash-dot pattern with small spaces inbetween), and just show a '3 1' pattern in every resulting KGraph (it creates just a dash pattern with small spaces inbetween).

The attached image shows the bug: the left is how it is supposed to look (created here with the predefined dash-dot) and the right is how it is rendered currently.

linePatternBug.png

[NiklasRentzCAU]

This issue is migrated from the old KIELER Pragmatics JIRA issue tracker. See the old discussion on this ticket in KIPRA-1922.

[sailingKieler]

I think there's a misunderstanding here.
If I recall right, in the dash pattern you specify the lengths between toggling between drawing and not drawing, at least according to the SWT semantics of the dash pattern interpretation. If you for example add an additional 1 to your pattern, you should get a very different result.

[le-cds]

If I recall right, in the dash pattern you specify the lengths between toggling between drawing and not drawing, at least according to the SWT semantics of the dash pattern interpretation.

According to this interpretation, the "3 1 1 1" pattern should recreate the dash-dot pattern, if I'm not mistaken:

If the problem is that a pattern cannot contain any number twice, then I would certainly think that's a bug.

[sailingKieler]

Maybe the attached diagram confused me, as the leftward edge looks like my expectation of the first edges drawing.

I remember that I spend quite some time on this while developing and documenting it for my thesis, but it could be that there's some issue in the mean time.

[sailingKieler]

A break point at

KLighD/plugins/de.cau.cs.kieler.klighd.piccolo/src/de/cau/cs/kieler/klighd/piccolo/internal/controller/PNodeController.java

Lines 461 to 462 in 120f3ce

	float[] pattern = styles.lineStyle.getLineStyle() == LineStyle.CUSTOM
	? Floats.toArray(styles.lineStyle.getDashPattern()) : null;

should clarify this.

[NiklasRentzCAU]

At that breakpoint the pattern is [3,1] instead of [3,1,1,1], so the model itself has a small bug.
I just replicated the issue and found the mistake: The dashPattern for the LineStyle in the ECore model has a 'unique' flag set to true, whereas it should be false.
Now that I know how to work with these ECore models, I will just create a quick PR to fix this.