Templates and Use in SVG

[mscuthbert]

This is just to leave a "big idea" somewhere -- I was looking at the Corpus Monodicum site and saw how they managed to greatly shrink the size of their SVG by using "use" and templates in their code:

https://data.corpus-monodicum.de/AE10C10B3AAC65FA11DC04A22B24CBF02823A602AC54423993A772C5425BBDF7.svg

it's a different direction than the move to vector fonts, but it's an interesting way to get high level reuse without needing to put complex paths in multiple places.

[AaronDavidNewman]

It's also SVG-only. But it seems like a really good idea (first time I had a chance to look at it). Size of the SVG and the memory it consumes are the biggest problems I have with Smoosic rn for large scores.

Also I notice these guys don't use beams much :) We would save a lot of svg space having the glyphs as variables, but we'd still have beams/stems that would be immediate renders. And for most real scores, the svg group can't be limited to the line since there are systems, slurs, etc. But still, this is worth some experimentation.

[ronyeh]

Tom and I discussed related topics (svg symbol / use) in 2021: #1127

[ronyeh]

There is definitely value to this approach. While loading SMuFL font files works great for a web browser context, what happens when we want to export the output to an SVG tag (for use in a vector art editor)? It would definitely be nice to be able to render the paths as SVG templates / symbols and then use the use tag to build up a score. This rendered SVG would not require the SMuFL font to be installed on the target system. It would work anywhere.

[mscuthbert]

Yes! This is what happened when one of the SVGs was posted to a thread and I said "looks a little boxy to me"

[ronyeh]

Just looping in @rvilarl because he has looked into SMuFL a lot recently.

With VexFlow 5, we are moving in the direction of using the otf / woff files directly, and not including the glyph paths inside the VexFlow library. This has many benefits, including allowing a developer to choose her/his favorite font, without requiring VexFlow to bundle them all at build time.

The main drawback is that we no longer have knowledge of what the SVG paths look like. If we ever need to render a SVG with the path information, we would have to take the opentype.js approach and parse the font files at runtime. Perhaps opentype.js could be an optional runtime dependency? So if the developer wants to use the glyph paths, we would require that opentype.js be available for vexflow to use.

[rvilarl]

This is much better than repeating the path several times.

However I still believe that the best is to use the font directly for several reasons:

• glyphs are referenced by a single character, which is already much less than the reference to the template.
• a text string can include several glyphs and the browser will take care to space them correctly. (with this approach I have reduced chordsymbol.ts from 800 lines to about 400 lines, many runtime calculations could be removed)
• the fonts are loaded once and then cached by the browser.
• using the font we can use all the available glyphs, we are not limited to the ones imported hardcoded.
• @ronyeh if we want to add paths, I would recommend to create a new font with these paths.
• @mscuthbert the font can also be referenced in the svg to avoid the boxy result if the fonts are not installed, see https://vecta.io/blog/how-to-use-fonts-in-svg#:~:text=Using%20fonts%20with%20Object%20tags&text=Because%20object%20tags%20are%20allowed,able%20to%20access%20these%20imports.

[ronyeh]

Hi Rodrigo,

This is good discussion. I agree that for many cases, it is best to use the SMuFL font directly, and I vote for adding that capability into VexFlow 5. It will allow the developer to choose any SMuFL font for a website.

However, the biggest drawback of this approach when rendering to SVG is that the SVG itself is not self-contained and is not portable to other systems.

For example, the SMuFL OTF approach might generate SVG that looks something like this:

<svg xmlns="http://www.w3.org/2000/svg" stroke-width="0.3" stroke-dasharray="none" fill="black" stroke="black" font-family="MuseJazzText,MuseJazz,Bravura" font-size="30pt" font-weight="normal" font-style="normal" width="1100" height="900" viewBox="0 0 1100 900" style="width: 1100px; height: 900px; border: none;">
    <g class="vf-clef" id="vf-auto6996">
        <text stroke="none" x="125" y="150"></text>
    </g>
    ...

The first text element is rendering a treble clef.

If this SVG is included on a website that preloads the correct SMuFL font (in this case, any one of MuseJazzText,MuseJazz,Bravura), then the treble clef will render properly.

However, if someone happens to download that SVG from the website, they now have a SVG file that is not portable to other systems.

If that someone sends the SVG to a friend, the friend would likely see something like this:

 

This is because 99+% of operating systems (especially mobile) will never have MuseJazz or Bravura installed.

So that is our big concern. It would be nice if VexFlow 5 supported both options.

The default option could be to load the OTF files and then place text elements for each of the music glyphs. This is the approach that you have investigated.

However, I think there should be an alternative option which still loads the OTF files at runtime, but instead places the rendered paths into the SVGs. We could let developers know that this option is useful if they plan to create portable SVG documents that can be used on any device.

I am strongly in favor of moving towards loading OTF files at runtime. I just do not think we should completely remove the capability to render glyph paths, because it might lead to people not wanting to upgrade from VexFlow 4.x => VexFlow 5+. We are going to have lots of cool new improvements in VexFlow 5, so I want to give developers every reason to upgrade.

(One idea is to have an optional plugin that can be used to render SVG paths using the loaded OTF fonts. This plugin can be based on VexFlow 4 rendering code and possibly might require opentype.js as a runtime dependency.)

[rvilarl]

Hi Ron,

I believe that we just have to do it like in the webseite I referenced above for the separated svg files produced by testing, see code below. Vexflow5 as lib will take care about downloading the file on the package you produced (https://unpkg.com/vexflow-fonts@1.0.5/):

<svg xmlns="http://www.w3.org/2000/svg" width="400" height="150" font-size="24" text-anchor="middle">
    <style>
        @import url("https://fonts.googleapis.com/css?family=Roboto+Condensed:400,400i,700,700i");
        @import url("https://fonts.googleapis.com/css?family=Open+Sans:400,400i,700,700i");
        @import url("https://fonts.googleapis.com/css?family=Anonymous+Pro:400,400i,700,700i");
    </style>
    <text font-family="Roboto Condensed" x="190" y="32.92">
        This is a Roboto Condensed font
    </text>
    <text font-family="Open Sans" x="190" y="82.92">
        This is a Open Sans font
    </text>
    <text font-family="Anonymous Pro" x="190" y="132.92">
        This is a Anonymous Pro font
    </text>
</svg>

[sschmidTU]

Just leaving a probably irrelevant note here that Google Fonts is not GDPR compliant (EU data privacy laws), but I guess we don't need to use Google Fonts here (text fonts), you would use the unpkg/vexflow fonts.
(if you want your SVG/website to be GDPR compliant, you need to self-host the fonts that you would otherwise take from Google Fonts)
https://meetanshi.com/blog/google-fonts-gdpr-compliant/

[ronyeh]

Thanks for this info @sschmidTU ... I had no idea that Google Fonts is not GDPR compliant!

[ronyeh]

Hi all,

Just letting you know that we have started reviewing Rodrigo's PRs for VexFlow 5 over at:

https://github.com/vexflow/vexflow/pulls

If you have any questions or comments on this work, please ask them over at the PR discussion.

I'm excited to see what VexFlow 5 will become, but I think the more eyes we can get reviewing the code, the stronger the end product will be.

[ronyeh]

@sschmidTU @rvilarl

Regarding GDPR, does an approach like https://github.com/fontsource/fontsource work?

It's a directory of open source fonts, that are each hosted individually on NPM.

https://github.com/fontsource/font-files

https://github.com/fontsource/font-files/tree/main/fonts/other/bravura

See directions for installing Bravura via NPM:
https://fontsource.org/fonts/bravura/install

We could try to use fontsource and make sure all the font files are the most up to date versions (I see their version of Bravura might be slightly outdated...).

Or we can take the same approach and publish all the vexflow compatible fonts as individual NPM packages.

Then a developer can run npm install @vexflow-fonts/leland to install the web font locally in their project. Then, when your project goes live, your bundler will put the font files on your own web server. Since it is self hosted, you can control the GDPR compliance.

[rvilarl]

Is the vebfont approach using unpkg not valid? Is unpkg also not GDPR compliant? I mean using:

https://unpkg.com/vexflow-fonts@1.0.5/

[sschmidTU]

The issue with Google Fonts to my knowledge is that Google gets the user's IP, and a lot of people don't like Google and them getting their IP. So, the legal cases might not even have been brought up if it wasn't Google. But that's just a side note. I'm not sure if this also applies to other direct download links, or if it's a special case with Google Font being an API that serves the file after a request and not a direct download link.
In any case, developers using Vexflow can also self-host the fonts on their own servers, right? That would be the most compliant approach.

[eliot-akira]

unpkg.com is hosted at Cloudflare, and it seems to be an unanswered question if it's GDPR compliant or not.

The only way I see at the moment is to inform the user that dependencies from unpkg.com (cloudflare) are necessary to load the page, before actually loading them. Than the user has the option to leave the page before sharing data with cloudflare.

I would not recommend to use unpkg in production if the GDPR applies!

• GDPR compliance mjackson/unpkg#294

On the other hand, here's an article about another service jsDelivr, that claims it's OK.

How the German court’s ruling on Google Fonts affects jsDelivr and why it is safe to use