Tablature rests are not visible, then badly positioned

• Aug 26, 2016 - 18:14
Reported version
3.0
Priority
P1 - High
Type
Functional
Severity
S2 - Critical
Status
closed
Regression
Yes
Workaround
No
Project
MuseScore
Tags
tablatures
notations
3.0alpha

Windows 10, latest code. See the attached files.

First, follow the steps outlined in this issue in order to properly format the score:
https://musescore.org/en/node/122246
(e.g. delete the contents of the entire first measure in the non-tablature staff it in order to refresh the score in MuseScore and properly format the tablature staff)

Now, find the rests in the tablature staff. You can't, because they are not visible.
Then export the file as PDF. It looks the same, no rests (see attached PDF file)
Then export the file as SVG. Now the rests are visible, but located vertically way too high

So what is happening here? I thought that the PDF and SVG exporting operated in more or less the same way in terms of collecting elements for drawing/painting. But clearly there is a difference here. I am trying to export SVG, and I'm glad to see the rests, but not happy about their position. Maybe this is two separate issues, but I'm filing it as one for now.

Attachment Size
tabs_staff_spacing.mscz 6.83 KB
tabs_staff_spacing.pdf 11.69 KB
tabs_staff_spacing.svg 75.15 KB

Comments

• Aug 26, 2016 - 18:22

Here is the critical difference between SavePdf() and SaveSvg() in terms how how they collect elements to paint:

SavePdf() invokes Score::print(), which has these 2 lines of code (scorefile.cpp lines 1223-1225):
{syntaxhighlighter SPEC} QRectF fr = page->abbox();
QList ell = page->items(fr);{/syntaxhighlighter}

SaveSvg() has this line of code (file.cpp line 2609):
{syntaxhighlighter SPEC} QList pel = page->elements();{/syntaxhighlighter}

Reply

• Aug 27, 2016 - 20:09

From what I see, this issue about the rests is another side effect of the big change of the layout code, merged in mid-April.
Result expected (new score for Bass/Tab 4-str. Full)
expected.jpg
Result found with this nightly: fe2eea4
15 avril.jpg

Reply

• Aug 27, 2016 - 20:26

Thanks for the follow-through.

Maybe I should separate this into two issue threads. I want to make clear that the invisibility of the rests (first issue) is obscuring a vertical positioning problem (second issue) that is exposed via the SVG export, where the rests are visible.

Since I seem to be the de facto SVG export expert at this time, I also want to make sure that the use of page->elements() in SaveSvg() is correct. I did not write that line of code, it was there before I entered the picture. IMO the PDF and SVG exports should export the exact same set of elements. Am I wrong about that? Is there a reason these functions operate on a different data set? Or is this really two different ways of collecting the same set of elements, and the invisibility is affecting the result?

Both functions check the visible property of each Element* in the collection, and exclude elements where e->visible() == false. It's the page->items(page->abbox()) that is preemptively excluding the rests in savePdf(). This means that these Rest elements have their visible() property set to true, but they are still not being drawn by doLayout().

Reply

• Aug 29, 2016 - 18:49

An addition to my previous post regarding the visible, poorly positioned rests in the SVG file:

These rests are not the correct rest type, they are always quarter note rests, regardless of the space they occupy. This is obvious, but I wanted to call it out explicitly here in the issue thread. Again, I have no idea if this is one core code issue or more. It's still one issue here.

Reply