label font for colorbar is smaller than FONT_LABEL?

[tomeracles]

I am using GMT 6.5.0 so apologies if this is already fixed (or not a bug).

Description of the problem

When setting the font size for my colorbar label with --FONT_LABEL it renders as smaller than if I used the same font with pstext. Is this intended? I can change the size with --FONT_LABEL, it's just that the actual sizes don't seem to match up.

(From testing it seems that setting axis labels on the main plot, e.g. in psbasemap -Bx+l, results in the same size text as pstext gives me, so it is colorbar that is producing a smaller font than specified with FONT_LABEL.)

Full script that generated the error

gmt begin labeltest png
gmt grdimage @earth_relief_01m -R-10/10/48/60 -Coleron -JM10c -BneSW -Bxaf -Byaf
gmt colorbar -Bxa1000+l"Elevation (m)" --FONT_LABEL=20p,Helvetica
echo "Elevation (m)" |  gmt text -F+f20p,Helvetica+cBC -D0/-3c -N
gmt end

Actual outcome

Expected outcome

I would expect the two lines of text saying "Elevation (m)" to be the same size, since they are both set to 20p,Helvetica as far as I can tell.

System information

• Operating system: Debian GNU/Linux 12 (bookworm)
• GMT version (gmt --version): 6.5.0

[yvonnefroehlich]

Hi @tomeracles,

When setting the font size for my colorbar label with --FONT_LABEL it renders as smaller than if I used the same font with pstext. Is this intended? I can change the size with --FONT_LABEL, it's just that the actual sizes don't seem to match up.

Yes, this is actually intended. Up on GMT 6.5 for mode mode, an automatic scaling of the font size of the colorbar labels based on the width of the colorbar was introduced (please see #6802). In the dev docs (please see https://docs.generic-mapping-tools.org/dev/colorbar.html#description) there is a note:

The font used for the annotations along the scale is specified by FONT_ANNOT_PRIMARY while any unit placed at the side of the bar is controlled by FONT_ANNOT_SECONDARY. If a label along the bar is requested, it is plotted with FONT_LABEL. But mind you that the modern mode theme scales down the size of annotations and labels based on the colorbar length for improved legibility. So, in modern mode scripts it might look that these parameter settings are not working correctly. If you may want to increase font sizes to compensate the scaling effect the solution is to use the online --FONT_ANNOT_PRIMARY=... construct.

The actual scaling of the font size is: square_root(colorbar_width / 15).

There are several reports and comments on GitHub and the forum (e. g., GenericMappingTools/pygmt#3041 and https://forum.generic-mapping-tools.org/t/multiple-colorbars-changes-the-annotation-fontsize/4945) indicating that this change leads to some confusions.

[tomeracles]

Oh okay, sorry I should have been able to find those discussions before posting. So however you set FONT_LABEL, the size is multiplied by the scaling factor? And if you wanted to specifically match font sizes between different parts of the figure (if you were very pedantic) would you need to work backwards to calculate the inverse scaling factor to apply to your FONT_LABEL option?

EDIT:

In the dev docs (please see https://docs.generic-mapping-tools.org/dev/colorbar.html#description) there is a note:

The font used for the annotations along the scale is specified by FONT_ANNOT_PRIMARY while any unit placed at the side of the bar is controlled by FONT_ANNOT_SECONDARY. If a label along the bar is requested, it is plotted with FONT_LABEL. But mind you that the modern mode theme scales down the size of annotations and labels based on the colorbar length for improved legibility. So, in modern mode scripts it might look that these parameter settings are not working correctly. If you may want to increase font sizes to compensate the scaling effect the solution is to use the online --FONT_ANNOT_PRIMARY=... construct.

Just thought I'd mention that I read this previously but got the impression that you could still specify exact fonts with, e.g., "the online --FONT_ANNOT_PRIMARY=... construct", not realising that those font sizes would still have the scaling factor applied.

[weiji14]

Just thought I'd mention that I read this previously but got the impression that you could still specify exact fonts with, e.g., "the online --FONT_ANNOT_PRIMARY=... construct", not realising that those font sizes would still have the scaling factor applied.

Yes, even with FONT_ANNOT_PRIMARY set, the scaling would still be applied (e.g. if you set 20p, the actual font size would be smaller). See @yvonnefroehlich's scale_cb_font function in GenericMappingTools/pygmt#3041 (comment) on how to scale to an actual size.

[leouieda]

Hi all, could I make a motion to remove auto-scaling as the default? This is quite confusing and in most cases leads to inconsistent font sizes. I think it's more of a niche application than the general case. Plus, having it on by default breaks backwards compatibility (as evidenced by the load of baselines that had to be updated) and it's not a particularly good reason to do this. It would make much more sense if this were an option that could be turned on when needed (perhaps via a FONT_COLORBAR_AUTOSCALE variable that is false by default).

Pinging @GenericMappingTools/core

[remkos]

I agree that the default autoscaling can certainly lead to confusion, particularly since it is difficult (if not impossible) to overrule.
So I think the suggestion made by @leouieda is a good one.

@tomeracles: please don't drown half of The Netherlands 🙂

[joa-quim]

This situation makes me remember the GMT4 vs GMT5 vectors case. First, former were removed, then users (an me) bugged Paul that they both served their purpose and GMT4 type vectors were brought back to live. Here, reverting to the old case of no auto-scaling would be a breaking change too. Given that auto-scale is the rule in all fonts, frame widths, etc... I definitely prefer one solution where things continue as they are but provide an option to respect the old behavior when needed (the users confusion is not the general rule - meThinks). Don't know the work involved in this though.

[tomeracles]

Given that auto-scale is the rule in all fonts, frame widths, etc... I definitely prefer one solution where things continue as they are but provide an option to respect the old behavior when needed

Forgive me, but is auto-scale the rule in all fonts? I am under the impression that for, e.g., map axis labels and annotations, the default/config font sizes are respected regardless of how big the axes are. Being able to keep consistent font sizes in a figure with multiple panels, boxes etc. (and indeed across multiple figures) is (imo) part of the overall excellent professional look produced by GMT, and making this more difficult seems a shame — albeit it's only a minor inconvenience to someone who understands how the fonts are scaled.

@remkos Thank you 😆 I suppose this is an example of more work needed to create a professional-looking figure 😅 . Promise not to drown the Netherlands.

[joa-quim]

Auto-scale is the default in modern mode but not in classic mode. See https://docs.generic-mapping-tools.org/latest/theme-settings.html
So, in principle, setting GMT_THEME=classic even in modern mode should stop all automatic stuff, including in the case that we are talking about. But this needs confirmation.

[tomeracles]

Sorry, again, for my ignorance, I have learned something new.

I can confirm that setting GMT_THEME to "classic" appears to stop the automatic setting of the FONT parameters according to map size in GMT 6.5.0 modern mode, but does not stop the scaling being applied to the specified font sizes when plotting with colorbar.

[joa-quim]

but does not stop the scaling being applied to the specified font sizes when plotting with colorbar

This does look a bug to me. At least without revisiting with attention this whole subject.

[leouieda]

To me, the scaling of the colorbar font size makes little sense. The use case for this being necessary doesn't seem very common, at least not as common as making multiple panels or wanting consistent font sizes for a paper figure. The fact that multiple bug reports and forum posts show up about this in GMT and PyGMT is an indication of that.

On the backward compatibility thing, I'd argue that introducing this breaking change as the default was a bug and so making it not the default is a bug fix. I don't mind having the option but having this as the default is very confusing for most users. I'm no newbie and it took quite a bit of googling for me to figure out why it happened.