Ideally we'd have a mode where the character bounds are calculated, and then the center of these used as the "origin" for the symbol...

I think this would need to be an option though, or we'd break a lot of existing symbology

@nyalldawson , was discussing this with @m-kuhn not too long ago and we both reached the same conclusion.

Ideally we'd have a mode where the character bounds are calculated, and then the center of these used as the "origin" for the symbol...

This is yet another option for placement (which happens to work equally in this specific scenario on the image), no?

I think this would need to be an option though, or we'd break a lot of existing symbology

Agreed, the question is if we can extend the combobox for vertical placement or if we need a new checkbox or similar

@signedav I think you already had some thoughts on this?

Yes. Since I'm not working today I'll share em tomorrow and will much appreciate your feedback then.

Summarizing my notes (you might know all this already)...

Currently we do have three modes as vertical anchor point:

The middlepoint is everywhere the source of truth: it's calculated in the font marker layer as the middle of the baseline and QFontMetrics::ascent() , what is basically the highest possible point of a font (like the top of the 'aigu' of the È).

Still when a letter is vertically centered with VCenter it looks mostly like this (example with Deja Vu):

Because it's the middle of the ascent-baseline and not the middle of the characterize, it's not really centered on some letters:

(while the À is correct, the A is not)

This would require the character bounds to fix, but that's not the main topic here anyway.

Concerning this cadastre-font to have all symbols centered according to the sign, it would not solve the issue. We just want to have them right on the baseline.

We might assume, it should set the symbols on the right place with the setting "Bottom":

But it doesn't do it.

Because we make the following calculation:

• Calculate the middlepoint like above: (ascent-baseline-difference) / 2
• Then we get the symbol size (the one from the settings, scaled depending on the unit and are dividing with 2 -> having an offset
• And we set this offset to the middlepoint.

This would work, when the size would fit the ascent-baseline, but it does not. The ascent-baseline is smaller, what means the letter is slightly above:

Instead of expected this:

And on the cadastre-font it looks like this:

Instead of expected this:

To fix this we should calculate the middlepoint according to the scaled fontsize or calculate the offset according to the ascent-baseline.

And yes, I guess it needs a setting because otherwise it breaks existing projects.

Pro for another anchorpoint option in the combobox would be that it's more elegant (having e.g. "Baseline" there). Con is, that we kind of loose the setting when switching between the markers. This would be solved by a new checkbox "Consider Baseline as Bottomline".

Not sure how much "VCenter" or "Top" could be improved here, but I think on "Top" we could make an improvement as well that it does set the offsets in the same way like on "Bottom". If so, I would prefer a checkbox "Consider Baseline" over two new anchor point types. But concerning GUI I have no strong opinion.

Thanks for the explanation.
For my understanding: if we go for a new checkbox "Use baseline as bottom line", activating it will change the calculated position for "Bottom" and "Top" (but VCenter will be unchanged)?

Yes. With VCenter this issue does not make a difference, since when the size calculated with the baseline and the font-metric is e.g. 10 and the size of the symbol is e.g. 12, the position is still correct because it's in the middle (besides that it could be optimized by calculating the size of the symbol by getting the bounds of the current char like mentioned above, but this is another topic).

Maybe some ideas for the VCenter topic, even though it does not concern this specific issue with the cadastre symbols.

Currently it's centered according the size of the biggest character with accent (here the Á):

When it would center it according to the bounds of the current symbol it would look like this:

And something completely different would be that it's centered according to a accent-less capitol letter (here the A) like this:

Backing up a step, from @m-kuhn:

This is yet another option for placement (which happens to work equally in this specific scenario on the image), no?

I'd say this particular font is an unusual situation (centering characters over the baseline). But there's MANY MANY symbol fonts which don't do this which would benefit from a proper "center over the actual character bounds" placement mode. (Eg, all the ESRI symbol fonts, which have characters like this:

)

Couldn't BOTH situations be fixed with a "center marker over character bounds" mode?

My preference would be for the existing modes in the Anchor Point combo (for font markers only!) to be renamed to "Top (Legacy)", "Bottom (Legacy)" "VCenter (legacy)" and then new modes added for "Top", "Middle", "Bottom" which are calculated based on the actual character bounds. If there's still a specific requirement for a "baseline" mode then that could also be added to this same combo box.

All NEW font marker symbol layers would default to "Middle", so only existing ones would use the "VCenter (legacy)" mode...

Thanks for your reply.

I'd say this particular font is an unusual situation

Yes. But I guess the reason is that the point where the symbol should be centered to is not the center of the symbol bound.

... and thats - as far as I understand the bound-approach - why it wont solve it for this.

Wouldn't the baseline approach make sense for other normal fonts as well? Like here:

@signedav

Wouldn't the baseline approach make sense for other normal fonts as well? Like here:

Yes, you're correct. I'd still argue that we also need methods which consider the bounds to be useful for the majority of symbol fonts though 👍

Alright, I do agree that the reference to the individual bounds would make sense. Not only for the symbol fonts.

So best would be to have an option to have the symbol bounds as reference and to have the font baseline as reference. And of course the third option of the inconsistent current way to do it.

The symbol bounds would lead to (vertical) placement like this:

And the baseline would lead to (vertical) placement like that:

And the None (legacy) would lead to what it does currently: Place above (top) the position of the highest bound in the font plus (difference between highest point and baseline and the size of the font divided with two*) and below (bottom) of the baseline minus (difference between highest point and baseline and the size of the font divided with two*) and the center is like with the baseline.

* what is the current "bug". See #59732 (comment)

Means both (baseline and bounds) would make sense to implement, still if only one of them will be implemented, it might make sense to have the setting prepared as a combobox (enum) instead of a checkbox (bool).

Does this make sense for you @nyalldawson @nirvn @m-kuhn ?

P.S. having a meeting with the potential sponsor next week - will keep you up to date.

@signedav

Why not just go with my proposal of adding new options to the existing vertical align combo box? It avoids the need for another new widget, and avoids the (meaningless?) top/middle with baseline reference modes

No strong opinion.

Your suggestion means:

• top legacy
• top bounds
• center legacy
• center bounds
• bottom legacy
• bottom bounds
• bottom baseline

Or wont you make top and bottom bounds?

@signedav

Your suggestion means:

top legacy
top bounds
center legacy
center bounds
bottom legacy
bottom bounds
bottom baseline

Exactly! (And "center bounds" would become the new default)