Proposal: Unifying smufl metrics
rvilarl opened this issue · comments
Today we have a metrics file per font to adjust margins, scales,...
I want to propose to:
- use the same metrics for all the fonts (this is an important step to allow the easy addition of new fonts once we move to FontFace).
- resolve the scaling issues modifying the OTF files following the approach I used for Gonville.
Bravura and Leland metrics are almost identical (I will make a PR to resolve some minor differences)
If we use the same metics for Petaluma, the only issue to resolve is the size of the time signature
current
reference
Thoughts?
I'm all for removing metrics if the information isn't needed or can be derived from other places. Can we have metrics 'fall through' to a different font, the way we do with glyphs?
I know in the case of both chord symbols and jazz ornaments I needed different metrics for Petaluma. It seems there were issues with alternate noteheads also. It can't just be time signatures.
In some cases, the metrics are the same because the glyphs aren't in Leland/Gonville, so it uses the Bravura glyphs. But if Leland (for instance) adds glyphs in the future, it may need separate metrics.
I like the idea of metrics falling through and only storing the changed metrics from a baseline.
There are a lot of obscure symbols in Bravura with some odd metrics, so the ability to specify them in another place would be a help. But I am concerned about Vexflow min file size, so improvements there are definitely welcome.
I'm all for removing metrics if the information isn't needed or can be derived from other places. Can we have metrics 'fall through' to a different font, the way we do with glyphs?
The idea is to have a single set of metrics adjusted to Bravura. Then if there is a need to do any adjustment, on let us say Petaluma, then:
- Make the changes directly to the OTF file using
FontForgelike I did in https://github.com/rvilarl/gonville/blob/main/gonville2smufl.py producing a newPetalumaVexfont. - Regenerate
petaluma_glyphs.ts - Compile
VexFlow.
I know in the case of both chord symbols and jazz ornaments I needed different metrics for Petaluma. It seems there were issues with alternate noteheads also. It can't just be time signatures.
The jazz ornaments have changed but they are now more in line with Bravura
current
reference
bravura
The alternate noteheads were resolved programmatically in #1477
In some cases, the metrics are the same because the glyphs aren't in Leland/Gonville, so it uses the Bravura glyphs. But if Leland (for instance) adds glyphs in the future, it may need separate metrics.
As explained above, this would be adjusted in the OTF file directly
Not sure I'm a fan of having different fonts that are adjusted for Vexflow. One advantage of the new system is that I can load the same font inside Vexflow and in my other parts of my apps and it only needs to be loaded once. If I need to load Petaluma and the PetalumaVex then the overall file size is bigger than just loading metrics.
Not sure I'm a fan of having different fonts that are adjusted for Vexflow. One advantage of the new system is that I can load the same font inside Vexflow and in my other parts of my apps and it only needs to be loaded once. If I need to load Petaluma and the PetalumaVex then the overall file size is bigger than just loading metrics.
Hi Michael, are you loading Petaluma already on the other parts of your app? If yes, how have you coped with the very big numbers? (see height(h) below for petaluma numbers (20+) however clefs are in the same range)
we're not doing it yet, but we do plan to load some jazz font somewhere (was thinking of using Petaluma, but wow, I didn't see this), and it'd be really great to just load it once and use the metrics. Is this something to bring up with Petaluma creators rather than creating a fork?
@mscuthbert already notified to the creators.
@rvilarl I know I'm a month late, but what is the Chord Symbol 'reference' version. In the version I have, those chord symbols look fine, they are not all squished together like that.
@AaronDavidNewman you are right! I introduced the problem, in my local copy, when I was flying because I disabled the downloading of the WEB_FONTS as I did not have internet connection. Sorry for that.
@ronyeh is there are proper work around to work offline
Good question regarding offline.
Can you create a new issue and describe the problem? I can investigate.
see #1530
You can add a element with "preload" attribute to your html. Probably you want to do this if you are generating reference images.
https://stackoverflow.com/questions/1330825/preloading-font-face-fonts/46830425#46830425
Hi @rvilarl
Thanks for your hard work on reducing the need for separate metrics files.
However I have a question.
Before, a VexFlow user could customize a particular glyph of a specific font by modifying that font's metrics file.
Now that every font will be using the common_metrics.ts file, does that mean we can no longer do this? I'm not even sure it's something that people took advantage of... but I thought of this because I saw in a recent PR that Aaron was concerned with the extra big accidentals in Petaluma affecting the layout of the chord symbols.
Anyways, it is just something to think about. It's technically a "capability" of 4.1 that we will be removing from 4.2.
Should we add back the capability of having custom metrics files for each font? Maybe each metrics file can be empty, so it will default to common_metrics. But if something is specified in that font's metrics file, it will override the default value in common_metrics.ts.
So instead of:
Font.load('Bravura', BravuraFont, CommonMetrics)
It would look something like:
const MergedMetrics = { ...CommonMetrics, ...BravuraMetrics };
Font.load('Bravura', BravuraFont, MergedMetrics)
I am working on a single set of metrics for two reasons:
- to be able to use OTFs directly in VexFlow5
- to follow the font creator's choice for the size of the different glyphs (we had already the problem with petaluma's time signature)
I am trying to fix the calculations on run time rather than with metrics.
I am trying to avoid Font.Load all together and use FontFace.