-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
DOC: add warnings about get_window_extent and BboxImage #29910
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DOC: add warnings about get_window_extent and BboxImage #29910
Conversation
To get accurate results you may need to manually call | ||
`matplotlib.figure.Figure.savefig` or | ||
`matplotlib.figure.Figure.draw_without_rendering` to have Matplotlib | ||
compute the rendered size. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is unclear to me. I feel, we are mixing two things here an it's too short to understand:
draw_without_rendering
ensures the window_extent is up-to-date for the current transform stack. This resolves incorrect intermediate state due to lazy evalutation, e.g. of the layout.- How does
savefig
help here? Is this this the double save idea of Bug when saving to vector format (pdf, svg, eps) #2831 (comment). If so, that needs more explanation. Also I'm not sure on the generality of the solution Bug when saving to vector format (pdf, svg, eps) #2831 (comment).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I left a comment over on #2831 for why in the case of vector backends we may need savefig (tl;dr: print_pdf
changes the DPI).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I still think this is too terse to be helpful and actionable for users. However, I won't block over this.
Decide yourself whether it's good enough for now or how much additional effort you want to put into this.
Co-authored-by: Tim Hoffmann <[email protected]>
Co-authored-by: Tim Hoffmann <[email protected]>
I'm going to merge on @timhoffm 's approval. I do not disagree this is terse and vague, but I'm not sure how to make it less vague without making it way less terse. |
Closes #2831
Went with a purely documentation fix (and fleshed out the
BBoxImage
docs while I was at it).PR checklist