Open pnkraemer opened 7 months ago
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?
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 https://github.com/matplotlib/matplotlib/issues/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')
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!
Then we get images with different size in pixels while DPI is the same and equals to 100.
Bounding boxes of generated PDFs differs too.
From my perspective
matplotlib
documentation is a little bit vague and unclear at this point but it seems thatsavefig.bbox
/bbox_inches
tweak somehow shape of bounding box ofArtist
's onFigure
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.
Originally posted by @daskol in https://github.com/pnkraemer/tueplots/issues/101#issuecomment-1877748764