Petaluma A7 chord symbol

Is it me or is the 7 ever so slightly too close to the A when using Petaluma:
It’s touching, which I don’t think looks as clear as other chord symbols?

Yes, it is a bit close. At the moment all of the specific kerning data for chord symbols is based on the appearance of regular text fonts, like (but not limited to) Academico. Possibly I have made the kerning of Petaluma Script too tight in general, though it’s quite representative of how tight the handwritten text looks in the books on which the font family is based. You can adjust this in the Project Default Chord Symbol Appearance dialog so that you don’t need to adjust this more than once, by the way.

Hi Daniel, I love the font in general and only noticed that on A7, all the others look perfect. Thanks for the reply - that’s easy to move with the dialog

There is no kerning between the A and 7 glyphs in Petaluma Script (nor in Academico). The adjustments in Dorico Pro 2 look like they may be calculated programatically. When full size, the 7 in both fonts is shifted to the left by the same amount for an A7 chord symbol. When the chord symbol is shown with a superscript 7, the full-sized 7 is scaled down and shifted up (and to the left). Also, it looks like the chord symbols use the bounding box of the glyph paths/drawing (leaving out the left/right side bearing space), so even without adjustments, the spacing may be tighter than the font in normal use. This was based on looking at the Chord Symbol Appearance Editor, resetting the offsets, looking at the boxes and glyph placement.

Though neither of those fonts implement the superscript OpenType feature, it would be useful if Dorico used it when a font does have the glyphs and feature available. Then the superscript glyphs should feel more like the same weight of the capital letter (instead of a little lighter/thinner in weight) and what the type designer intended. And appropriate kerning, when needed, would be specified in the font for those pairs, e.g., A and superscript 7, as the space between the glyphs would be different than between A and 7, of course.

To check if Dorico handled superscript glyphs, I tested with one of my fonts that had the superscript glyphs and OpenType superscript feature.

The kerning for chord symbols is not stored in the font, Jeff, because it has to kern between characters in different fonts (i.e. the text font and the music font).

Dorico cannot yet access OpenType features beyond the most simple glyph substitution ones for things like ligatures because they are not currently exposed by the Qt framework that we are using. We certainly don’t rule out building this support ourselves, but it’s not something we are likely to do imminently.

Might it eventually be possible for a third party to specify what those adjustments should be between symbols in pairs of fonts so that reasonably good defaults could be set by the type designer for those chord symbols? Perhaps also allowing one to also specify alternate glyphs to use when superscripting, for example, until support for some of those OpenType features is available. (Just thinking out loud, so to speak.)

Not knowing your codebase, I wonder if it might make sense to use the font’s spacing and kerning data for when pairs of glyphs are from the same font for chord symbols, as in the non-superscript A7 example, and then the externally defined adjustments for when between pairs of fonts.

Dorico cannot yet access OpenType features beyond the most simple glyph substitution ones for things like ligatures because they are not currently exposed by the Qt framework that we are using. We certainly don’t rule out building this support ourselves, but it’s not something we are likely to do imminently.

It’s unfortunate that the Qt framework doesn’t expose the OpenType font features. But, it also explains why some other applications that one would expect to support those features do not. It looks like Qt might use the HarfBuzz shaping engine, underneath, so there may be eventual potential for support. I totally understand the priorities.

Thanks for the detail, Daniel.

Hi there,

I’ve come back to this threat out of curiosity to see if anyone has cracked it. Interesting to see that nothing has been attended to with this issue still.

The unusual spacing of A7 is still very noticeable for me, whenever I use Petaluma.

You’re right that the font hasn’t been modified, but do you know about the easy fix for this?

Engraving Options–Chord Symbols–Project Default Appearances.

Many thanks!

That’s very curious indeed!
Especially since C7 has a default 0.75 offset… :thinking:

I would have thought that there would be a new version of Petaluma that fixes this problem. I understand there could be reluctance to re-issue the same font because people may already have done editing in their projects to work around this problem. But surely a “Petaluma 2” font or something like that would be helpful. I disagree that the Project Default Appearance workaround is an “easy fix” because you have to do those edits for every variation of A7 you use (e.g. A7, A7b9, A7#11, A7sus, etc.) and then you have to make sure those overrides are in every project template you use.

I really like the looks of Petaluma, except for this one detail. Are there any other similar fonts that don’t have this problem; that one can switch to simply by changing the font selection – i.e. without creating more problems than one solves? For example, the Norfonts seem to have comprehensive support for Dorico. Bopmusic and Copyist look like styles that would work for me, but every example I saw had every text item as all caps… I didn’t find any examples in that font showing the A7, but it looks like all the chord symbols that do appear in examples are well spaced.
BopMusic (SMuFL) Font ‣ NorFonts
The Copyist (SMuFL) Font ‣ NorFonts

The basic problem, it seems to me, is that the character “7” has the bottom extended all the way to the left. If that vertical stem could arch just a little, I don’t think there would be any problem, and probably would not disturb any previously created projects.

Well, I happen to think that the only problem with A7 is, that for some reason the offset of the “7” is somehow too far to the left by default. If this could be adjusted globally and permanently, we’d be done with this issue.
All other simple “7” chord symbols have positive offsets, only A7 has a negative one.


I’m not sure but I think I understand that the offset is like that because it looks correct for A7 chords when written in Bravura. And Petaluma is restricted to sharing the same offset info.