Feature request: compact SVG dom option in renderAbc()

[stewarthaines]

Hi Paul,

Thanks for your work on this project. It's been really solid for things I've wanted to do - namely producing XHTML files with inline SVG elements of music notation.

I'm using abcjs in a VueJS app for creating EPUB books that include music notation that looks good on mobile screens of varying size from phones to tablets.

The approach is to render SVG elements and serialize the resulting dom to XHTML using XMLSerializer. The app transforms abc notation to multiple SVG elements using the oneSvgPerLine and wrap options with increasing staffwidth values. Then at reading time the EPUB has javascript to choose which set of SVG elements to display based on paragraph width that is expressed in terms of font-size.

The output file size is in proportion to the complexity of the SVG dom. The published EPUB XHTML uses three staffwidths per score (for small, medium and large screen widths) so the files have three versions of the SVG for each score. This sent me looking for ways to make a more compact SVG dom.

I've implemented a solution that significantly reduces output file size, based on changing the way glyph paths are defined.

I've created this issue to discuss if there's any interest in incorporating my changes to the the main abcjs branch.

The SVG <defs> element is described here; https://developer.mozilla.org/en-US/docs/Web/SVG/Reference/Element/defs

The improvement I'm proposing works by eliminating the duplication of glyph path data. Instead of individual <path> elements in the dom the revised glyph handling employs the <use> element with a reference by id to the glyph <defs> singleton.

For my purposes this is working really well. I have a fork of the abcjs repo with these changes that I'm using in my project. #1087

If you think it might be of more general interest I'd be happy to take some guidance on what else might need to be addressed to get it ready for a PR to abcjs/dev. (Tests and documentation?)

[paulrosen]

The glyph generation can definitely use help! I would love to explore this.

I have some tests in the abcjs project, but I've got another project with hundreds of abc strings that I use for regression testing.

I guess making it an option is the right way to go, just because there might be some particular post-processing someone has done that depends on the current behavior.