I can confirm this behaviour. Maybe some sort of roundoff issue w/ the PDF backend? But... those figure sizes are pretty pathological.

The issue is with fontsize < 1. which it was in all your examples. In the PDF backend. Hard to get very worked up about cases where people want to plot fonts that are .35 mm high. Intellectually unsatisfying, but the easy solution is to make the figure bigger so the fonts can be larger than 1 pt.

import matplotlib.pyplot as plt
import matplotlib.ticker as ticker
import numpy as np

a = np.random.rand(50,50)

fig, axs = plt.subplots(1,3, figsize=(1.4,0.7))
for nn, i in enumerate([0.5, 0.9, 1.1]):
    ax = axs[nn]
    ax.imshow(a)

    ax.set_yticklabels(["",1,10,100, "ABCDEFGH", "X"])
    ax.set_xticklabels(["",1,10,100, "long long label", "short"])
    ax.xaxis.set_major_locator(ticker.MultipleLocator(10))
    ax.yaxis.set_major_locator(ticker.MultipleLocator(10))

    ax.tick_params(axis='both', which='both', labelsize=i)
    ax.tick_params(axis='x',which='both', rotation=90)

plt.savefig("fig.pdf")
plt.savefig("fig.png")
plt.show()

Here is the PDF... fig.pdf

Is this a problem of the pdf rendering, not interpreting the positions correctly, or a problem of the pdf backend not setting those positions correctly?

I don't think the example is that pathological. You might want to create an image plot which has all points labeled and distribute it via pdf, such that the viewer may zoom into the pdf and see the labels, but that plot still having a defined size in inches (i.e. not to create a poster-size figure).

FWIW mplcairo renders this correctly :-)

If you print, then it’s fine to render as a png. If you are looking at it on a screen then the figure size is arbitrary.

Yes this would be a nice bug to fix. I’m just not sure how high a priority it’ll get.

I have no idea if it’s a basic PDF limitation. It renders incorrectly in both Preview and Acrobat. It would be interesting to see if it happens in EPS and SVG.

I don't think we need to discuss the fact that it is often desired to create a pdf of predefined size. So I guess either it is possible to fix the issue or not, independent on whether everyone understands the use case of it.

It seems SVG is created just fine. So a possible workaround could be to convert svg to pdf outside of matplotlib. However I haven't found a way to do that (Inkscape seems to rasterize the pdf).

@anntzer 's suggestion to use cairo fails for me. The following image is the output from cairo matplotlib.use("Cairo") with cairocffi-0.8 installed.

https://github.com/anntzer/mplcairo

I tracked this all the way down into ft2font.cpp where it wasn't clear to me what happens. But what is happening here is that the width reported by font.get_width_height() of the text snippet stops decreasing when fontsize is less than 1. So the label gets put at the size=1.0 font x position:

Fontsize: 0.2
string: ABCDEFGH
fontprop :family=sans-serif:style=normal:variant=normal:weight=normal:stretch=normal:size=0.2
width 358

Fontsize: 1.0
string: ABCDEFGH
fontprop :family=sans-serif:style=normal:variant=normal:weight=normal:stretch=normal:size=1.0
width 358

Fontsize: 2.0
string: ABCDEFGH
fontprop :family=sans-serif:style=normal:variant=normal:weight=normal:stretch=normal:size=2.0
width 714

@anntzer Does mplcairo output in PDF? I thought it was just an Agg replacement, but if it also puts all the vector outputs under one umbrella that seems very useful.

Edit: should have read the README. Answer = Yes.... Is there a roadmap to put this into the main repo at some point?

See these notes from FreeType's FT_Set_Char_Size which is used in set_size:

• While this function allows fractional points as input values, the resulting ppem value for the given resolution is always rounded to the nearest integer.
• If either the character width or height is zero, it is set equal to the other value.
• If either the horizontal or vertical resolution is zero, it is set equal to the other value.
• A character width or height smaller than 1pt is set to 1pt; if both resolution values are zero, they are set to 72dpi.

cairo natively outputs to raster/pdf/ps/svg so mplcairo is actually a replacement for all these backends (modulo a few features, I believe the only missing things are: URLs in svg (may possibly happen in the next cairo release, apparently), and use of the core 14 fonts just from the metrics and without embedding in pdf).

The plan to put this in the main repo is

• merge Cairo rendering for Qt5 #8771 and cairo rendering for wx #9202 which cleanly separate the rendering and the windowing parts of qtagg and wxagg (I have a similar PR ready for tkagg but I'll wait until these are merged first, plus there are already enough open tk PRs lying around)
• fix setupext (setupext should not explicitly add /usr/{,local/}include to the include path #9737) to allow nonsystem compilers
• wait until mpl drops Py2 support (I have zero interest in making this work for Py2), which tacaswell said should happen after mpl2.2 is released
• wait until MSVC gets full C++17 support (see HACKING.rst in the mplcairo repo for details), should hopefully happen in not too long?

@QuLogic So font size < 1pt is not possible? Hmmmm. We end up rendering it less than 1 pt, so I’m a little flummoxed that we can’t tell how big a string is going to be.

@anntzer Sounds great!

TBH, I don't yet know how this affects things, especially if other file formats work (I didn't check too carefully)? Or how it's possible we render at <1pt either.

yeah, it’s a bit mysterious. Particularly as Agg works just fine. Thanks for the pointer, I’m sure this is the problem, somehow...

Err wait, if you increase DPI on the PNG so that you can see the text, it turns out that it never changes size below 1pt. It does change size in PDF because we embed the fonts themselves and let the viewer render it, but the size we get to allocate space is always for 1pt.

Oh, great, well at least the world is consistent. So do we try and work around this, or tell people who want to use unreadable fonts to readjust their expectations?

Well, I guess the question is how correct is mplcairo and how difficult it is to do whatever it is that it does to get it to work.

OK, I can't reproduce the error in PNG:

EDIT: Oh, duh. I see. In PNG the font sizes never drop below 1 pt...

a = np.random.rand(50,50)

fig, axs = plt.subplots(1,3, figsize=(1.4,0.7), dpi=5000)
for nn, i in enumerate([0.5, 0.9, 1.1]):
    ax = axs[nn]
    ax.imshow(a)

    ax.set_yticklabels(["",1,10,100, "ABCDEFGH", "X"])
    ax.set_xticklabels(["",1,10,100, "long long label", "short"])
    ax.xaxis.set_major_locator(ticker.MultipleLocator(10))
    ax.yaxis.set_major_locator(ticker.MultipleLocator(10))

    ax.tick_params(axis='both', which='both', labelsize=i)
    ax.tick_params(axis='x',which='both', rotation=90)

plt.savefig("fig.pdf")
plt.savefig("fig.png", dpi=5000)
plt.show()

resulting png:

Actually for mplcairo+pdf too the size plateaus at 1pt, not going lower. As noted by @QuLogic it's likely running into the same FreeType limitation.

I'm just calling cairo_scaled_font_text_to_glyphs, which does all the layouting: https://www.cairographics.org/manual/cairo-cairo-scaled-font-t.html#cairo-scaled-font-text-to-glyphs / https://github.com/anntzer/mplcairo/blob/master/src/_util.cpp#L537

Interestingly the path (compile-time option) using libraqm (that handles right-to-left / complex layout languages) also has an issue with tiny fonts, but a different ones: the spaces between the glyphs are too big, although the texts are right-aligned correctly.

So is there a path to fix here? Throw a _log.info if the user tries to call font size <1 and maybe clip the PDF fontsize at 1 so at least it is rendered in the right spot, if at too large a size? If FreeType won't let us have fontsizes less than 1 pt, I don't see why we should jump through hoops to accommodate.

But why? At the moment you can use smaller font sizes. (As seen from this comment above)
Why would you break that?

You can't use smaller fontsizes in the Agg or Cairo backends, and you can't position them properly in the PDF backend.

I guess I have to rethink what people mean by "scalable" when it comes to vectorgraphics.

@ImportanceOfBeingErnest Any other options you had would be welcome.

You could go the other route of trying to scale all the reported font dimensions by the <1 fontsize, but then you'd break the rendering for all the Agg/Cairo backends. That seems worse to me than restricting the scalability of the fontsize.

The "proper" solution is to get FreeType to change their routine. I am not sure why they don't allow small fontsizes.

Probably because font scaling is more complicated that just dilating or shrinking the whole thing (even for "scalable" fonts). See e.g. https://docs.google.com/document/d/1wpzgGMqXgit6FBVaO76epnnFC_rQPdVKswrDQWyqO1M/edit for a pretty good read (IMO).

This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!

I think this is essentially a limitation of freetype we're unlikely to work around.