Ties in tablature: vertical position wrong and ends hidden behind fret marks

• Nov 23, 2015 - 15:18
Reported version
S3 - Major

Nightly d45cc19 / Win 7

See attached score. The default position of note ties in tablature seems to be slightly too low in voice 1 and slightly too high in voice 2. This is especially noticeable when "show back-tied fret marks" is ON and the ties are short, because the ends are being hidden by the white background of both TAB numbers.


Attachment Size
tab_ties_position.mscz 31.8 KB


Nightly d08e14c (4 Jan 2016) on Win 7 HP

Compare a section of the pdf output of the attached MuseScore file to Finale 2009 and the difference is noticeable. The default placement and shape of voice 1 ties in Finale is much better:


My request is: (1) Bring tablature ties to the foreground so that they are no longer affected by the white space. (2) Introduce more curvature to the default ties. (The attached file shows problems with ties in other voices as well.)

Attachment Size
tab_ties_issue.mscz 25.53 KB
Title Tablature ties truncated and too flat (when lines set to "broken") Improved placement and appearance of tablature ties
Title Improved placement and appearance of tablature ties Improve placement and appearance of tablature ties
Title Improve placement and appearance of tablature ties Ties in tablature: problem with vertical positioning
Severity S5 - Suggestion S4 - Minor
Regression No
Reproducibility Always
Workaround Yes

Still the case in MS 2.3.2

Title Ties in tablature: problem with vertical position Ties in tablature: vertical position wrong and ends hidden behind fret marks

So this has been going on since v2? Yet the ties move down/up when I open a v2 score in v3 and select "reset to default positions".
I just created a new score in v2.1 and this issue is present there too. So it predates this issue page by one sub-version.
It's an unrelated circumstance that causes me to have 2.1 as my version 2 installation.

to clarify - The reason this is a Major issue is that there is no workaround. You cannot set the Tie styles only for tablature. Those style settings affect all ties in all staves.

AFAICT, the bounding box used by TieSegment::layoutSegment() is not correct, and may be because the bounding box for the tablature note is for the text of the note head, not the background whiteout rectangle, which is bigger than the note head. I'm looking further into the cause, but the solution appears to be a specific adjustment inside TieSegment::layoutSegment() for tablature note heads. Possibly a new Note::getOuterBBox() function would be the best way to do it, not a manual adjustment inside class TieSegment.

Here are two images of two different adjustments to the tab tie y-coordinate. The first subtracts 1.75, and the second subtracts 4.
1.75 is the extra height at the top for the background whiteout rects,. To my eyes, they both eliminate the cropping, so the 1.75 is a minimum, which works for me. Any contrary opinions?

Note that the by default tablature staff lines are separated by 1.5 * the spatium, 37.5 versus 25. The height of the whiteout rect is based on one tablature staff space = 37.5 by default. The height of the FreeSerif font at 9pt is 34. The whiteout rect is 3.5 taller than the text, thus it is positioned 1.75 higher than the text.

I attached the image files themselves so you can zoom in and see the pixels. I zoomed in to 500%, and the cropping is eliminated in both images, AFAICT. This is a screenshot of a double-zoomed-in MuseScore too. You gotta look closely at these things...

Attachment Size
tabtest+4.png 2.59 KB
tabtest-1.75.png 2.61 KB

The y coordinate is easy, it's the x-coordinate that is funky. The whiteout rect calculates it by shifting the note head (text) x-coordinate by 0.1 * the spatium, by default that's 2.5. I don't know from where the factor of 0.1 derives, and the spatium is a vertical value, not horizontal. I don't know why you'd want it wider just because you user taller staff spacing, or narrower if you use shorter staff spacing.
This code is in one place only, Note::draw(), here:
I also don't know if it is desirable to change the ties' horizontal positions. If this is just a y-coordinate issue, then I'll provide just that value to the Tie class. No need to mess with x if it looks right in the current master. That y value is already available the same way the Note::draw() gets it:
const StaffType* tab = staff()->staffType(tick());
y = tab->fretMaskY() * magS();

Status active PR created

I only adjust the y-coordinate, not the entire bounding box; x is unchanged. The new code adjusts the translation that is applied to the slur/tie in TieSegment::computeBezier(), early in the layout/draw process.
This makes the minimum position change, 1.75, plus 0.2 * the spatium, for a total of 6.75 at the default spatium value of 25. 1.75 looks OK when zoomed in, but in default resolution on my HD1080x1920 monitor the tie touches the tab number. 0.1 didn't do the trick, so I settled on 0.2. It looks good to me, even better than the tie on the two standard quarter notes in the top staff. Here are screenshots in default and zoomed resolution:
testtab-6.75n.png    testtab-6.75.png
Feedback is appreciated. I made a judgment call on how far to move the tie, and I based it on the score's spatium, which seems appropriate for a y-coordinate, but if not, let me know.

also note - for this example score, adding -1.75 to the tab note y offset makes it equal to the quarter note above it: -18.75. For a default tab staff, that is half the staff space value of 37.5. The quarter note's tie is translated by 18.75 already. The original value of the tab note tie's y offset is -17 = -34 / 2.
I set it to -18.75, then I move it up by an additional -5 = 0.2 * 25; to -23.75.
Those numbers are in internal MuseScore units @360dpi. That's close to the 300dpi of many printers. My 24" 1920x1080 monitor is running at 92ppi. An 8K monitor this size would be 4x that resolution = 368ppi. Some iPhones and other HDish smaller monitors, as well as 4K and 8K monitors, achieve 360ppi or higher, but it's not common for screens yet. It will be...

Status PR created fixed

The pull request was merged but this is issue was not closed automatically due to a missing space between "fix" and "#88411" in the commit message.

Fix version