Vexflow: SMuFL support + status of Gonville support

[Silverwolf90]

(Might be worth looking at this proposal first: https://github.com/0xfe/vexflow/issues/349 -- Once those tasks are completed this issue becomes more relevant)

In the old issue on SMuFL support, we agreed on not using the metadata but a different set of hardcoded metrics, and I think that was a mistake. Being able to rely on SMuFL metadata entirely for layout will simplify the codebase. Now that I've used SMuFL pretty extensively, I'm in favor of going all-in on SMuFL, rather than ending up in some half-way state because we're trying to support Gonville too. It would still be a big net positive if we could use the SMuFL metadata, even at the cost of supporting Gonville.

I do think we need to seriously consider what is gained from supporting Gonville. It's non-standard, has a minimal glyph set, completely lacks metadata, and adds complexity to the codebase to support it alongside SMuFL. Basically, now that SMuFL exists, I do not think VexFLow should aim to support non-standard music fonts.

If we did want to continue supporting Gonville alongside SMuFL we have to store data about Gonville that allows us to approprately transform and consume Gonville glyphs as if they were SMuFL compliant

• We need the following data on each Gonville glyph:
  
  
  
  • Horizontal origin alignment
  
  
  • Vertical origin alignment
  
  
  • Orientation for multi-line segments
  
  
  • All multi-line segments in SMuFL are oriented horizontally but in Gonville _some_ are oriented vertically
  
  
  • SMuFL glyph name (eg: accidentalSharp) for the respective VexFlow Gonville glyph identifiers (eg: vb9)
  
  
• Some Gonville glyphs coincidentally match up with SMuFL (like noteheads), so it might only be necessary to maintain a mapping of deviations from SMuFL
• Provide SMuFL compliant metadata for Gonville glyphs

[mscuthbert]

I agree completely. It would be far easier to do this change once, support Bravura, and make a SMuFL compliant version of Gonville later (if someone loved the look of that font) than to let the code support both SMuFL and non-SMuFL fonts.

My sense though is that SMuFL support will have enough people who want to have it in Javascript that it's worth creating a SMuFL API independent of VexFlow (obviously one that is incorporated into VexFlow also and under the same license) and then have VexFlow use that API for all its font calls. It'd make testing easier I'd think.

[Silverwolf90]

Actually, that's a great point. It would be so much simpler to just fire up FontForge or whatever and make the Gonville glyphs SMuFL compliant. No code required!

[0xfe]

I agree with everything on this thread! :-)

I'm totally fine with supporting just SMuFL fonts and doing away with Gonville (until it's SMuFL compliant.) There's a lot of awesome stuff we can do with more data.

I think the best way to move in that direction is by making small incremental changes starting with maybe just a couple of elements.

Cyril, you have a lot of experience with SMuFL, and I see you're experimenting already, so feel free to send out incremental PRs if you can (and are up for it.)

[Silverwolf90]

Will do! https://github.com/0xfe/vexflow/issues/349 outlines down the tasks that need to be done before to make SMuFL support as simple as possible, I'll be slowly chipping away at those whenever I've got the time.