Skip to content

Image overflow in IPython Notebook 3 (beta) #7701

Closed

Description

@JeremyMMulcahey

When my notebook converted from v3 to v4, running the code below, yielded the image below:

code
overflow

Additionally, the plot below, with dimensions (18,6) did not overflow in the previous version of the IPython Notebook:

plot

Activity

  1. takluyver commented on Feb 6, 2015

    @takluyver
    Member

    The behaviour hasn't actually changed, but we made the background around the notebook 'page' grey, so it's much more obvious now when things extend beyond the page.

    We're not sure what to do about this, because we do think the grey surround looks much nicer when things aren't extending outside the page.

  2. JeremyMMulcahey commented on Feb 6, 2015

    @JeremyMMulcahey
    Author

    The original issue came up in ellisonbg's office and he requested that I submit the screen shots. To investigate the possibility of a difference, he requested that I go back to ipython 2 and rerun the code (then submit those screen shots). These are the resulting screen shots:

    overflow2

    plot2

    Side note: Agreed, the grey surround does look much nicer.

  3. JeremyMMulcahey commented on Feb 6, 2015

    @JeremyMMulcahey
    Author

    It appears the image dimensions, and the plot dimensions, are contained within the notebook. Hope this helps!

  4. added this to the 3.0 milestone on Feb 7, 2015
  5. takluyver commented on Feb 7, 2015

    @takluyver
    Member

    I've marked this as 3.0 to ensure one of us takes a look at it.

  6. jdfreder commented on Feb 9, 2015

    @jdfreder
    Contributor

    The reason this happens is because the following div doesn't have a width: 100%:

    It's not that simple. We can't set the width to 100% because that's used by the resize handle.

  7. takluyver commented on Feb 9, 2015

    @takluyver
    Member

    @jdfreder's PR #7718 would put oversize outputs in a scrolling box instead of letting them spill out of the page. Is that preferable?

    We can't set the width to 100% because that's used by the resize handle.

    Could we set max-width?

  8. jdfreder commented on Feb 9, 2015

    @jdfreder
    Contributor

    Could we set max-width?

    That worked.

    Yet another alternative solution, which I attempted but didn't have any luck achieving, is to make the page resize to the output contents.

  9. takluyver commented on Feb 19, 2015

    @takluyver
    Member

    Looking back at this, I was under the impression that in IPython 2.x images were resized to fit in the page, based on the screenshots people showed. Going and fiddling with IPython 2.x myself, I can easily get images to spill out of the page area. Possibly we've just made the page area a bit narrower for IPython 3?

    screenshot showing plots exceeeding page width

  10. takluyver commented on Feb 19, 2015

    @takluyver
    Member

    It's a Firefox/Webkit difference - If I open the same notebook in Chromium, the images are resized to fit the notebook page.

  11. takluyver commented on Feb 20, 2015

    @takluyver
    Member

    Gah, browsers and CSS flexbox. It's all inconsistent.

    Firefox with or without the #7721 fix (it appears to make no difference):

    screenshot from 2015-02-19 16 02 58

    Chromium with #7721 applied:

    screenshot from 2015-02-19 16 03 23

    Chromium with #7721 reverted:

    screenshot from 2015-02-19 16 07 51

    So if we revert #7721, the behaviour of wide images in outputs is consistent across browsers, but it's a regression for Chrome users who like image output resized to fit in the notebook.

    I think resizing is probably the right thing to do for images in markdown cells, though.

  12. takluyver commented on Feb 20, 2015

    @takluyver
    Member

    why a "resize handler" is needed?

    I don't know the details for this one, but making complex applications behave as you expect in the browser, especially across different browsers, requires a pile of hacks. If we're doing things on resize events, I seriously doubt that we can get rid of that without breaking something else fairly badly.

    @jdfreder @minrk or @Carreau may be able to fill in the details.

  13. modified the milestones: 3.1, 3.0 on Mar 18, 2015
  14. added 2 commits that reference this issue on Mar 28, 2015
    f12764f
    80ed08e
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

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions