SVG Export handles z-stacking order of staves incorrectly. Staff Type Changes within systems are also not honored
1) Create score
2) Add image
3) Alter z-stack order of the image so that it fits visually below/under staff lines so that stave lines show. Just below everything actually, which from my estimation is approx. <= 1000 stacking order:
4) Export to .SVG
Result upon load (also the result of .COM site since as JoJo S. mentioned (https://musescore.com/groups/improving-musescore-com/discuss/5090677?fr…), the .com site uses the .SVG export:
There is a little bit of z-stacking order that worked here, but the staff lines themselves are not showing when they should as if the image didn't get the appropriate z-order or the staff lines don't honor some type of z-ordering that is default in the main view of the application). Something's not "consistent" with the SVG export as with the normal view of the score + PDF output.
The main concern here is for .COM users because it would be nice to have some images behind things if users would like them, but also of course just straight up .SVG export for local users also.
I wonder who is main contributors for SVG export and if this might be something really easy to solve?
The issue tracker here doesn't need my .mscx file to produce the above mentioned steps. Just add any image (preferably something on the lighter-side) to a score and lower its Z-order below 1000 and then export to get similar results.
Comments
As far as I know we're using plain Qt to do that SVG export
Update:
![staff-offset.png]( "staff-offset.png")
Upon further investigation, staves are "1st-pass" no matter what, and then the elements within the svg drawing are ordered into a list via their z-order. This would account for non-consideration of the stacking order of staff-lines (from my estimation about z: 1200). While that was noticed, it's also noticed that SVG export draws its staves system-by-system unless a system contains an invisible measure or a frame, and then it switches to measure-by-measure for that system. The problem there is that it doesn't also handle those newer Staff Type Changes so that it draws measure-by-measure in that situation, so that something like this:
will be broken upon SVG export. This should also be fixed so that SVG and PNG/PDF are equivalent in appearance afterward.
At any rate, it would be easy to alleviate the problem of not taking into consideration the z-order of staff lines, but it would be at the expense of the drawing of stave-lines per system under certain circumstances for efficiency's sake, and I don't have any data as to how efficient the difference is
It would be easy to update the code so that staves are drawn measure per measure and have the z-stacking order also be taken into consideration, as it naturally would occur by not having separate passes distinguished between stave-lines and the rest of the elements. That would probably fix the problem with the Staff Type Changes. For example, the above image with the staff change, upon svg export as is, looks like the following because it drew the entire system's staff lines in one pass (the next system looks how it does in the main program):
To have both where z-order is taken into consideration + also go system by system + measure by measure on the appropriate occasions would require more involvement.
https://github.com/musescore/MuseScore/pull/7443
After conversing with Sidewayss, the importance of per-system staff-lines when capable was outlined, so this was included in the update.
I also include here a test mscx file + resulting SVG on my system showing that it's working okay now, but further testing is much appreciated
snapshot of svg file:
![screenshot-of-svg.png]( "screenshot-of-svg.png")
Anyone got any extra time to spare... please test further, but so far so good over here.
Duplicate of this issue, which I marked as the duplicate just now:
https://musescore.org/en/node/280831
Or #280831: Export/SVG Z-Order problem: StaffLines(polylines) are always behind images