Skip to content

Intermittent SVG error in the notebook #8133

New issue
New issue
Closed
Closed
Intermittent SVG error in the notebook#8133
Milestone
no action

Description

@moble
moble
opened on Mar 24, 2015

I have long had a problem with SVG matplotlib output in the notebook. Intermittently, the plot will extend outside of the axes, as exemplified in this screenshot:

matplotlibsvgnotebookbug

Basically, everything below the horizontal axis should be hidden. Most of the time, it is properly hidden -- e.g., when the plot is first made, or when I collapse and expand the output area. But then sometimes, it'll go buggy like this. I can't reproduce this consistently, but it seems to happen most often when I make a plot in another cell.

That stuff that's usually hidden evidently does correspond to actual data; when I plot again with xlim(xmin=1e-18), the data does show up just like that, except that it is correctly based at 1e-18. So it's evidently really in the SVG.

I'm wondering if this is related to #1881 and #2647, but none of the descriptions of problems there were specific enough. Is this expected badness in the matplotlib output?

I've had this problem for a long time (years?), but I can verify that it exists currently in IPython 3.0.0. I'm seeing it in up-to-date Chrome and Safari on up-to-date OS X, using an up-to-date anaconda installation (python 2.7). Here are the IPython details:

{'commit_hash': u'f75fda4',
'commit_source': 'installation',
'default_encoding': 'UTF-8',
'ipython_path': ..../anaconda/lib/python2.7/site-packages/IPython',
'ipython_version': '3.0.0',
'os_name': 'posix',
'platform': 'Darwin-14.1.0-x86_64-i386-64bit',
'sys_executable': '/Users/boyle/.continuum/anaconda/bin/python',
'sys_platform': 'darwin',
'sys_version': '2.7.9 |Continuum Analytics, Inc.| (default, Dec 15 2014, 10:37:34) \n[GCC 4.2.1 (Apple Inc. build 5577)]'}

Activity

  2. moble commented on Mar 24, 2015

    @moble
    moble
    on Mar 24, 2015
    Author

    Ah, yes I can! And it's even reproducible! I've never been able to make this reproducible before.

    Open this notebook. You might have to evaluate the cells to make sure the output is actually SVG; if so I don't know of any way to do this without the following line in ipython_config.py:

    c.InlineBackend.figure_format = 'svg'

    Anyway, once you've got all three figures as SVG, delete the middle one. This does it every time for me. The badness also happens for me in existing figures when I'm evaluating a new one.

  4. moble commented on Mar 25, 2015

    @moble
    moble
    on Mar 25, 2015
    Author

    After diffing the whole HTML of the notebook before and after deleting the first plot, I wasn't able to find a significant difference.

    Yeah, I'd doubt that it'd be HTML; it comes and goes (and comes and goes again) depending on various actions in the notebook.

    I think it's really just that the data points are failing to be clipped by the axes rectangle. But why this should fail intermittently is the question.

    Another data point: I can use just plain plots, with no log scaling, and get extra data to appear on all four sides of the axes:

    matplotlibsvgnotebookbug2

    So I guess it's just a generic feature of the SVG, whenever the range of the data being plotted is larger than the range of the xlim and ylim values.

  5. moble commented on Mar 25, 2015

    @moble
    moble
    on Mar 25, 2015
    Author

    I should also point out that I used a completely new profile to do this, with absolutely no changes to ipython_config.py, custom.js, etc.

  7. takluyver commented on Mar 25, 2015

    @takluyver
    takluyver
    on Mar 25, 2015 via email
    Member

  9. moble commented on Mar 25, 2015

    @moble
    moble
    on Mar 25, 2015
    Author

    Safari has the same problem as Chrome, so I'd be a little surprised if it's a rendering bug -- though not hugely surprised.

    BTW I've boiled it down to a particularly simple test case:

    plt.plot([0, 1], [0, 1])
plt.xlim(0.1, 0.9)
plt.ylim(0.1, 0.9);

  10. takluyver commented on Mar 25, 2015

    @takluyver
    takluyver
    on Mar 25, 2015
    Member

    Safari and Chrome both use the Webkit rendering engine (technically, Chrome uses Blink, which is a fork of Webkit), so it's possible that they are inheriting the same underlyign bug.

  12. moble commented on Mar 25, 2015

    @moble
    moble
    on Mar 25, 2015
    Author

    It is also interesting that the example using plot can reproduce this issue but removing log=True in the other examples avoids the problem.

    I think that's just a coincidence of the limits. With log=False, the bars of the histogram range between y=0 and y=1 (or higher), but the limits also go from y=0 to y=1 (or higher), so all of the plotted stuff is within the limits, and there's nothing to be displayed incorrectly. With log=True, the bars extend infinitely(ish) far down, but the ylimit has some finite minimum, so the bars can be accidentally displayed.

    That's why I think plot is the more useful case; as long as there's data outside the limits, it looks like there's potential for that data to be accidentally displayed.

  15. moble commented on Apr 4, 2015

    @moble
    moble
    on Apr 4, 2015
    Author

    No, it doesn't work for me -- unless I'm misunderstanding you. I tried your experiment of copying the SVG twice into an HTML file, then delete one using developer tools. I got the out-of-bounds lines. Then I went into the HTML file and deleted the <defs> sections from both SVGs, full refreshed the page, deleted one, and zoomed, and I saw the problem again. You can see in my screenshot that the defs section isn't there:

    screenshot

  18. moble commented on Apr 4, 2015

    @moble
    moble
    on Apr 4, 2015
    Author

    That certainly explains that. And for the naive MWE above, I can verify that the clipPath id is the same in each case. But then, I can also change the parameters of the graph and get the same clipPath. So apparently, either whatever is being hashed to produce the id either isn't complete enough, or the hash isn't updated for changes in the plot. Any idea where that id comes from?

  20. abreslow commented on Apr 14, 2015

    @abreslow
    abreslow
    on Apr 14, 2015

    Can you provide a pointer to that issue? I posted this on StackOverflow: http://stackoverflow.com/questions/29616764/matplotlib-savefig-produces-incorrect-svg-image-for-bar-chart-with-log-scaled-y

  22. abreslow commented on Apr 15, 2015

    @abreslow
    abreslow
    on Apr 15, 2015

    Thanks @rsmith31415.

    On Tue, Apr 14, 2015 at 1:34 PM, rsmith31415 [email protected]
    wrote:

    @abreslow https://github.com/abreslow Well, I think your problem is not
    really related with this particular issue and your code works okay in the
    IPython Notebook. However, this is the problem:

    Your SVG is defining a clipping mask at the end of the file:

    The browser seems to be flexible about this, but you usually want to
    create your definitions at the top of the SVG code. Unfortunately,
    matplotlib is placing clipping masks at the bottom and this is causing your
    problem. For example, if you move your clipping mask as follows:

    <style type="text/css"> *{stroke-linecap:butt;stroke-linejoin:round;} </style>

    you will see the correct plot:

    [image: screenshot from 2015-04-14 15 29 30]
    https://cloud.githubusercontent.com/assets/599274/7146695/11f715a8-e2bb-11e4-9dd6-5deba796039e.png

    Even trivial examples such as this:

    <defs>
    <clipPath id="myClip">
        <circle cx="30" cy="30" r="20"/>
        <circle cx="70" cy="70" r="20"/>
    </clipPath>
</defs>

<rect x="10" y="10" width="100" height="100"
      clip-path="url(#myClip)"/>

    will fail if you put your clipping mask at the bottom.

    —
    Reply to this email directly or view it on GitHub
    #8133 (comment).

    Alex Breslow
    PhD student in computer science at UC San Diego
    Email: [email protected]
    Website: cseweb.ucsd.edu/~abreslow

  24. minrk
    closed this as completedon Apr 15, 2015

  25. minrk commented on Apr 15, 2015

    @minrk
    minrk
    on Apr 15, 2015
    Member

    Thanks, folks.

  26. minrk
    added this to the no action milestone on Apr 15, 2015

  27. tacaswell commented on Apr 28, 2015

    @tacaswell
    tacaswell
    on Apr 28, 2015
    Contributor

    @abreslow The issue you are seeing with clipping is a bug is librsvg rendering incorrectly, not in mpl emitting buggy svg. There is no constraint that clip paths must appear in the document before they are used. See much longer response at matplotlib/matplotlib#4341

  28. tacaswell
    added a commit that references this issue on Apr 28, 2015

    BUG : fix svg corner case

    66e9fa2

  29. tacaswell commented on Apr 28, 2015

    @tacaswell
    tacaswell
    on Apr 28, 2015
    Contributor

    @abreslow Please see matplotlib/matplotlib#4388 and see if that fixes your problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions