opentypejs (OTF files used directly)

[rvilarl]

I have been experimenting with opentypjs and I have observed:

• procesing speed is similar.
• vexflow size increase by 190k (due to the inclusion of the library) -> vexflow-core would be aprox. 592K, which is similar to the current vexflow-bravura 520K
• the subset of the OTFs including the glyphs that we use are: 70k for bravura and 60k for petaluma less that the current vexflow-font-bravura.js 188K and vexflow-font-petaluma.js 166k

This approach would easily allow to include other fonts (it is enough to have the OTF file)

Thoughts?

[ronyeh]

We currently use opentype.js to extract the glyphs from the OTF files.

Looking forward, I think someday we could use the FontFace API. That would support use of the SMuFL OTF files directly, without needing opentype.js.

I wrote a basic glyph inspector using the FontFace API. You can see it after you run grunt in your local copy of VexFlow. Open the tools/fonts/inspector/otf.html file.

In the HTML source, look for

      async function loadFontFiles() {
        const bravuraOTF = '../@/bravura/Bravura_1.392.otf';
        const bravura = new FontFace('Bravura', `url(${bravuraOTF}) format('opentype')`);
        await bravura.load();
        document.fonts.add(bravura);
        ...

So someday, it would be great to support loading these OTF files directly. VexFlow would be responsible for scaling and placing the glyphs in the correct locations on the score.

[rvilarl]

@ronyeh I am making the experiment with OpenType because it also provides the paths for SVG. The only thing that I am missing is rotation. Does FontFace provide SVG paths and rotation?

[0xfe]

Hi folks -- I would prefer not to include OpenType in Vexflow. There's no real benefit, since we preprocess the font data anyway, and we have to customize the metrics (the font formats are not the hard part.) And I'd like to maintain the "no runtime dependency" requirement for Vexflow.

[rvilarl]

@0xfe Ok but there is a benefit: VexFlow size increases every time we include a new font and OTF is much more size efficient than the javascript representation. I thought that this would be a good approach if we wanted to support Sebastian, Finale and Leipzig font families See https://www.smufl.org/fonts/ and address #1398 avoiding the further increase of the library.

[rvilarl]

We currently use opentype.js to extract the glyphs from the OTF files.

Looking forward, I think someday we could use the FontFace API. That would support use of the SMuFL OTF files directly, without needing opentype.js.

I wrote a basic glyph inspector using the FontFace API. You can see it after you run grunt in your local copy of VexFlow. Open the tools/fonts/inspector/otf.html file.

In the HTML source, look for

      async function loadFontFiles() {
        const bravuraOTF = '../@/bravura/Bravura_1.392.otf';
        const bravura = new FontFace('Bravura', `url(${bravuraOTF}) format('opentype')`);
        await bravura.load();
        document.fonts.add(bravura);
        ...

So someday, it would be great to support loading these OTF files directly. VexFlow would be responsible for scaling and placing the glyphs in the correct locations on the score.

This is also an important imput to #1459 @ronyeh I agree that FontFace API is the way to go.

[AaronDavidNewman]

Can you get at the metrics with FontFace API? I don't think so. It is just a dynamic way of loading the fonts.