Resulting media size differs from declared one about tueplots HOT 3 OPEN

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?

from tueplots.

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')

from tueplots.

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!

from tueplots.