Set the size of fretboard offset text as part of the style

• Jan 19, 2014 - 20:04
S5 - Suggestion

I cannot read the super-tiny text for the fret offset that accompanies the fretboard diagrams.

I also could not find a setting in the style to increase the font (if there is one, please let me know!).

It would be great if this font size could be controlled as part of the style. In addition, having the ability to adjust the size of the overall block would be nice too.


The only text I *normally* see are the X's and O's at the top of the strings, and I can't imagine those being bigger. They already practically touch each other for adjacent strings. And if you then decide the show the diagram starting somewhere other than the top, the number that displays appears the same size as the X's and O's. So I guess you'd be wanting to increasing the latter but leave the former alone? Is that standard practice? I could also easily see wanting the whole diagram bigger, with the text scaling accordingly.

Anyhow, there don't seem to be any user-accessible controls for any of this. It's all hardcoded in fret.cpp. It all scales, as does almost everything in MuseScore, with the Space setting. So you can get bigger diagrams with correspondingly bigger text by using bigger staves. I suppose you could try playing tricks with small and invisible staves - attaching a fret diagram to a normal staff that you make invisible, then having your other staves be small, and using an appropriate large Space setting to make your small staves look normal. Not fun, but you did ask for workarounds.

Anyhow, FYI, there is no such thing as a "critical" feature request. Critical is reserved for bugs that cause crashes, corruption, loss of data, etc. But looking at the code, it seems it would be a pretty simple matter to add the following as style parameters:

- stringDistance (currently hardcoded to 0.7sp)
- fretDistance (current hardcoded to 0.8sp)
- font (current hardcoded to FreeSans 4pt, scaled by sp)

I suppose the same font could be used for both X/O and for fret offset, but really, I think the X/O is better off scaling with string distance. So if there really is consensus that it would be common to want the fret offset font larger in proportion, I think maybe only that should be controlled by the style.

Features are, as a general policy, already frozen for 2.0. Not sure if this would end up being an exception. There's a few other things about fret diagrams that feel "unfinished" right now (not the least of which is the apparently useless parameter in style / general / chord symbols to control distance between fret diagram and chord symbol), so maybe this all could get more attention.

Thanks for the quick response.

I'm referring to the text that appears to the left of the fretboard if you move it up the neck. That text is super small and it is really important for that information is quickly readable. A 4pt "6" versus "8" is hard to distinguish.

I agree the X's and O's can scale with the diagram. They are the only two characters that appear there, so they can be relatively smaller and still be distinguishable.

I would suggest ~10pt for the fret number text, but of course, having this as a preference would be more suitable.

Thanks for the suggestions on workarounds. I ended up using a text block and moving it up to the diagram, or just writing it in pen, both a bit clunky.

Anything to get this in soon would be appreciated - even a one-off build I could use to re-print some of my pages.

Do you guys do "hidden" settings - i.e., something that is only editable in a settings file and not in the UI? That would be OK by me for the short term in an effort to keep the UI frozen.


That number is indeed very small, but it is hardcoded and made to fit into a rectangle of fret- and sting distance
I think the entire fretboard diagram needs to be larger

I agree that the fretboard diagrams could be larger, but the text needs to be proportionally larger even so.

If it is constrained to the fretboard grid, maybe it could be sized up to a 2x2 grid instead of 1x1.

I'm attaching a PDF snippet of a score. See the lower two fretboard diagrams. I just used a text object to mark these. I think this size text is pretty good.

Attachment Size
fretboard.pdf 37.84 KB

I agree it should be centered on the first fret. But, I wouldn't worry about it being exactly centered if that causes problems (a few pixels of play won't matter).

FWIW, looking around at published sheet music, it really seems MuseScore's defaults are pretty spot on size-wise. Both the size of the fret diagram relative to the staff and the size of the text relative to the diagram seem competely in line with the published examples I see. And in particular, I was unable to find any published exampes where the fret offsets were anywhere near as large as the example posted above. On the other hand, I think it's all crazy small in published music too, and the idea of being able to customize this appeals to me, probably using the parameters I mentioned. For simplicity, perhaps just two: one for the overall diagram size, one for fret offset font size.

In general, I don't think having inaccessible parameters - ones set only via configuration files as opposed to dialogs - is looked well upon. Nor are explosions of dialogs, though. It's been suggested that some day MuseScore might add some sort of "configuration editor" to give access to a number of parameters that don't otherwise make sense to expose. I'm pretty sure this is not being considered for 2.0, and I don't know if this is the sort of thing that it is intended for anyhow.

If you can follow the instructins for building MuseScore yourself, it would be an easy matter to build yourself a custom version by changing fret.cpp. But while of course anyone could do that for you, I don't think anyone would want to sign up for doing so every time a bug fix came along you were interested in - so it's really something you might want to try for yourself.

I took a look at this in the code and ran into an issue with the existing fret number layout. It is using a fixed horizontal offset of .5 the string distance. That works for offsets < 10 (i.e., a single digit) but not for offsets like 11, 12, etc.

So, there is an existing bug that can be fixed with this change:


if (_fretOffset > 0) {
painter->drawText(QRectF(-stringDist, fretDist*.5, .0, .0),
Qt::AlignVCenter | Qt::TextDontClip,


if (_fretOffset > 0) {
QString fretString = QString("%1").arg(_fretOffset+1);
qreal fretStringWidth = fm.width(fretString);
painter->drawText(QRectF(-fretStringWidth -stringDist*.5, fretDist*.5, .0, .0),
Qt::AlignVCenter | Qt::TextDontClip,

From there, I was able to create a local version that scales up the string. The existing font object is static, so I created a copy, scaled it, and used it to draw the fret number.

I haven't read the rules on contributing fixes so I'm not sure if you want me to submit anything for the bug fix above.

Thanks - it would be great if you could submit this. I think this change needs to be linked into the preferences pane and I don't know how to do that.

Here's the code I'm using to scale up by 2x. fretNumScale should be linked to the prefs. And, maybe this needs to be another static font rather than creating one every time draw() is called? And maybe the font should be set back to the smaller font when done?

This is my first look into the code so I'm not sure what the conventions are.

Anyway, here's the code snippet:

QString fretString = QString("%1").arg(_fretOffset+1);
qreal fretNumScale = 2.0;
QFont biggerFont(font);
biggerFont.setPixelSize(font.pixelSize() * fretNumScale);
QFontMetricsF bfm(biggerFont);
qreal fretNumberStringWidth = bfm.boundingRect(fretString).width();
painter->drawText(QRectF(-fretNumberStringWidth -stringDist*0.5 , fretDist*.5, .0, .0),
Qt::AlignVCenter | Qt::TextDontClip,

Thanks. That second commit should definitely get a review.

It may be inefficient to create a new font object every time a fretboard is drawn. It would probably be better to follow the pattern for the 'font' member and create it once and update it when the prefs are set.

There is also a question of whether it should get its own full text style, or just have a size parameter you set in style / general / chord symbols. I'd recommend the latter, and have both the overall diagram size and font size settable there. It's kind of a hack, but you'll see Figured Bass does the same. Chord symbols probably could as well, but there no real advantage since the text style already existed in 1.X.

Agreed. Also see the bug I filed about the offset to the staff. That could be set in this panel as well.

There may be more work here with the chord names along with the fretboard diagrams. I often use them together and have to arrange them manually. It would be nice if they knew about each other and did an automatic layout.

Yes, vertical distance belongs here as well.

Also, we've observed before there is an existing parameter for distance between fret diagram and chord symbol, but that it doesn't seem to do anything. It seems from the code it affects chord symbol position *if* the chord symbol is a child of the fret diagram rather than of the segment, but I don't see any way to make that happen. I think this is leftover from when for a while there was a concept of a frame containing both?

Anyhow, I think we don't need that parameter to work. I guess the parameter was there so a chord symbol would automatically reposition itself relative to the fret diagram if present. But in my experience, it's usually all or nothing. You either have fret digrams everywhere there are chords or you have them nowhere. You can get this behavior already simply by choosing an appropriate vertical position for the chords. If you really do have some chords with fret diagrams and some without - which I don't see often - it shouldn't be a huge hardship to reposition manually.

But actually, it's probably not a big deal to alter the chord symbol layout to check to see if a fret diagram exists at the same segment, rather than check if the parent is a fret diagram.

Re: "all or nothing" - that may be the case in commercially printed sheet music, but for my usage (creating lead sheets for musicals), I'm using chord symbols everywhere and fretboard diagrams only where there is a particular, non-obvious voicing that I want to utilize.

So, I'm commonly creating pages with dozens of chord names and only a few fretboard diagrams.

Understood. If it's as easy to fix as I suggested above, maybe it could be included in a set with the others.

But also, I would think in your case, you'd be likely to want to put the fret diagrams *above* the chord symbols so the chord symbols would be in a consistent location. In which case, it's still true that simply by setting appropriate default vertical positions, no special handling is necessary. And even if you do decide to move the chord symbols above the fretboard diagrams for these cases, it still special purpose enough of a situation where asking the user to move the chord symbol manually is not unreasonable. The Inspector makes it easy enough to just apply a vertical offset to as many chord symbols as you want at once.

Good discussion. I'm not sure if above/below really matters for the fretboard diagrams. But, as a data point, looking through the ~50 pages of music I'm working on, I've consistently put them below the chord name.

In terms of priority, my thoughts are:

- larger fret offset numbers (done)
- preference to fine tune fret offset numbers font size (this bug)
- I settled on a 2.5x zoom versus the 2.0 that was submitted
- preference to fine tune the offset of the fretboard diagrams (#24494: FretDiagram : make the vertical offset a user adjustable parameter)
- consistent auto-placement of fret diagram and chord name w/preferences to fine-tune (the discussion above - new bug needed?)
- fretboard diagram UI tweaks (#24487: Fretboard Properties window : field labels align to wrong input region)

I did try putting the fretboard diagrams above the chord names and doing so increases the distance between the staves, which may be why I have them in the order I do (moving the chord names doesn't seem to do that).

I'm not familiar with the QT UI frameworks, so I'm probably not the person for UI tweaks or wiring up preferences, yet...

Zscore - Just to clarify - you are saying you put fret diagrams under chord symbols even in cases where the fret diagrams are not present for all chords? If so, does that means the chord symbols that do not have fret diagrams are at a lower vertical position than those that do, or that the chord symbols without fret diagrams have empty space below them? If the latter, you can get this effect with the current style settings. If the former, manual adjustment would currently be necessary, but a fix to the "distance to fret diagram" style setting would eliminate that need. I'd be curious though to see if this is something that is a common standard in published music or not.

Jojo - code looks basically good to me, although the variable name biggerFont doesn't do it for me :-). I do kind of like having this be a scale factor rathert han outright font size, as it makes it seem less like soemthing there needs to be an actual text style for.

I've attached an example. As I noted, I may be doing this because moving the fretboard diagrams up increases the space between staves when they start to get closer.

The biggerFont variable was mine. That was from a local patch I was using to see the symbols. Don't blame Jojo ;)


Attachment Size
chords.pdf 34.11 KB

The examples clarifies nicely, thanks. I'm still wondering if this is something that "standard" that a notation program is "supposed" to support well, or if it's the sort of special case thing that one would expect to need manual adjustments for.

BTW, if that's the size for fret offset you are proposing, I will say that I feel that should definitely *not* be the default. That looks to be almost (but not quite) twice as big as anything I've seen in a published score. From what I can see, the usual size of the fret offset is just slightly more than the distance between frets. But the whole diagram is often printed larger if there are chords that require fret offsets.

As long as people are looking at this, two other things that could be worth adding:

1) Most of the published scores I see put the fret offset to the *right*, not the left. This could be a style parameter too.

2) Most published scores I see also have additional text, like "4 fr." or "4th fret". I could imagine a style parameter for text to append, but in the latter case, it would need to be "1st", "2nd", "3rd", "4th", etc - not always the same. So maybe better to allow text to be entered directly in the fret diagram. This might have to wait.

That is my extra big font size so I can see it in a dimly lit pit. That is a 2.5x scale. Not a proposed default, but a good example of why a style setting would be good. I think 2.0 is a good default.

I've seen the fret number on either side. I like the number on the left by itself since I read left-to-right and want to see the number first. It is also compact. But, having it on the right does support a suffix better.

I'm on my iPhone now but I can attach an excerpt later from a Berklee Music course that has the fret number on the right (sigh) but also fairly large (yeah). It was likely done in Finale.

Just goes to show that there are no easy features.

my proposed code change may look OK (except for variable names, which I'll fix) but it doesn't work. :-(
a) the font is huge
b) not changeable
Scratching my why...

Need to get that going before adding the left/right option.

Edit: a couple hours later
I got it, instead of accessing e.g. "ST_fretNumScale" directly one has to use "score()->styleD(ST_fretNumScale)".
That does work in the score, but not (yet) in the properties dialog, but I'd like that to be a proper preview of what you'd get.

Anyway, here's the version that works for the score: a1cfe86 (and the previous version removed from GitHub)

And here a commit on top for the left/right option: 5393c28

I just tried out Jojo's branch and the preferences work as expected. I'm able to adjust the size of the font for the fret offset using the style editor.

It would be nice if this followed one of the text styles for font, but I'm happy with what we have now.

Some UI nits for the Style tab:

1. since both chord symbols and fretboard diagrams are now included in this tab, the section headers are ambiguous. If the Chord Symbol entries could all be grouped instead of having 6 separate groups, that would help. Otherwise, I think they should include a prefix to delineate "Chord Symbol" controls from "Fretboard" controls.

2. "Capo" should probably be last in the list and not between two sections that deal with size / position

3. the "Distance to fretboard diagram" parameter seems to do nothing. It should be removed until it works.

4. the value the user enters for offsets should be standardized. In the case of chord symbol position, it is the relative position (i.e., negative to move up) but for fretboard diagrams it is the absolute distance (i.e., positive to move up). I prefer specifying the magnitude as in the fretboard diagram. That is, let the program figure out the most likely direction (in this case "up") and I'll just specify how much. If I want to go against the grain and move it opposite of the logical direction, then it makes sense (from a user perspective) for the number to go negative.

5. the label "Distance staff to fretboard diagram" could use some rewording. Since the section is labeled "Fretboard diagram" this could simply be "default vertical position" as in the chord symbol above. If that label is not desirable, I'd suggest that the same text be used for chord symbols and fretboard diagrams.

6. the label "Fret offset number size" should be "Fret offset font size".

7. maybe the offset number size and position could be reorganized to look like this:

Fret offset       size: _______              position: ( ) L    (*) R

ad 1: I'll try to address this, by having 2 frames on that page, one for Chord Symbols and one for Fret diagrams
ad 2: Capo is part of Chord Symbol, so belongs up there.
ad 3: I'm working on that, but don't have a good solution yet, I'm struggling how to find the height of the fretboard diagram inside the layout of a chord symbol, I have it halfway working with using a fixed value of 5.5sp, but don't like this, so I'll disable this spinbox for the time being
ad 4: this requires a code change too, but I'll look into it.
ad 5: will do, but this needs the above change for consistency
ad 6: I'll change it to "Fret offser number font size:
ad 7: will do

OK, added this to my PR, except for the topics 4 and5, need some advice here:
do we want the position to be negative when we men above staff, or should it be positive?
currently we have it negative for chord symbols, but positive for fretboard diagrams and it really should be consistent, but which way round? I think it is negative in other places too, e.g. voltas and trills.

As far as I know, it is consistent throughout MuseScore: vertical distances are measure downward, so negative numbers are needed to move something higher. Think also text style settings, inspector settings, etc.

Regarding the size of the fretboard diagram:

To actually calculate the height of the fret diagram while in the chord symbol, I *think* it's a question of referencing the fret diagram's bbox. Probably fd->bbox().height() (where fd is pointer the fret diagram).

As I mentioned previously, there might be a layout-order issue: Harmony objects are currently laid out before FretDiagram objects according to element.h & element.cpp. So you might consider reversing those two if it doesn't break something else (which it might - I'll bet this stuff is pretty delicate). But without reversing the order, you may be looking at a stale value of fd->bbox(), so for instance adding a fret diagram after the chord symbol might not affect the chord symbol until the *next* layout() call.

Actually, looking further at harmony.cpp, I see some semi-related code is already there - not sure how I missed it earlier. At the very end of Harmony::layout(), there is a calculation involving bbox().top(). Unfortunately, this code too is looking for a parent of type FRET_DIAGRAM rather than looking for another annotation on the same segment with the same track. So this code isn't being hit.

Hmmm. On further examination, it looks like this code is not moving the chord symbol, but is instead allocating extra space for the staff to accommodate the chord symbol. Thus, increasing the vertical distance between staves / systems. This is done only in the case where a fret diagram also exists, which makes sense, because extra space is allocated for fret diagrams so we might as well do so for the chord symbol too. But since this code is presumably never being hit, no extra space would be allocated here even if you got the chord symbols to display above the fret diagrams. So if you're already testing at the top of the function to find a matching fret diagram, maybe just check the same flag here at the bottom and you'll get extra space allocated for the chord symbol for free.

Again, this extra space is allocated only in the fret diagram case, which I think is good for now. Eventually we might want an option to add extra space for all chord symbols, but that would be too disruptive to do by default at this point.

Genius! This works! Commit on its way...
{syntaxhighlighter brush:cpp}
@@ -848,6 +848,15 @@ void Harmony::layout()
Measure* m = static_cast(parent()->parent());
yy = track() < 0 ? 0.0 : m->system()->staff(staffIdx())->y();
yy += score()->styleP(ST_harmonyY);
+ Segment* s = static_cast(parent());
+ for (Element* e : s->annotations()) {
+ if (e != this && e->type() == FRET_DIAGRAM && e->track() == track()) {
+ yy = score()->styleP(ST_fretY);
+ yy -= score()->styleP(ST_harmonyFretDist);
+ yy -= e->bbox().height();
+ break;
+ }
+ }
else if (parent()->type() == FRET_DIAGRAM)
yy = score()->styleP(ST_harmonyFretDist);

Fantastic! Are you fixing the code at the bottom too so extra space is allocated for the chord? You might as well. Probably save "e" in the code above into another variable "fd" (explicitly initialized to 0) local to the whole function, so you can reference it later as "if (fd)".

I haven't yet touched that part, will have a try tomorrow.

Edit: I just looked at it and don't understand what you mean.

Do you mean something like this?
{syntaxhighlighter brush:cpp}
@@ -844,6 +844,7 @@ void Harmony::layout()

qreal yy = 0.0;
+ Element* fd = NULL;
if (parent()->type() == SEGMENT) {
Measure* m = static_cast(parent()->parent());
yy = track() < 0 ? 0.0 : m->system()->staff(staffIdx())->y();
@@ -854,6 +855,7 @@ void Harmony::layout()
yy = score()->styleP(ST_fretY);
yy -= score()->styleP(ST_harmonyFretDist);
yy -= e->bbox().height();
+ fd = e;
@@ -902,7 +904,7 @@ void Harmony::layout()
setUserOff(readPos() - ipos());
- if (parent()->type() == FRET_DIAGRAM && parent()->parent()->type() == SEGMENT) {
+ if ((parent()->type() == FRET_DIAGRAM && parent()->parent()->type() == SEGMENT) || fd) {
MStaff* mstaff = static_cast(parent()->parent())->measure()->mstaff(staffIdx());
qreal dist = -(bbox().top());
mstaff->distanceUp = qMax(mstaff->distanceUp, dist + spatium());


Probably not, as this crashes ;-)
Guess it's time for bed...

Yes, that's the basic idea. Except that won't quite work, as the code within that block is assuming the chord is a child of the fret diagram, so it is going up two levels of parent() to get to the segment - line 23 above. As far as I know, all that stuff about parent being FRET_DIAGRAM can just be ripped out. If you must leave it in, you've have to initialize mstaff differently for that case versus the fd case. But as I said, as far as I can tell, other places in the code just assume the parent is segment, so I don't think we're gaining anything keeping a test for a condition that will never happen.

So it could go more like this:

    if (fd) {
        MStaff* mstaff = static_cast<Segment*>(parent())->measure->mstaff(staffIdx);
        ... // everything is the same from here on out

As I said, I don't know that this code actually works properly, but it's not even being hit now. So at least give it a shot to see if it works.

yea, I wasn't thinking properly, but this doesn't do anything to the layout:
{syntaxhighlighter brush:cpp}
@@ -844,6 +844,7 @@ void Harmony::layout()

qreal yy = 0.0;
+ Element* fd = NULL;
if (parent()->type() == SEGMENT) {
Measure* m = static_cast(parent()->parent());
yy = track() < 0 ? 0.0 : m->system()->staff(staffIdx())->y();
@@ -854,6 +855,7 @@ void Harmony::layout()
yy = score()->styleP(ST_fretY);
yy -= score()->styleP(ST_harmonyFretDist);
yy -= e->bbox().height();
+ fd = e;
@@ -907,6 +909,11 @@ void Harmony::layout()
qreal dist = -(bbox().top());
mstaff->distanceUp = qMax(mstaff->distanceUp, dist + spatium());
+ else if (fd) {
+ MStaff* mstaff = static_cast(parent())->measure()->mstaff(staffIdx());
+ qreal dist = -(fd->bbox().top());
+ mstaff->distanceUp = qMax(mstaff->distanceUp, dist + spatium());
+ }


Nor does it when dropping the 'fd->'

Shoot, I was going to say drop the "fd->" - assuming you mean on the bbox() call. The point of the original code, as far as I can see, is to allocate more room above the staff to accomodate the chord symbol itself. Space for the fret diagram is allocated in FretDiagram::layout(). Anyhow, since we are trying to allocated room for the chord symbol, we definitely want bbox() (which is to say, this->bbox()), not fd->bbox().

To be clear on what this does:

Have a score with fairly tight system spacing - tight enough that there is little room for fret diagrams. Now add a fret diagram to a note/rest on the second system. You should see the system move down as extra space is allocated for the fret diagram (because of the code in FretDiagram::layout()). Now add a chord a symbol to that same note/rest. If the code you are looking at is doing it's job, more extra space should be allocated for the chord symbol, so the system should move down farther.

I have no trouble believing it doesn't work, though. The code doesn't really look much like the code in FretDiagram::layout(). Could be that's not really supposed to be a negative value in dist, could be simply adding spatium() to it is the wrong thing to do.

I get the sense maybe you aren't actually running under a debugger, so stepping through code line by line isn't feasible? Could be worth figuring out QtCreator - not just for this, but in general.

Meanwhile, I'm looking into this, and will let you know shortly.

I am using QtCreator, but haven't yet got the debugger to run. I did try with and without the "fd->", no difference and the staff doesn't move down further that without any of the 2 changes. I used a qDebug() statement to check it enters that section and it does.

Actually we want to always allocate space for chord symbols (like we do fpr lyrics), and if there is a fretboard, add to its space allocation, so maybe we catch both birds with one stone?

OK, it *does* seem to work, but not well. First, it actually only affects spacing within a system, not space between systems. Not sure why, since with fret diagrams it works both ways. But also, the chord symbol placement is wrong. Although while you're typing it shows close to the staff where it should be, it moves higher - probably to where its original position would have been had the staff not moved down - upon completion of chord symbol entry.

So now we're dealing with deeper intricacies of layout than I am comfortable with. If I were you, I would make the change exactly as you have it but put an "#if 0" - "#endif" around that whole block and add a comment there like "TODO - allocate additional space for chord symbol". That means extra space won't be allocated for chord symbols, but that's OK as far as I am concerned - you can add space for that staff yourself by dragging it down, or increase system distance globally if necessary.

Posts crossed :-)

FWIW, when I did my test, it *was* allocating space for chord symbols always (because I was too lazy to reproduce your code that looks for a fret diagram). I agree that at some point it would be good to provide such an option. But since most existing scores aren't expecting that space, and actually, it isn't common in published scores to alter staff spacing just for chord symbols, it would have to be am option in my opinion. And I have to think, post-2.0.

I'd rather leave it as is in my current PR and submit a new issue for this, with a hint at the code change I tried and couldn't get to work.
I guess there's also quite some dead code to be removed, unless fret frames are supposed to come back one day.

As long as your current PR still has the old check for parent, so the code to add extra space won't get hit. I wouldn't want that code to get hit, since it actually messes up layout.

the current PR messes up the position of the chord symbol when having a fretboard diagram on any non-top staff :-(
Stupidly I only ever tested with the top staff.
Looking into this now.

OK, something very strange is going on, and it is not my PR, as it happens with a nightly build (b453dfe):

adding a fretboad diagram to the top staff allocates extra space above it, added chord symbols appear as per the configured setting above staff
adding a fretboard diagram on the bottom staff of a 2.staff instrument allocates space above it (i.e. between the staves), added chord symbols appear much higher than the configured value (but still between staves), but during entry the curser shows up at the right spot.
adding a fretboad diagram to any other independent staff does not allocate additional space about it and added chord symbols behave as strangle as for the bottom staff of a 2-staff instrument.
My PR's last commit's behavoir seems to be just a poor victim... here it looks like this:
At least all chords in the same hight...

a) I have no idea how to fix that
b) I won't find the time to look into it further for the next couple days...

This is similar to what I observed with the code to allocate more space for chord symbols, so I guess maybe the problem lies elsewhere.

I'll try to look into this. It's possible the our code will cross and be hard to merge, so I may wait until your PR goes through. As far as I can tell, the only only occurs if fret diagram are involved, right? I don't see any such positioning issues while just enter chord symbols. Or maybe I just haven't found the right series of steps?

No, I haven't had time, plus it really doesn't make sense to look at this until the text handling code settles down. The recent changes (over the past month or so) have really shaken things up and much is still broken.