re-introduce font-specific formatting to chord symbol metrics #1569
Conversation
There was a problem hiding this comment.
@AaronDavidNewman is it working? don't you need the following change in chordsymbol?
- const glyphPoints = 20;
- symbolBlock.glyph = new Glyph(glyphArgs.code, glyphPoints, { category: 'chordSymbol' });
+ const glyphPoints = 20 * metrics.scale;
+ symbolBlock.glyph = new Glyph(glyphArgs.code, glyphPoints,);
|
Wow, you're right. But it does seem to be working, weirdly. The key difference is the size of the sharp. If I add my changes to the master branch, and remove them, the size follows the change. It is not working in the sense that change the scale does not actually change the rendered glyph. But the scale of some glyphs is definitely changing. I don't really understand it, I'll have to dig in. There seems to be some type of side-effect going on. master: PR: |
|
@AaronDavidNewman I think that the scale is not working. The differences come from the other parameters. The size is the same. |
|
Maybe it was the other parameters that were wrong, then, and not the scale. I thought the sharp was larger, but I see now that it just isn't formatted correctly. Because the advance width isn't being used. When I apply the scaling now, the glyphs look too small. And I guess that makes sense, because scaling the symbols you'd also have to scale the width of the symbols. So maybe the way to go is just to put the Petaluma metrics back for chord symbols, but without the scaling for now. Main branch Too large: Main branch w/metrics and scaling Too small: Main branch w/metrics and no scaling Just right?: And it's not just a problem with Petaluma, Bravura with scaling, also too small: |
AaronDavidNewman
changed the title
|
I've changed my mind about scaling the individual glyphs. I think the music fonts were made with the glyphs sized relative to each other intentionally, either for readability or effect. So if the left and right parens aren't the same size (like they aren't in Petaluma), it's something we should just accept when we're using that font. The other metrics are different though, because they are needed for formatting. The common metrics only work because most of the fonts are similar enough to Bravura, but they won't work for Petaluma. Also they could be embedded in the fonts themselves so in theory we wouldn't need font-specific formatting, it would just be part of the font package. So anyway, long winded way of saying this is ready for review. |
| const petalumaChordMetrics: Record<string, ChordSymbolGlyphMetrics> = { | ||
| csymDiminished: { | ||
| leftSideBearing: -95, | ||
| advanceWidth: 506, | ||
| yOffset: 0, | ||
| }, | ||
| csymHalfDiminished: { |
There was a problem hiding this comment.
@rvilarl is this approach OK with you?
Before, we had a separate metrics file for the petaluma font.
With this PR, it is hard-coded into the load_petaluma.ts file.
I guess this can serve as a way to illustrate how we can customize metrics even though those files no longer exist.
There was a problem hiding this comment.
This is fine with me for vexflow4.
|
Only one comment. If we do not use the scales why do we leave them? |
|
FYI in Vexflow5 I found specific glyphs for the accidental |
It was an oversight. I removed it from common metrics. |
These are the minimal changes to add chord symbol metrics and have custom for Petaluma.