Tie displayed incorrectly at start of system

• May 24, 2019 - 15:47
Reported version
3.x-dev
Priority
P1 - High
Type
Functional
Frequency
Once
Severity
S3 - Major
Reproducibility
Always
Status
closed
Regression
Yes
Workaround
No
Project

If a tie crosses a system break, then we are supposed to draw a reasonable length of tie on the second system, starting at the header. This doesn't work correctly in some cases. The cases where it doesn't work correctly may differ between 3.0.5 and 3.1, but I can reproduce some version of this on either. Still working on a complete understanding. So, yes, I'm submitting an issue with a "needs info".


Comments

Regression No Yes
Reported version 3.0 3.x-dev

As mentioned, there are cases where the same happens in 3.0.5, most of those were fixed as per #287022: Tie position incorect over line break without clef. However, a different fix of mine for an unrelated issue (#281024: Invisible staves inappropriately factored into note spacing) introduced a new case where this fails. That's because my original fix used prevEnabled() to find the segment to start drawing from, but now it really needs to use prevActive(). Otherwise, you get bad results if the key is C on all visible staves but you have invisible staves with a different key. On top of that, the width calculation might need a tuneup too.

Attached is a case that works in 3.0.5 but fails in 3.1. Load into 3.0.5 and you get this:

avoidance_issue-2.png

That's actually too much space, I think because we are paying attention to a key signature segment with nothing on it for the visible staves. But in 3.1, because we no longer even lay that segment out, you get this:

avoidance_issue-2-31.png

I should note you actually first get a kind of curious version where the tie is drawn over the clef, looks like maybe a cool optimization, but it redraws itself on the next layout to this.

Attachment Size
avoidance_issue-2.mscz 13.54 KB
Fix version
3.1.0