You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Rasterizing patch in legend changes position - PDF backend #6227
There must be some hardcoded dependency on the dpi=72 in the raster backend. If i set matplotlib.rcParams['savefig.dpi'] = 72
before plotting (it was 150 before), the legend patch is placed in the correct position.
I spent a while chasing down this rabbit hole, and the problem here is that the pdf backend uses a mixed renderer (vector and raster) and they have different DPI. The legend is implemented as a (deeply) nested OffsetBox which provides a 'local' rendering area via many stacked translations in screen space. If some of the artists in the nested offset boxes are rasterized the offsets get crossed. I think what is happening is that the artists have (eventually) an offset specified in screen space so the rasterizer draws in in the wrong place on the temporary raster buffer and then that wrongly drawn image is correctly transferred to the pdf.
One possible work around is to rasterize the whole legend which will draw it in the correct place (but now your text is no longer a vector) or to, as you discovered, use a dpi of 72 for your rasterization (which means your rasterized images are super low DPI).
Re-tagged this as 2.1 because the fix for this is probably in refactoring the code in offsetbox.py which has not been meaningfully touched sense 2008-2010 and would probably be coupled with adding a proper layout manager to the code and ensuring that the transforms that rely on dpi are re-computed when ever the mixed-mode renderer changes renders.
Activity
QuLogic commentedon Mar 26, 2016
Confirmed not working on 1.5.x, 2.x, or master.
claria commentedon Mar 27, 2016
There must be some hardcoded dependency on the dpi=72 in the raster backend. If i set
matplotlib.rcParams['savefig.dpi'] = 72before plotting (it was 150 before), the legend patch is placed in the correct position.
tacaswell commentedon Mar 27, 2016
I think it is more that the pdf backend has a fixed dpi of 72 and the image dpi is getting used for the transform instead of 72.
tacaswell commentedon Mar 27, 2016
And this is not a regression for 1.4.3 or fixed by the recent image overhaul
tacaswell commentedon Mar 28, 2016
I spent a while chasing down this rabbit hole, and the problem here is that the pdf backend uses a mixed renderer (vector and raster) and they have different DPI. The legend is implemented as a (deeply) nested
OffsetBoxwhich provides a 'local' rendering area via many stacked translations in screen space. If some of the artists in the nested offset boxes are rasterized the offsets get crossed. I think what is happening is that the artists have (eventually) an offset specified in screen space so the rasterizer draws in in the wrong place on the temporary raster buffer and then that wrongly drawn image is correctly transferred to the pdf.One possible work around is to rasterize the whole legend which will draw it in the correct place (but now your text is no longer a vector) or to, as you discovered, use a dpi of 72 for your rasterization (which means your rasterized images are super low DPI).
Re-tagged this as 2.1 because the fix for this is probably in refactoring the code in
offsetbox.pywhich has not been meaningfully touched sense 2008-2010 and would probably be coupled with adding a proper layout manager to the code and ensuring that the transforms that rely on dpi are re-computed when ever the mixed-mode renderer changes renders.claria commentedon Mar 28, 2016
I tested your suspicion that rasterization the whole legend woud work and indeed it avoids the problem.
stilley2 commentedon Aug 6, 2017
As another potential workaround, using the pgf backend works
e.g.:
jklymak commentedon Sep 21, 2017
Hmmm, see discussion: #9203 where the same rasterization issue in the pdf backend came up.
oscargus commentedon Jun 3, 2022
This seems to be fixed in the current master: