SVG Export - clarifications and efficiencies

I also thought about an external SVG font file. It has promise, but like CSS it doesn't fit the standalone image paradigm, so it would be unavailable for that common usage of SVG files. And if you're going to have an external font file, why not the actual TTF or PostScript file? If the font file is referenced in the SVG you can use any font, whether or not it's installed in the OS. That's the tactic I'm going to pursue with SVG text.

I don't understand your first paragraph. Do you mean once the SVG is loaded into a browser, during run-time? Or are you talking about updates to the source font which require changes to the downstream SVG font? You can always regenerate the SVG from MuseScore to get the latest glyph updates translated into paths. And you can always copy/paste new paths into the <fonts> element in the SVG file and re-render it. What am I missing?

As I said, musescore-old is v0.x branches, no v1 branches available there.

What advantage would that provide? What attributes would the elements inside the group inherit? The only one I can see is the transform=translate(). The stroke and fill are definitely not shared by the text and the frame, so none of the fill-xxx or stroke-xxx attributes would apply either.

I believe that there might be various legitimate uses of groups that could exist inside MuseScore SVG. But coding those elements to be inside groups while other elements remain group-less is not necessarily straightforward. And wrapping everything in a group is excessive, as the vast majority of elements, when previously wrapped in groups, were alone in those groups. >99% of the old group wrappers were around single elements, Staff lines being the primary exception.

An interesting example is the SlurSegment. All the SlurSegments in a system have the same translate() coordinates. They are unique in this way, though Beams are similar, but only for the Y axis. The translate() X coordinate is constant, the start of the system, in all the SlurSegments. This is the case even in my piano-roll-style scores with one long system: all the slurs in a single system are drawn relative to the same x/y coordinate position. So it would be ideal to stick all those slurs in a group with a single transform=translate() attribute. But to do so would require knowing which system a slur is in, which is not straightforward in the code.

Ok, thanks! I'll, check that out. IE is the one that likes .eot files, I believe. I always test first in Firefox and Chrome - Chrome is the SVG-friendliest of all the browsers. IE is generally the weirdest.

...after some testing/investigating: This is definitely an issue with the .eot file. If I use ASCII text in those note head text elements I see the characters in a default serif font. And if I use the same CSS with HTML, not SVG, I have the same issue. So it's considering the MScore font not found or not usable in some way. It might be that EOT doesn't deal properly with the Private Use Area in unicode, which is where the MScore font's characters are.
I have used this same CSS markup to include fonts elsewhere, and it does work in IE11 with other fonts, so this is not an SVG-specific issue, it's an EOT/font issue. I just downloaded Microsoft's own WEFT web font embedding tool, but it's some wizard-based thing that wants to analyze my websites and change my html for me. It doesn't seem to simply convert font files or provide more transparent help on this issue.
Damn, it's always something obscure... I'll post a fix when/if I find one. Thanks for testing it!
Here's someone else having a similar problem, though 3.5 years ago, and no real solution provided: http://stackoverflow.com/questions/10747144/getting-ie-to-use-private-c…
Here is a page that purports to test the PUA (private use area) support in your browser, but it looks worse in Firefox than Chrome or IE11 (on my machine), and it generally looks kind of empty: http://www.fileformat.info/info/unicode/block/private_use_area/utf8test…
I'm wondering if for IE this font needs the characters moved down (visually up in FontForge) in the unicode character set. But that would also mean a different SVG file for IE, because the character values there would have to change too.

Does anyone else have experience displaying the MScore font in Internet Explorer?

I have tried two things to solve this, one of which works:
1) The bad news: I tried moving the characters down by 0xC000 and 0xD000 in the character set, putting them in more normal ranges. Worked in Chrome/Firefox, same problem in IE.

2) The good news: I created a brand new font in FontForge, set encoding to Full Unicode (which is way huger than I imagined), and copied/pasted glyphs from mscore.sfd to my new mscore-web.sfd in exactly the same slot in the Private Use Area. I then generated a .ttf file and the .eot file, and ¡Abracadabra! the font displays in IE.

So to get the Mscore font to work in IE I copied all of the glyphs into this new file and it works. Attached is a zip file with the updated font files/css file (I didn't want to use the same font file name, though I am using the same font-family name in CSS).

I don't know what the difference is with the new .sfd file. Maybe there's a setting that can be changed in the existing font to make it compatible with IE, I do not know. Maybe it's because mscore.sfd doesn't define the full Unicode character set, or it's "encoding" is incomplete in some way. My new font does not include the ".notedef" or other 3 final characters in the original file that are in the 0x10000 range. I only copied from 0xE000 to 0xEBB0, the triple-dot character.

btw - I believe this is why LilyPond uses .png files to display their fonts on the web.
See here: https://fonts.openlilylib.org/#font-catalog
and here: https://fonts.openlilylib.org/font-specimen-viewer.html

Yep, because it doesn't know about the font, it just sees a character code.
So you have to be cautious using external references in your SVG files if you want to open them directly in Inkscape and have them be editable. Even if you have the font installed, the reference to the font family is only in the CSS, not in the SVG. SVG is just a class=value to define the formatting.

excuse the edit- I just saw the measure number 5 looks OK. That's because it's Element::Type::Text, which is so generic that I can't style it in CSS (yet). So the font-family and font-size are specified in the SVG file. It would appear that you have the FreeSerif font installed on your machine, either that or it's not FreeSerif, but the fact that it's an alphanumeric ASCII character renders it legible.

I never said external references were for everyone. For me, they're a bonanza.
Thanks for continuing to test this!

I tested it against Scribus, and a similar result. I do not know of an SVG editor that specifically handles CSS, but I'm more of into text than graphics. Have you tried the google svg-edit? It's the most basic of all of the SVG graphical editors I've tried, but I didn't like the way it ran inside the browser. It might have CSS capabilities - chrome certainly does.
Depending on the rest of your deployment situation, you could, for example probably take advantage of external font files, the way MuseScore v1.3 did; but not external CSS. Maybe internal CSS, that could be an option. You could try that with a manual edit to these SVG files if you like. I'm not coding anything inside MuseScore to generate the CSS, that's all manual, and it's really a one-time thing, not an every-time-you-export thing.
I don't know if Inkscape would deal with CSS embedded in the SVG. But if you're really into the smaller file size, then give it a try. It seems to me like the best hope you've got of getting something to work.

regarding the second line of header quoted above:

• xmlns="http://www.w3.org/2000/svg" This is absolutely necessary for the browser to render the SVG.

• xmlns:xlink="http://www.w3.org/1999/xlink" This is for XLink and links to external resources from within this file. By default, a MuseScore SVG has no reason for this. Even if gradients do get implemented, and they use internal urls, this is not required in the header. If someone wants to muck around in their MuseScore-generated SVG file and add external links, they should feel free, and they can add this to the header in the process. Unless there is some other form of external resource that I do not foresee, this is unnecessary for MuseScore.

• version="1.2" baseProfile="tiny" This ties the document to SVG Tiny 1.2, which is oriented specifically to mobile devices with small screens. Do we really want to do that? From what I'm reading it seems that ican do more harm than good, including compatibility with IE and limited feature sets elsewhere. It seems to me that if MuseScore seeks to be as compatible as possible, these settings should simply be omitted. I can't even find "Tiny" on caniuse.com and a google search for "svg tiny 1.2 browser support" yields little useful information - for example.

In the process of cleaning up my own headers I've bumped into various bits of code in file.cpp/saveSVG() and svggenerator.cpp that should be updated. I will include them in the pull request. They are:

• svggenerator.cpp - Initialization of the SvgPaintEnginePrivate class, resolution = 72;. Now that element.h is included, the Ms namespace is available, and in line with the 72dpi changes this should be: resolution = Ms::DPI;.

• file.cpp/saveSVG() - 2nd line of code sets this very same property to its default value: printer.setResolution(DPI); This is unnecessary.

• svggenerator.cpp/SvgGenerator::metric() - I don't know who or what might call this function, but it is using a literal 25.4 value in a couple of places and that should be replace by the new constant DPMM. For example, this line of code:
return qRound(d->engine->size().height() * 25.4 / d->engine->resolution());
should change to this:
return qRound(d->engine->size().height() / Ms::DPMM);

These are not in the pull request, they are recommendations for a future clean-up of the file:

• svggenerator.cpp - struct _attributes{} - it's only really used for the title and description, but there's a bunch of code to deal with all the other structure members. And given that it's only two members, it hardly merits a separate struct. title and description could easily lose the struct wrapper.

• file.cpp and svggenerator.cpp - size and viewBox are the same, why do we need to set both? I don't know if there's some Qt process underneath the covers that needs them both, but if there isn't, then we should eliminate size, which is the one that is no longer used in the pull request code.

• svggenerator.cpp/qfontToSvg() - This is not used in MuseScore or my font-based code. I'm using an override of drawTextItem(), in the same group of functions as drawPath() and drawPolygon(). Many of unused members of the attributes structure (mentioned above) appear here. This function is a prime candidate for deletion, as it is generally outdated and has no matching drawTextItem() implementation to deliver actual results.

• svggenerator.cpp - Text Codecs. SvgPaintEngine::end() has this code:
#ifndef QT_NO_TEXTCODEC
d->stream->setCodec(QTextCodec::codecForName("UTF-8"));
#endif
The first line of the current SVG header (that I'm lobbying to remove) is:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
If a Text Codec is actually defined, this might cause problems. In my code, I'm removing that first line of SVG header, as mentioned previously, and I'm removing the #ifndef around the call to QTextStream::setCodec, so that it always uses the SVG default, UTF-8. I recommend doing the same thing here. If you want to integrate other text codecs, that can be done later, but right now MuseScore only supports UTF-8 regardless.

The pull request has been made. See issue #86686 for details:
https://musescore.org/en/node/86686#comment-398701
--
One last thing I have had to change to make my piano-roll-style scores work: Increase the limit on the width of the page from 2,000mm to 200,000mm. An semi-arbitrary increase, because there's no reason to limit it at all in the paperless world. 2,000 was definitely too small, and I can't imagine getting near 200,000, so that's where I stuck it. I could have switched to inches, then it would be a 2,000 inch limit, but I didn't want to deal with the rounding errors discussed previously in this thread.

This change is in mscore/pagesettings.ui. I'm not going to include it in the pending pull request, but I wanted to note it as an issue and a simple fix. There are large format printers that can print from a roll of paper/plastic and their horizontal limit is a lot more than 2 meters too, FWIW.