gmt
gmt copied to clipboard
GenericMappingTools
WIP Fix incorrect font for colorbar unit
See #6799 for background. The label on the color bar for units was set using annotation font and offset instead of the correct label font and offset. @seisman, please build and run tests and see if you agree with me that the ~35 failing tests are better with the larger font for label and in line with other use of labels. We can then address this after 6.4 as a bug fix.
Have not heard back from anybody about this so pinging @seisman, @maxrjones, @joa-quim and @Esteban82. Perhaps it is worth more discussion. Here is what master currently does, using the FONT_ANNOT_PRIMARY [12p] for the y-axis label:
This PR would declare a bug and state that as for all basemaps the FONT_LABEL [16p] should be used instead, giving
Once could argue that colorbars are very unusual basemaps in that one axis is much longer than the other (factor 20 by default) and that the short axis is never annotated or ticked. Hence, using the label font for a short unit label seems too large. This is of course why I switched to the annotation font decades ago.
However, as it is we are unable to change it independently of the axis annotation, and this WIP solution would affect both axes labels. An alternative would be to declare the bug differently and say it was meant to be the secondary annotation font FONT_ANNOT_SECONDARY [14p] instead of the primary, thus allowing for
- A smaller default font size than label font [14p vs 16p]
- A way to change it without affecting the annotation or main axis label settings
I must say this type of bug-fix offers a better solution for this type of plot. Thoughts?
I must say this type of bug-fix offers a better solution for this type of plot
agreed, for this case it is important for the unit label to be controlled independently from the colorbar label
I don't like the bottom example. Font is way too big. But agree that a different control for the two labels (with a nice default, auto-scaled?) is useful.
Yes true. The whole concept of treating the tiny colormap as a basemap with the same defaults as an actual basemap is wrong. It would seem that the font sizes, ticks etc ought to scale with the color bar length, independent of the auto-scaling for the map it is attached to. Otherwise one has to do a lot of --PAR=value to make it look OK.
Interesting example. I have never seen “inches” used this way. I usually see “Hairlength, inches” or “Hairlength (inches)” on the x label.
On Jul 3, 2022, at 10:57 AM, Paul Wessel @.***> wrote:
Yes true. The whole concept of treating the tiny colormap as a basemap with the same defaults as an actual basemap is wrong. It would seem that the font sizes, ticks etc ought to scale with the color bar length, independent of the auto-scaling for the map it is attached to. Otherwise one has to do a lot of --PAR=value to make it look OK.
— Reply to this email directly, view it on GitHub https://github.com/GenericMappingTools/gmt/pull/6802#issuecomment-1173106406, or unsubscribe https://github.com/notifications/unsubscribe-auth/APUT6GNOBE4EO545GBKVANLVSGS6HANCNFSM5ZDDEBYA. You are receiving this because you are on a team that was mentioned.
Well, it was just a dumb example to show font size. Normally all my research into hair-length uses proper SI units.
I want to wrap this up. Sounds like we are in agreement that this is a good fix and that perhaps further work on default sizes is needed, but that is separate from this fix. Unless I hear fussing I will update those 35 PS files given this fix and complete it.