gonville as SMuFL and gootville

[rvilarl]

fix #1475 Now including Gootville and a SMuFL variant of Gonville. See https://github.com/rvilarl/gonville

[mscuthbert]

What does this do to the minimum build size of Vexflow + one (non-jazz) font? The font sizes of full SMuFL fonts are a concern.

[AaronDavidNewman]

Gootville otf is smaller than Gonnville. It looks like the glyphs.ts is smaller also, which is a little surprising. So it shouldn't affect it negatively.

I didn't try it though, I am not sure how to create a single-font build (even though I think @ronyeh added targets for it).

[rvilarl]

What does this do to the minimum build size of Vexflow + one (non-jazz) font? The font sizes of full SMuFL fonts are a concern.

It is about 60k smaller

-rw-r--r--. 1 rodrigo rodrigo 509448 nov 27 22:43 reference/cjs/vexflow-gonville.js
-rw-r--r--. 1 rodrigo rodrigo 446958 nov 28 06:08 build/cjs/vexflow-gonville.js

[rvilarl]

Gootville otf is smaller than Gonnville. It looks like the glyphs.ts is smaller also, which is a little surprising. So it shouldn't affect it negatively.

I didn't try it though, I am not sure how to create a single-font build (even though I think @ronyeh added targets for it).

just use grunt and you will get it

-rw-r--r--. 1 rodrigo rodrigo 446958 nov 28 06:08 build/cjs/vexflow-gonville.js

[ronyeh]

Thanks for working on this! I think we need @0xfe 's opinions on this. There are a bunch of stakeholders here, including OSMD and possibly music21j, who may rely on "Gonville" being actual Gonville and not Gootville.

I saw this discussion from 2014: https://musescore.org/en/node/41736

My views:

• We probably shouldn't call it "Gonville" if it's actually Gootville, a font inspired by Gonville.
• I love SMuFL. I think at some point, we should retire Gonville if we want to make VexFlow 100% SMuFL.
• If folks really want this font, I'd like to hear their feedback on this PR ( ping @mscuthbert @sschmidTU )

Maybe if people want it, we should consider adding this font alongside Gonville for VexFlow 4.2? Then when we decide to remove Gonville altogether, we can bump the major revision to VexFlow 5.0?

[sschmidTU]

@ronyeh the musescore discussion doesn't say anything about differences of Gonville vs Gootville as far as I've seen. But it somewhat shows how the creator introduced it to Musescore.

I still have to fully test Gootville, though I'm not a fan of the bigger accents, and I'm not 100% sure it's a replacement without drawbacks for all users for all use cases. I would prefer keeping Gonville as an option. Maybe gonville could be a build target? That way, you can choose whether you want to have Gonville in your build or not.

[mscuthbert]

I agree that the name should change -- and probably there should be a version where both fonts are available (okay to make gootville the default).

I used https://elbsound.studio/music-font-comparison.php?font=Gootville and the differences are quite slight but of what does change everything seems like an improvement except that the default trill-extension vertical positioning which seems a little too high to me (but MUCH better than the default horizontal positioning before). And can't say I'm a huge fan of the new mf's "m" placement. The larger time signatures are really great. The extra space between the default 16th note (downstem) tail and the notehead is very nice . The "Symbol mix" comparison shows huge improvements (as with the "Chromatic cluster" in the Contemporary comparison). Though the tempo mark vertical placement seems wrong to me (and I prefer the wider two-measure repeat in Gonville).

There's also an advantage in that I currently generate some scores automatically from MuseScore (good MusicXML rendering and png generation) and interactive scores of course in VexFlow. That MuseScore also uses Gootville will make the two examples less different (the different colored stafflines will be the only giveaway; but it's an early decision of VexFlow that I LOVE and hope never changes. Any score designed for computer display should use some amount of gray-shading on staff lines, even if just a little; black is only for printing).

[rvilarl]

I am working on a SMuFL compatible Gonville (moving the glyphs to the SMuFL specified location). I will change this PR to draft and keep it open so that you can see the progress. I will also set Gootville as an additional font.

[ronyeh]

Wow, that's a cool contribution and it seems like hard work! :-)

A SMuFL-ized Gonville would definitely be useful. FYI: this seems to be okay under the Gonville license.

====== Licence

The Gonville font files themselves may be used without restriction. You don't even have to preserve a copyright notice or anything. Use freely and enjoy.

In particular, this means that you may embed the Gonville font or portions of it in PostScript, PDF, SVG or other document file formats without incurring any constraint whatsoever on your subsequent use or licensing of those files.

(On the other hand, if you're using the Gonville outlines in a context where they might be mistaken for your own work, e.g. incorporating them into a music typesetting program, it would be polite to give me credit for the design.)

The source code that generates the font files (if you download the source archive below, or look in the git repository) is distributed under the MIT licence.

For more details, see the file called LICENCE in the distribution archive.

On Tue, Nov 29, 2022 at 11:30 PM Rodrigo Vilar @.***> wrote:

I am working on a SMuFL compatible Gonville (moving the glyphs to the SMuFL specified location). I will change this PR to draft and keep it open so that you can see the progress. I will also set Gootville as an additional font.

— Reply to this email directly, view it on GitHub https://github.com/0xfe/vexflow/pull/1476#issuecomment-1331746473, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAB2MCOBIFMZIXNDXN6BVDLWK37CZANCNFSM6AAAAAASL2XIGU . You are receiving this because you were mentioned.Message ID: @.***>

[rvilarl]

Concept already there! @ronyeh the SMuFL-izer is tools/fonts/gonville2smufl.py now the table has to be completed. :)

[rvilarl]

It is more complex than expected, the origin has to be adjusted as well for some glyphs. Using translate to fix this.

[rvilarl]

Almost there, a few glyphs pending.

[rvilarl]

Ready to review. I have moved the Gonville SMuFL generation to https://github.com/rvilarl/gonville I will also reference it in smufl.org should anyone want to use it.

[rvilarl]

Gonville SMuFL has been created moving the original Glyphs to the SMuFL specified location. The render coordinates had to be adjusted on several instances.

Keys are a little bit smaller: current reference

Fermatas a little bit bigger: current reference

[rvilarl]

There were some bugs in the previous font that are now resolved:

current

reference

[rvilarl]

Looking in detail at all the tests, I found two bugs:

• clef code used for percussion was wrong, now fixed.
• stavetempo had not been aligned with #1477, now fixed

[rvilarl]

Ready to review

[ronyeh]

Just a general question, do we need Gootville if you have converted Gonville to a SMuFL font?

I see that the other PR #1479 also includes Gootville. Do the PRs overlap?

[ronyeh]

Keys are a little bit smaller:

Hi, do we have a good reason for the visual changes of Gonville? I'm concerned that things are visually different without a good reasoning for the changes.

For example, you highlight that the treble clef is now smaller. Is smaller "more correct"? Is there a guideline for the sizing and positioning for all the engraving symbols?

For example, if you look at the example listed on the Gonville homepage: https://www.chiark.greenend.org.uk/~sgtatham/gonville/

The treble clef's G spiral is centered on the G line and touches both the E and the B lines. https://www.chiark.greenend.org.uk/~sgtatham/gonville/after.png

Your current sample is smaller, so the spiral no longer spans the bottom 3 staff lines. https://user-images.githubusercontent.com/22865285/205374425-7f709d7e-d38e-4b7e-ac23-fcb0d999b504.png

The previous version's reference image seems closer to what the Gonville designer intended.

In fact, I think we should use the Gonville homepage's example as a target. VexFlow should render that score as close as possible to the original example:

[rvilarl]

Keys are a little bit smaller:

Hi, do we have a good reason for the visual changes of Gonville? I'm concerned that things are visually different without a good reasoning for the changes.

Gonville as a font had two major problem:

• the glyphs were not loacated as specified by SMfLS
• the origin of the glyphs were not well positioned

This what I resolved in https://gihub.com/rvilarl/gonville

Now it was made evident that the scale of some glyphs is not correct. This can be addressed in https://gihub.com/rvilarl/gonville with a minor modification.

My theory is that if the fonts are as per SMuFL spec a common set of metrics can be used.

For example, you highlight that the treble clef is now smaller. Is smaller "more correct"? Is there a guideline for the sizing and positioning for all the engraving symbols?

Smaller is not more correct. However in the particular case of the clef, I believe that the problem is the point defined in the metric: 32.

  clef: {
    default: {
      point: 32,
      width: 26,
    },
    small: {
      point: 26,
      width: 20,
    },

It seems that it sould be bigger for the other fonts as well: Gonville Petaluma Bravura

[ronyeh]

Would it be possible to get this PR to a point where Gonville has no visual differences? I would be much happier to accept the PR if it had visual diffs, unless they were actually bugs that you fixed.

At this point I will assume that VexFlow's engraving is "correct" and any changes should point out why the existing layout is incorrect, via examples (like from Gonville website or lilypond or musescore or other engraving tools), or from texts like Elaine Gould's book.

Thanks!

On Tue, Dec 6, 2022, 7:30 AM Rodrigo Vilar @.***> wrote:

Keys are a little bit smaller:

Hi, do we have a good reason for the visual changes of Gonville? I'm concerned that things are visually different without a good reasoning for the changes.

Gonville as a font had two major problem:

• the glyphs were not loacated as specified by SMfLS
• the origin of the glyphs were not well positioned

This what I resolved in https://gihub.com/rvilarl/gonville

Now it was made evident that the scale of some glyphs is not correct. This can be addressed in https://gihub.com/rvilarl/gonville with a minor modification.

My theory is that if the fonts are as per SMuFL spec a common set of metrics can be used.

For example, you highlight that the treble clef is now smaller. Is smaller "more correct"? Is there a guideline for the sizing and positioning for all the engraving symbols?

Smaller is not more correct. However in the particular case of the clef, I believe that the problem is the point defined in the metric: 32.

clef: { default: { point: 32, width: 26, }, small: { point: 26, width: 20, },

It seems that it sould be bigger for the other fonts as well: Gonville [image: Clef Clef_Test Gonville] https://user-images.githubusercontent.com/22865285/205953730-32406ef2-d8a0-4395-9bf0-788c824f6984.png Petaluma [image: Clef Clef_Test Petaluma] https://user-images.githubusercontent.com/22865285/205953731-1cbaf92e-eae5-4396-9079-f6ec5240c51c.png Bravura [image: Clef Clef_Test Bravura] https://user-images.githubusercontent.com/22865285/205953733-ed902bfd-c616-40e3-9bb9-cd0120215fc7.png

— Reply to this email directly, view it on GitHub https://github.com/0xfe/vexflow/pull/1476#issuecomment-1339555764, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAB2MCPSMAI6OK7ULAEY7GDWL5LYNANCNFSM6AAAAAASL2XIGU . You are receiving this because you were mentioned.Message ID: @.***>

[ronyeh]

Sorry for mistyping.... I meant:

I would be much happier to accept this PR if it had NO visual diffs, other than ones from bugs that you fixed.

On Tue, Dec 6, 2022, 7:58 AM Ron Yeh @.***> wrote:

Would it be possible to get this PR to a point where Gonville has no visual differences? I would be much happier to accept the PR if it had visual diffs, unless they were actually bugs that you fixed.

At this point I will assume that VexFlow's engraving is "correct" and any changes should point out why the existing layout is incorrect, via examples (like from Gonville website or lilypond or musescore or other engraving tools), or from texts like Elaine Gould's book.

Thanks!

On Tue, Dec 6, 2022, 7:30 AM Rodrigo Vilar @.***> wrote:

Keys are a little bit smaller:

Hi, do we have a good reason for the visual changes of Gonville? I'm concerned that things are visually different without a good reasoning for the changes.

Gonville as a font had two major problem:

• the glyphs were not loacated as specified by SMfLS
• the origin of the glyphs were not well positioned

This what I resolved in https://gihub.com/rvilarl/gonville

Now it was made evident that the scale of some glyphs is not correct. This can be addressed in https://gihub.com/rvilarl/gonville with a minor modification.

My theory is that if the fonts are as per SMuFL spec a common set of metrics can be used.

For example, you highlight that the treble clef is now smaller. Is smaller "more correct"? Is there a guideline for the sizing and positioning for all the engraving symbols?

Smaller is not more correct. However in the particular case of the clef, I believe that the problem is the point defined in the metric: 32.

clef: { default: { point: 32, width: 26, }, small: { point: 26, width: 20, },

It seems that it sould be bigger for the other fonts as well: Gonville [image: Clef Clef_Test Gonville] https://user-images.githubusercontent.com/22865285/205953730-32406ef2-d8a0-4395-9bf0-788c824f6984.png Petaluma [image: Clef Clef_Test Petaluma] https://user-images.githubusercontent.com/22865285/205953731-1cbaf92e-eae5-4396-9079-f6ec5240c51c.png Bravura [image: Clef Clef_Test Bravura] https://user-images.githubusercontent.com/22865285/205953733-ed902bfd-c616-40e3-9bb9-cd0120215fc7.png

— Reply to this email directly, view it on GitHub https://github.com/0xfe/vexflow/pull/1476#issuecomment-1339555764, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAB2MCPSMAI6OK7ULAEY7GDWL5LYNANCNFSM6AAAAAASL2XIGU . You are receiving this because you were mentioned.Message ID: @.***>

[rvilarl]

I also prefer that, but going to the clef topic as an example, I would use a different point value in the metrics rather than upscaling Gonville in comparison to the other ones, would not you?

[rvilarl]

I will try a conversion without changes in origin and metrics as a first step.

[rvilarl]

I will submit a new PR with Gootfile addition only.