SVG export ignores user DPI setting

Thanks for the helpful explanation. I'm trying to launch mscore from Terminal on macOS but get a "command not found" error. I even made a symlink to mscore in /Applications/MuseScore 2.app/Contents/MacOS and moved the symlink to /Users/myusername/bin and set 755 permissions, but still it doesn't run from the command line on my system. (I realize I can enter the full path /Applications/MuseScore 2.app/Contents/MacOS but a simple command line option "mscore" would be really useful.) Thanks in advance for any help.

Thanks for this. I edited the $PATH variable and now I can run mscore from the command line.

May I ask the proper syntax? The following works and doesn't launch the GUI:

mscore -o filename.svg filename.mscz

When I tried to set the DPI, this setting was ignored:

mscore -o filename.svg -r 278 filename.mscz

mscore -r 278 -o filename.svg filename.mscz

I also wish to use the -T option to trim the SVG.

Importantly, MuseScore 2.1 does *not* seem to use the DPI settings from MuseScore's export settings for the batch convert plugin, at least not on my macOS system (latest OS, latest stable MuseScore). That's the reason I submitted this as a bug report. Can you please reopen this bug?

Reopening bug as active, as the "by design" functionality to read the user's DPI setting from the MuseScore settings fails. I've tried many values and quit and restarted the program as well as rebooted my Mac. It may be a macOS issue.

I also set the priority to major since the inability to set DPI is pretty serious (and mission-critical for my application).

Also, the DPI setting doesn't seem to work from the command line either. (It's possible that I don't have the correct syntax, but I've tried seemingly all possible permutations.)

On my system PNG export responds to the DPI setting, but SVG does not. I've tried exaggerated values such as 1000 to test. SVG always outputs the exact same dimensions no matter what setting is used.

I can check the dimensions both in the XML and in Affinity Designer (vector graphics program on macOS).

Any ideas why the DPI setting is being ignored by the plugin?

"(and yes, when I looked at the code recently, I got the feeling that this
command line option may not work at all, only the preferences setting, at
best)"

Importantly, neither the command line option nor the preferences setting work on MuseScore 2.1.0 with Jojo-Schmitz-batch_export-6a452a1 on macOS 10.12.5.

Does it work on Linux by chance?

I should also mention that exporting directly from MuseScore (without the batch converter plugin) does read the user-defined DPI preference.

It's at the beginning of the SVG file:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>

Width and height are always the same regardless of the DPI setting input.

If the DPI setting worked, the command line option without GUI would be invaluable for my application, since editing SVGs is otherwise terribly complicated. MuseScore outputs nice and clean SVG code.

Looks like the code was stripped from my post. Trying again... (imagine the following code with < and > surrounding it—these otherwise get deleted if they're entered in this comment box):

svg width="58.7782px" height="28px" viewBox="0 0 58.7782 28"
xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.2" baseProfile="tiny"

If I set export DPI (for SVG and PNG) in MuseScore settings to 1000 and then export the same file as SVG directly from MuseScore (i.e., not using the plugin or the command line), this line reads:

svg width="612px" height="792.175px" viewBox="0 0 612 792.175"

This means that MuseScore's built-in export method is indeed reading the DPI setting. Is there any way to get your plugin to read this setting or accept a user-defined value? According to the command line options in the MuseScore documentation it's supposed to read these values:

-r, --image-resolution
"Determines the output resolution for the output to PNG and SVG images in the converter mode. The default resolution is taken from Preferences, Export, PNG/SVG."

Is this just a bug in macOS? Does it work in Linux?

I should mention the irony of having to specify DPI for vector graphics at all. It should be possible to override any default values stored in the SVG's XML using simple HTML tags and width and height attributes, but these overrides are ignored in mobile browsers on iOS for some reason. This has been driving me crazy, and the only solution I can find is to output SVG files with the exact desired DPI embedded in them. I'm therefore really hoping the MuseScore batch converter plugin bug can be fixed.

Just a thought: I've had several MuseScore versions installed, including a recent nightly build. I've deleted all but the new 2.1 stable release from my Applications folder. Is it possible that 2.1 is somehow reading an old settings file from a former version when I run it from the command line? Just brainstorming here.

Sorry, I overlooked something important: When I exported directly from MuseScore, I forgot that there's no trim option. That means the 612px width was for the whole page, not simply the 1 measure in my test file. When I trimmed the SVG, the width was just 60px—just 1px more than the output from the command line, which is surely just incidental.

I tried different DPI values in the preferences and they all output the same result. This means that the bug is in MuseScore 2.1's SVG export—it doesn't appear to be in your batch convert plugin.

Can anyone on the dev team take a look at what might be causing MuseScore to ignore the user-defined DPI setting when exporting SVGs?

"I repeat: MuseScore batch converter plugin doesn't have a bug here!"

Yes, that's what I just concluded too... see my recent post! ;-)

Any idea how to locate the bug in the MuseScore code? The bug is the same ("SVG export ignores user DPI setting") and it appears to be in MuseScore 2.1 itself, not in the batch convert plugin. Since MuseScore has a setting specifically for SVG (and PNG) DPI, clearly this must be a bug.

At least on my latest macOS system this setting is being ignored. I've speculated that maybe it's reading an old settings file on my system, but judging from your reply this seems unlikely. Can anyone else using any OS try outputting SVGs at different DPI settings and see if the resulting XML (SVG files) is identical?

Now that would explain it. It could be an intended but undeveloped feature. Can any developers chime in here?

Still, SVGs are being output at some default DPI value, so surely this must be set somewhere in the code, right?

That's interesting... I was just looking at that file since there was a comment posted yesterday: "export bitmap to svg with lower resolution than original when applicable".

Yes, this is exactly what I'm looking at now. And yes, it would seem to be a contradiction, but unfortunately it turns out different browsers interpret the width and height embedded within SVG code and ignore any attributes added to HTML. This has been driving me mad, since I had also assumed that the whole point of vectors is to be resolution-independent. It looks like the only solution is to format the SVG files with the desired dimensions.

Transparency does work for SVGs exported from MuseScore.

Hopefully someone can figure out the DPI setting, or maybe I'll play around with a custom build if I have to (though I'll probably just mess things up).

There's a preferences.exportPdfDpi variable for the PDF resolution set in the preferences:

pdfWriter.setResolution(preferences.exportPdfDpi);

Still looking for the PNG/SVG resolution variable. It may be converterDpi referenced in line 2388 of this file as part of the savePng method:

return savePng(score, name, false, preferences.pngTransparent, converterDpi, trimMargin, QImage::Format_ARGB32_Premultiplied);

It's not mentioned elsewhere in the file.

I think I found it. Line 2396 defines savePng with options:

bool MuseScore::savePng(Score* score, const QString& name, bool screenshot, bool transparent, double convDpi, int trimMargin, QImage::Format format)
{

Notice "double convDpi".

saveSvg (line 2606) has no such option:

bool MuseScore::saveSvg(Score* score, const QString& saveName)

So if I'm reading the code correctly, your suspicion would be correct that PNG/SVG resolution in the settings should just read PNG resolution, and SVG resolution still needs to be developed.

No, the transparent option doesn't affect the output resolution.

Yes, as mentioned an exported SVG is transparent with this option set.

Yes, without the transparent option set the SVGs have a white background.

Oh, you're right. (Sorry, it's getting late.) I just exported another test file with transparent checked and unchecked and both exported SVGs are transparent. So you found another bug. :-)

I still definitely consider this a bug report since the settings dialog explicitly provides for SVG DPI as well as transparency, and this is also mentioned in the manual and command line options.

(I certainly don't wish to fight over its classification, but I do think it should be changed back.)

That's a shame, as you wouldn't believe how complicated it is to output an SVG with specified DPI and clean XML, or to edit it after the fact. I really hope this can be fixed (from my perspective!) or added soon. In principle it shouldn't be too complicated since a DPI setting is just a multiplier. I'll keep looking at the code and hope I don't mess things up. :-)

Just exported SVG and PNG at 72 DPI and their dimensions are identical, so SVGs currently export at 72 DPI.

There's also this code in svggenerator.cpp (line 363):

int resolution() { return d_func()->resolution; }
void setResolution(int resolution) {
Q_ASSERT(!isActive());
d_func()->resolution = resolution;
}

Most important is that everything in an SVG is dependent on DPI, so all coordinates, width and height need to scale as the DPI changes. I have no idea how this is all handled by MuseScore or the SVG generator (which I see is borrowed from Nokia under the LGPL license). Hopefully there's a simple variable that can adjust everything at once.