Export SVG
Closed this issue · 7 comments
SVG Export fails for large pieces. Let's try PNG export with high resolution (target is for print).
Per Jesse's email on the list:
In the long run I think SVG would be much better, because it will allow us maximum control over the images. This is also the format in which Craig has been working lately, which makes me think it would be smart to stick with SVG here, too. (An example of how this could matter is annotating cadential arrivals: because the ribbon tool doesn't currently make this possible, for published analyses I'll be adding these annotations by tweaking the underlying image files.) So if the url-length issue isn't too hard to solve (I remember Craig made a similar change to JRP work-file urls fairly easily), that would be great.
Changing the title of this ticket to reflect the direction back towards SVG.
So I've been doing some reading and research, and found an article from 2014 on CSS tricks , which linked to a follow-up codepen with even more optimizations. The basic idea is encode SVG as ascii, not base64. Summary:
- data-url accepts ASCII or base64
- SVG is XML/HTML it is mostly in the right encoding for data-url already
- base64 encoding an SVG increases the payload size (by a ratio of about 4:3, or 4 characters for every 3 bytes).
- by using single quotes, instead of double quotes, we wind up not having to encode spaces and other things.
- so:
<g transform='translate(45,40)'>instead of<g transform="translate(45,40)"> - since ' is a valid URL character as is (but
"has to be URL encoded to%22) we get a shorter string - basically:
- Encode <, >, #, any remaining " (like in textual content), non-ASCII characters, and other URL-unsafe characters, like %.
- enclose the data-uri value in double-quotes, and we should have a smaller download.
- so:
@curran, we might be able to attack this on multiple fronts:
- wherever we are generating SVG elements, we can take care to send those strings within single quotes rather than double quotes. (SVGs will remain valid if converted correctly)
- that way we do this consciously, by design, and only put into double quotes those things that need to be double quoted strings in the downloaded SVG.
- thus, we should only have to URL encode a minimal set of characters and ampersands and such, before putting it into a double quoted string as the data-url.
thoughts?
@curran another thing that I've been thinking about is two, or perhaps, three different SVG downloads -- one for notes, one for std-dev ribbons and one for attack-density ribbons. That makes the end product(s) less messy to deal with, too.
Per #138, I've removed some of the low-hanging fruit, and so I'm now seeing success with pieces like Jos1910. None of these optimizations have so far been necessary, as all the work was a combination of deduplication and replacement of verbose SVG constructs (like <use>, unfortunately :( )
I don't want to close this ticket yet, until we test a larger suite of songs.
Here is how I am saving the text editor content on the left side of the interface for Verovio Humdrum Viewer (http://verovio.humdrum.org) to disk when pressing the alt-s command
http://doc.verovio.humdrum.org/interface/humdrum/#saving-humdrum-filesdata
var text = EDITOR.session.getValue();
// var blob = new Blob([text], {type: 'text/plain;charset=utf-8'});
var blob = new Blob([text], {type: 'text/plain'});
saveAs(blob, filename);Where the saveAs function is defined in the Javascript library http://purl.eligrey.com/github/FileSaver.js/blob/master/FileSaver.js
https://github.com/eligrey/FileSaver.js/blob/master/FileSaver.js
Another possible method is to open up the SVG image text in a separate window.
Example: go to http://verovio.humdrum.org
and press alt-g after you see music notation, and a window will open with the SVG contents of the notation image:
http://doc.verovio.humdrum.org/commands/alt-g
Code that takes the SVG text and puts in a new window: