Alternate implementation of tight_bbox. #20250
Conversation
Instead of trying to fix the position of all artists during the tight_bbox save (which causes all kinds of grief), instead intercept all calls to renderer drawing methods and perform the shifting there. This is mostly at the proof of concept stage. The advantage is that this could perhaps ultimately without having to implement anything on the renderer side (a single implemenation of patched drawing methods suffices); the problem is that the patching may be rather tricky to get exact. For example, patching draw_text seems tricky, because some backends do not actually use the `x` and `y` parameters of `draw_text`, but rather directly fiddle with the Text object. Some other issues with dpi changes (for fixed-dpi vector formats) are also present.
|
The other approach made sense to me - not sure I'm following this one, which seems to be just doing what we do now but at a lower level? Was the other approach fatally flawed in some way? |
|
I'm fine with the other approach too if it can be made complete, but it basically requires figuring out for each and every output format we support how to clip an already generated file (or stream). Currently, only postscript, pdfpages, pgf, pgf-generated-pdf, and pgf-generated-pdfpages are missing; they should all be fixable but will likely require wrangling with the pdf spec (for example). If (somewhat theoretically) someone wants to support yet another output format, they'll need to write a new clipper for it too. With the approach here, all output formats are supported at once (even for third-party backends or not-yet-existent output formats), which is also one very positive point of the preexisting tight_layout implementation. In all cases, we of course do a first draw to position everyone and compute the bbox, but then the approaches between the preexisting implementation (a) and this PR (b) differ: in (a) we try to move all artists to their new positions (in the clipped coordinates) and prevent them from moving further during the draw-tree walking (by patching out apply_aspect), but that can break other processings that are needed (e.g. the floating_axes issue); in (b) we simply record an offset, and then walk the draw tree again, but when the artist calls out to the renderer, we intercept these calls and shift all coordinates as required. So in particular we don't need to patch out apply_aspect. OTOH, it turns out that for some artists (i.e., texts), even intercepting the coordinates passed to the renderer is quite tricky (even though we call |
Instead of trying to fix the position of all artists during the
tight_bbox save (which causes all kinds of grief), instead intercept all
calls to renderer drawing methods and perform the shifting there.
This is mostly at the proof of concept stage. The advantage is that
this could perhaps ultimately without having to implement anything on
the renderer side (a single implemenation of patched drawing methods
suffices) (compare with #19923); the problem is that the patching may be
rather tricky to get exact. For example, patching draw_text seems tricky,
because some backends do not actually use the
xandyparameters ofdraw_text, but rather directly fiddle with the Text object. Some otherissues with dpi changes (for fixed-dpi vector formats) are also present.
xref #19923 which tries to do the same thing but with per-format post-processors.
PR Summary
PR Checklist
pytestpasses).flake8on changed files to check).flake8-docstringsand runflake8 --docstring-convention=all).doc/users/next_whats_new/(follow instructions in README.rst there).doc/api/next_api_changes/(follow instructions in README.rst there).