Resulting media size differs from declared one

[pnkraemer]

          I'm afraid that this issue introduced a regression: resulting media size differs from declared one.

import matplotlib as mpl
import matplotlib.pyplot as plt

def save_fig(what: str, rc: dict):
    with mpl.rc_context(rc):
        fig, ax = plt.subplots(figsize=(3.25, 2.01), layout='constrained')
        ax.plot([i ** 2 for i in range(10)], '-..', label=r'$x^2$')
        ax.legend()
        ax.set_xlabel(r'$x$')
        ax.set_ylabel(r'$f(x)$')
        fig.savefig(f'{what}.pdf')
        fig.savefig(f'{what}.png')
        fig.savefig(f'{what}.svg')

save_fig('standard', {'savefig.bbox': 'standard', 'savefig.pad_inches': 0.015})
save_fig('tight', {'savefig.bbox': 'tight', 'savefig.pad_inches': 0.015})

Then we get images with different size in pixels while DPI is the same and equals to 100.

$ file *.png
standard.png: PNG image data, 325 x 200, 8-bit/color RGBA, non-interlaced
tight.png:    PNG image data, 319 x 195, 8-bit/color RGBA, non-interlaced

Bounding boxes of generated PDFs differs too.

$ echo {standard,tight}.pdf | xargs -n1 pdfinfo | grep -i 'page size'       
Page size:       234 x 144.72 pts
Page size:       230.16 x 140.88 pts

From my perspective matplotlib documentation is a little bit vague and unclear at this point but it seems that savefig.bbox/bbox_inches tweak somehow shape of bounding box of Artist's on Figure and use it instead of bounding box of original canvas.

UPD I don't know what figsize and dpi was in your sample abut sizes of generated PDFs follow.

$ echo {before,after}.pdf | xargs -n1 pdfinfo | grep -i 'page size'
Page size:       494.4 x 158.582 pts
Page size:       482.16 x 146.342 pts

Originally posted by @daskol in #101 (comment)

[pnkraemer]

Thank you for the notification and for giving clear examples. I took the liberty to create an issue from your comment, so we can discuss a solution.

I agree with you @daskol that setting a figure size to a value and having the saved figure be differently sized is unexpected. However, the discrepancy between what we pass to "figsize" and the size of the saved image seems to be a decision made in matplotlib, not Tueplots. Since the exact size of the saved figure is also affected by other variables, e.g., constrained/tight layouts (see here), I am not sure whether we can expect an exact match in either case.

But I think the reduced figure size should at least be documented. A natural place would be the FAQ part of Tueplots' documentation. We can also think about exposing the savefig.bbox variable as a function argument (just like savefig.pad_inches) to have more control over this behaviour.

What do you think @daskol? Would this work for you?

[daskol]

Thank you for replying to my comment and creating the issue.

In my opinion, the best solution we can do is not to set bbox by default and leave the decision to tighten bbox or not to user. There are multiple reasons for that. First of all, the principle of the least surprise is fulfilled: size of media will be what user expects. Another reason is related to how layout engine in Matplotlib works.

As far as I understand, bbox_inches and pad_inches kwargs are not used by layout engine. Indeed, layout engine is used by renderer before these kwargs go on stage. Options bbox_inches and pad_inches may be needed when layout engine fails to place all elements (or Artists in Matplotlib terminology) in a way to fit figsize. When layout engine fails and bbox_inches and pad_inches are not used, then some elements go beyond bbox defined by figsize and are consequently cropped out in a rendering backend (see matplotlib/matplotlib#11681 and particulary this comment and also this one). So my point here is that a user should always check the resulting media and if a layout engine failed and the media content was cropped, then a user should adjust the figure manually iteratively until he or she is satisfied.

Concerning the overfull hbox issue, I'd prefer to let a user know about the difficulties in layouting of a figure. In my experience, it is quite often the situation that hbox is overfilled because of Axis patch/path. Matplotlib renders background (Axis) as colored or transparent closed path (see edgecolor and facecolor options). Sometimes this border path goes beyond figsize (e.g., due to rounding errors in division by dpi=150 or ignored line width) and causes LaTeX warnings. Perhaps, FAQ should be updated accordingly.

Personally, I just override these options for saving as follows.

with mpl.rc_context({'savefig.bbox': 'standard'}):
    fig.savefig('raster.png')
    fig.savefig('vector.svg')

[pnkraemer]

Thanks for clarifying! So you suggest removing the savefig.* arguments from the figure-size-configuration altogether. Is that correct?

I think this makes sense. Adding to your reasons, I (now) think that changing the savefig.* arguments is a bit of an opinionated configuration, which we try to avoid here wherever possible. (Except for in the axis.py module, perhaps). I agree it is a good idea to remove it.

Would you be willing to send a PR that deletes those few lines from figsizes.py?

Concerning the overfull hbox issue, I'd prefer to let a user know about the difficulties in layouting of a figure. In my experience, it is quite often the situation that hbox is overfilled because of Axis patch/path. Matplotlib renders background (Axis) as colored or transparent closed path (see edgecolor and facecolor options). Sometimes this border path goes beyond figsize (e.g., due to rounding errors in division by dpi=150 or ignored line width) and causes LaTeX warnings. Perhaps, FAQ should be updated accordingly.

I do not quite understand what you explain here. Do you refer to the overfull hbox part of the FAQ? Is this an explanation of what exactly goes wrong? If you have a suggestion on how to update the FAQ, I'd be happy to incorporate it!