Skip to content

Rasterizing patch in legend changes position - PDF backend #6227

Closed

Description

@claria

Hi,

i plot a rasterized patch and also want the patch in the legend to be rasterized.
It works fine in the agg backend, but fails in the PDF backend:

mpl version: 1.5.1, python 3.5.1, arch linux

Code to reproduce the issue:

import matplotlib
import matplotlib.pyplot as plt

fig = plt.figure()
ax = fig.add_subplot(111)


patch1 = matplotlib.patches.Rectangle((0.5, 0.5), 1., 1., color='red', label='patch1')
patch2 = matplotlib.patches.Rectangle((2.0, 0.5), 1., 1., color='blue', label='patch2')

ax.add_patch(patch1)
ax.add_patch(patch2)

ax.set_xlim(0., 3.5)
ax.set_ylim(0., 3)

legend = ax.legend()
# rasterize first  patch in legend
legend.get_patches()[0].set_rasterized(True)

fig.savefig('asdf.png')
fig.savefig('asdf.pdf')

PNG output:
asdf

PDF output:
asdf pdf

Activity

  1. added this to the milestone on Mar 26, 2016
  2. QuLogic commented on Mar 26, 2016

    @QuLogic
    Member

    Confirmed not working on 1.5.x, 2.x, or master.

  3. claria commented on Mar 27, 2016

    @claria
    Author

    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.

  4. tacaswell commented on Mar 27, 2016

    @tacaswell
    Member

    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.

  5. tacaswell commented on Mar 27, 2016

    @tacaswell
    Member

    And this is not a regression for 1.4.3 or fixed by the recent image overhaul

  6. modified the milestones: , on Mar 28, 2016
  7. added
    Difficulty: Hardhttps://matplotlib.org/devdocs/devel/contribute.html#good-first-issues
    topic: geometry managerLayoutEngine, Constrained layout, Tight layout
    on Mar 28, 2016
  8. tacaswell commented on Mar 28, 2016

    @tacaswell
    Member

    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.

  9. claria commented on Mar 28, 2016

    @claria
    Author

    I tested your suspicion that rasterization the whole legend woud work and indeed it avoids the problem.

  10. stilley2 commented on Aug 6, 2017

    @stilley2
    Contributor

    As another potential workaround, using the pgf backend works

    e.g.:

    from matplotlib.backends.backend_pgf import FigureCanvasPgf
    ...
    canvas = FigureCanvasPgf(fig)
    canvas.print_figure('out.pdf')
  11. modified the milestones: , on Aug 6, 2017
  12. jklymak commented on Sep 21, 2017

    @jklymak
    Member

    Hmmm, see discussion: #9203 where the same rasterization issue in the pdf backend came up.

  13. oscargus commented on Jun 3, 2022

    @oscargus
    Member

    This seems to be fixed in the current master:

    image

  14. removed this from the future releases milestone on Oct 6, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions