SVG Export - clarifications and efficiencies
This new topic is an attempt to consolidate some concepts and information regarding SVG export.
Background: MuseScore v1 used fonts in SVG. v2 changed that, so now the raw vectors (paths) are exported to the .svg file. This eliminates the need for specific fonts to be installed on the user's machine, which is good. It also bloats the .svg file because those raw paths are a lot more SVG text than a reference to a font glyph. This is especially evident with lyrics and other text in a score. MuseScore puts an entire segment's lyric's text into one SVG path element. I've seen a score title produce a path of Element::Type::TEXT with 37,000 characters in it, one long line of text in the .svg file.
Efficiencies: Recent pull requests by Heslil Inc. and myself make changes to the SVG Export code to offset the increased file size in v2. So far, we have eliminated group elements that needlessly wrap other elements, and excluded default value settings from the file. But the files are still large, and those paths are still long.
Two further efficiencies can be achieved:
1) Set scaling (magnification, "mag" variable) to 1:1 and change SVG transform="matrix(a,b,c,d,e,f)" to transform="translate(e,f)". Less text and generally simpler. The "S" in SVG stands for "Scalable", so generalized scaling of all the elements internally is unnecessary - this is not a printed page.
2) Remove transforms entirely for all polyline elements and images. This goes back to the way v1 exported SVG. If you're going to export glyphs, fixed vectors, then the basic way to go about it is to translate() to your location, then draw the glyph. But if you're drawing lines from x1/y1 to x2/y2, it makes more sense to simply add the translation coordinates to the line's x/y coordinates (the SVG polyline element's points attribute). Less text and generally simpler, also conceptually more in line with the no-font paradigm.
In my personal version of MuseScore master, I have coded both these changes and they work well so far.
CSS: Another possible efficiency is in the use of external CSS. In my own project I am doing this, and I've been able to reduce my .svg file sizes by an additional 10-15% with a 755 byte .css file. CSS mostly affects the polylines, not the paths, but it enables the elimination of many repeated attribute settings in the SVG file. Unfortunately it's not appropriate for the basic use of SVG files as self-contained images, clip art, so it's outside the scope of MuseScore for the foreseeable future.
<path> Elements: MuseScore uses SVG paths for two distinct sets of elements:
a) graphically fixed elements such as rests, note heads, accidentals, etc.
b) graphically variable elements such as slurs, beams, text, etc.
Nothing you can do about the variable-sized elements. The fixed elements used to be font glyphs in v1. There are two other ways to use references instead of the actual path text in SVG:
1. The <defs> element combined with the <use> element
2. The <font> element
Both these methods have one basic problem: defining all the paths in the defs or a font element will take up a fixed amount of space that might be very large compared to how many of those paths are actually used in the file, like a bulky header. For example, you define all the different types of note heads, but only use 3. The SVG export code might need to be intelligent enough to only define the paths that are used by the file.
Method #1 also suffers from the problem that use elements cannot be animated, which affects my current project (hopefully there are others who care about animation too). I am currently playing with method #2 to see if it might be viable and worth the trouble. Yes, it's a step back into using fonts, but without requiring any fonts to be installed. It's a win-win if it's plausible.
But what about text? It's not music, but there can be a lot of it in a score. MuseScore v2's no-font policy for SVG affects lyrics and other score text, the graphics over which MuseScore has the least control, because these are external fonts. It's an interesting feature in that it also bypasses font copyrights via SVG exports. I don't have a solution or a recommendation here. I need to investigate further with my own scores and see how it goes. It seems that text in a score might be best implemented as text in an SVG document. But a reference to an external font is inappropriate for standalone image files, so it's in the same category as CSS here.