Hello Paolo,
I’m not saying that your approach is meaningless. Drawing paths as SVG and
then transforming them into a Lilypond path is a sensible workflow for
creating custom glyphs. But I’m just explaining why this would not work as a
generic method for embedding SVG images into our score.
Hello Valentin,
I don't agree with this. This method was not intended for embedding generic SVG images into a score: it was intended for putting stylized images for *notes*, not only for glyphs, which is common in notes of contemporary scores. This kind of shapes are mostly stylized, then they can be easily translated into paths and nothing else. And LP provides all the corresponding commands. Think for example about a hand for fingering:
I would not like to have a raster image for it. And it's better if you avoid the <image> tag (see below)
In your example the linked SVG does not exists, but if I replace it with an
existing one like
https://jsfiddle.net/utxfgyLb/
I do not get any blur. Also if I’m using scale transforms on it I do not get
any pixelation, as I’d expect on enlarging a rastered image. I’ve tried it on
Firefox and on Konqueror/QtWebEngine (Chromium based).
So if this happens it should probably be considered a bug of the viewer. And
we cannot try to have Lilypond circumvent any bug that might exist in some
viewing software.
This happens because modern browsers have a "surplus" of features and not because the old viewer doesn't observe the SVG specs. Then, the blurry image on older versions of FF should not be considered a bug. Look at this page:
"[...] SVG files displayed with <image> *are treated as an image*: external resources aren't loaded, :visited styles aren't applied, and they cannot be interactive. To include dynamic SVG elements, try <use> with an external URL. To include SVG files and run scripts inside them, try <object> inside of <foreignObject>."
Then, embedding <svg> into <image> is not a reliable way to do what we are talking about. The clean solution is to inline <svg>.
Cheers,
Paolo