gonville as SMuFL and gootville #1476

rvilarl · 2022-11-26T06:42:01Z

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

mscuthbert · 2022-11-28T00:56:21Z

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 · 2022-11-28T02:47:10Z

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 · 2022-11-28T05:11:02Z

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 · 2022-11-28T05:13:26Z

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 · 2022-11-28T05:51:10Z

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 · 2022-11-28T11:25:52Z

@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 · 2022-11-28T21:04:01Z

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 · 2022-11-30T07:30:41Z

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 · 2022-11-30T08:12:21Z

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 <#1476 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAB2MCOBIFMZIXNDXN6BVDLWK37CZANCNFSM6AAAAAASL2XIGU> . You are receiving this because you were mentioned.Message ID: ***@***.***>

rvilarl · 2022-11-30T15:39:12Z

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

rvilarl · 2022-12-01T08:16:40Z

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

rvilarl · 2022-12-01T20:51:38Z

Almost there, a few glyphs pending.

rvilarl · 2022-12-02T19:06:18Z

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 · 2022-12-03T08:26:10Z

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 · 2022-12-03T08:32:46Z

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

current

reference

rvilarl · 2022-12-03T08:51:40Z

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 custom noteheads refactored #1477, now fixed

rvilarl · 2022-12-03T08:51:56Z

Ready to review

ronyeh · 2022-12-05T22:09:49Z

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 · 2022-12-05T22:14:45Z

src/fonts/load_all.ts

@@ -15,6 +16,7 @@ import { loadPetaluma } from './load_petaluma';
 export function loadAllMusicFonts(): void {
  loadBravura();
  loadGonville();
+  loadGootville();


Are people OK with the main vexflow.js library growing bigger as we add more SMuFL fonts? We do have targets to generate builds with a single font, but I'm wondering if we want the main library to include all fonts.

@0xfe @mscuthbert @AaronDavidNewman

This makes vexflow.js grow 100K.

src/fonts/gonville_metrics.ts

ronyeh · 2022-12-05T22:16:57Z

src/fonts/gonville_metrics.ts

@@ -100,35 +99,46 @@ export const GonvilleMetrics = {
      point: 40,
    },
    down: {
-      point: 40,
+      point: 34,


Are all these small changes due to scaling / offset changes when converted to SMuFL?

What are the main visual differences?

I am trying to make a single set of metrics so that the addition of fonts in the future is easier.

ronyeh · 2022-12-05T22:17:50Z

src/stavetempo.ts

@@ -100,7 +100,7 @@ export class StaveTempo extends StaveModifier {

      x += 3 * scale;
      Glyph.renderGlyph(ctx, x, y, options.glyph_font_scale, glyphProps.code_head);
-      x += glyphProps.getWidth ? glyphProps.getWidth() : 0 * scale;
+      x += Glyph.getWidth(glyphProps.code_head, options.glyph_font_scale);


Was the previous approach buggy? Or is this just a cleaner way to do things?

Yes, the notehead and stem of the stavetempo were not connected. This is what I meant with the second bulltet:

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 custom noteheads refactored #1477, now fixed

Reference

Current

ronyeh · 2022-12-05T22:19:13Z

src/clef.ts

@@ -78,7 +78,7 @@ export class Clef extends StaveModifier {
        point: 0,
      },
      percussion: {
-        code: 'restMaxima',
+        code: 'unpitchedPercussionClef1',


Is this a bug fix?

Yes, the percussion clef was drawn using a rest maxima. This is what I meant with the first bulltet:

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 custom noteheads refactored #1477, now fixed

Reference

Current

ronyeh · 2022-12-06T00:10:24Z

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 · 2022-12-06T15:30:03Z

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 · 2022-12-06T15:59:09Z

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 <#1476 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAB2MCPSMAI6OK7ULAEY7GDWL5LYNANCNFSM6AAAAAASL2XIGU> . You are receiving this because you were mentioned.Message ID: ***@***.***>

ronyeh · 2022-12-06T16:00:50Z

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 > <#1476 (comment)>, or > unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAB2MCPSMAI6OK7ULAEY7GDWL5LYNANCNFSM6AAAAAASL2XIGU> > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> >

rvilarl · 2022-12-06T17:35:48Z

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 · 2022-12-06T17:53:22Z

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

rvilarl · 2022-12-16T22:31:41Z

I will submit a new PR with Gootfile addition only.

rvilarl requested a review from AaronDavidNewman November 27, 2022 10:52

rvilarl marked this pull request as draft November 30, 2022 07:30

rvilarl changed the title ~~gonville replaced by gootville~~ gonville as SMuFL and gootville Nov 30, 2022

rvilarl marked this pull request as ready for review December 2, 2022 19:04

rvilarl requested a review from ronyeh December 2, 2022 19:04

rvilarl added the 4.x label Dec 2, 2022

rvilarl added 3 commits December 3, 2022 09:35

gonville smufl & gootville

4e4dd6e

fix percussion clef code

0e8c0f9

fix stavetempo

19bd45b

ronyeh reviewed Dec 5, 2022

View reviewed changes

src/fonts/gonville_metrics.ts Show resolved Hide resolved

ronyeh reviewed Dec 5, 2022

View reviewed changes

rvilarl mentioned this pull request Dec 6, 2022

Usage of FontFace rather than paths #1479

Closed

rvilarl marked this pull request as draft December 6, 2022 20:21

rvilarl mentioned this pull request Dec 6, 2022

Fix/clef code and tempo notes #1481

Merged

rvilarl closed this Dec 16, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

gonville as SMuFL and gootville #1476

gonville as SMuFL and gootville #1476

rvilarl commented Nov 26, 2022 •

edited

Loading

mscuthbert commented Nov 28, 2022

AaronDavidNewman commented Nov 28, 2022

rvilarl commented Nov 28, 2022

rvilarl commented Nov 28, 2022

ronyeh commented Nov 28, 2022 •

edited

Loading

sschmidTU commented Nov 28, 2022

mscuthbert commented Nov 28, 2022

rvilarl commented Nov 30, 2022

ronyeh commented Nov 30, 2022 via email

rvilarl commented Nov 30, 2022

rvilarl commented Dec 1, 2022

rvilarl commented Dec 1, 2022

rvilarl commented Dec 2, 2022

rvilarl commented Dec 3, 2022

rvilarl commented Dec 3, 2022

rvilarl commented Dec 3, 2022

rvilarl commented Dec 3, 2022

ronyeh commented Dec 5, 2022

ronyeh Dec 5, 2022

rvilarl Dec 6, 2022

ronyeh Dec 5, 2022

rvilarl Dec 6, 2022

ronyeh Dec 5, 2022

rvilarl Dec 6, 2022

ronyeh Dec 5, 2022

rvilarl Dec 6, 2022

ronyeh commented Dec 6, 2022 •

edited

Loading

rvilarl commented Dec 6, 2022

ronyeh commented Dec 6, 2022 via email

ronyeh commented Dec 6, 2022 via email

rvilarl commented Dec 6, 2022

rvilarl commented Dec 6, 2022

rvilarl commented Dec 16, 2022

gonville as SMuFL and gootville #1476

gonville as SMuFL and gootville #1476

Conversation

rvilarl commented Nov 26, 2022 • edited Loading

mscuthbert commented Nov 28, 2022

AaronDavidNewman commented Nov 28, 2022

rvilarl commented Nov 28, 2022

rvilarl commented Nov 28, 2022

ronyeh commented Nov 28, 2022 • edited Loading

sschmidTU commented Nov 28, 2022

mscuthbert commented Nov 28, 2022

rvilarl commented Nov 30, 2022

ronyeh commented Nov 30, 2022 via email

rvilarl commented Nov 30, 2022

rvilarl commented Dec 1, 2022

rvilarl commented Dec 1, 2022

rvilarl commented Dec 2, 2022

rvilarl commented Dec 3, 2022

rvilarl commented Dec 3, 2022

rvilarl commented Dec 3, 2022

rvilarl commented Dec 3, 2022

ronyeh commented Dec 5, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ronyeh commented Dec 6, 2022 • edited Loading

rvilarl commented Dec 6, 2022

ronyeh commented Dec 6, 2022 via email

ronyeh commented Dec 6, 2022 via email

rvilarl commented Dec 6, 2022

rvilarl commented Dec 6, 2022

rvilarl commented Dec 16, 2022

rvilarl commented Nov 26, 2022 •

edited

Loading

ronyeh commented Nov 28, 2022 •

edited

Loading

ronyeh commented Dec 6, 2022 •

edited

Loading