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
Though I came across these in working on #1677, this is separate and points out some problems in the current image widget independent of whether mouse/click traits are added.
I've tried to make this list fairly complete to create a checklist for a PR to fix; hopefully I can propose some solutions in the next day or two.
First, a bit of background: The Image widget accepts a width and height that are used to set the height/width tag on the img element in the front end.
Also, this ended up a bit repetitive. There is a notebook in a gist working through all of this too.
The Image widget width and height are, in all but the most simple case of an isolated image widget not in a Box, likely to be ignored, and will definitely be overridden by width/height properties of the containing box. The reason for both is that CSS rules always override the width/height in the img tag.
The height is always ignored, even in an Image widget displayed by itself (no box) in a cell, because height is set by the notebook CSS to auto, so the height in image tag is ignored.
The actual size of the image as displayed on screen is not exposed to python...those values are conceivably of interested for, e.g., preserving aspect ratio or scaling mouse clicks. The actual size should be exposed because it depends on things essentially unknowable to python, like the computed style that applies to the image once it is embedded in other Widgets (or a narrow browser window).
An image displayed in an isolated Image widget has its aspect ratio preserved. The same widget, embedded in a Box whose layout.height (or width) is set will not be displayed with the intrinsic aspect ratio. The CSS wins, and the CSS doesn't know about aspect ratios...BUT...
...the image display size can be set by setting image_widget.layout.height (or width), though...
...you need to set both to guarantee the correct aspect ratio.
Putting an image in a box whose dimensions matches the image dimensions (i.e. the box layout's height and width match the height and width of the underlying image data) results in a display image that is 4 pixels smaller in height than the underlying image, though the display width is the underlying image width. This is because there is a margin of 2px in the CSS for jupyter-widget and the height is set to auto. No clue why the width isn't reduced if I set the width to auto.
Setting padding and/or a border on the Image widget reduces the displayed size of the image (which it should), but there is no way to get that size from python.
The JavaScript properties width and height of the HTMLImageElement for the image on the front end are always the rendered width/height of the image (which they are supposed to be), and are unrelated to with width/height in the image tag or, as a consequence, the width/height attributes in the back end.
Edit: The Image widget documentation need some work on explaining sizing.
The text was updated successfully, but these errors were encountered:
And just noticed the gist doesn't display the widgets. Sorry about that...if you download it it should be self-contained except for the reference image, which looks like this:
Though I came across these in working on #1677, this is separate and points out some problems in the current image widget independent of whether mouse/click traits are added.
I've tried to make this list fairly complete to create a checklist for a PR to fix; hopefully I can propose some solutions in the next day or two.
First, a bit of background: The
Image
widget accepts a width and height that are used to set the height/width tag on theimg
element in the front end.Also, this ended up a bit repetitive. There is a notebook in a gist working through all of this too.
Image
widget width and height are, in all but the most simple case of an isolated image widget not in aBox
, likely to be ignored, and will definitely be overridden by width/height properties of the containing box. The reason for both is that CSS rules always override the width/height in theimg
tag.height
is always ignored, even in anImage
widget displayed by itself (no box) in a cell, becauseheight
is set by the notebook CSS toauto
, so the height in image tag is ignored.Image
widget has its aspect ratio preserved. The same widget, embedded in aBox
whoselayout.height
(or width) is set will not be displayed with the intrinsic aspect ratio. The CSS wins, and the CSS doesn't know about aspect ratios...BUT...image_widget.layout.height
(or width), though...jupyter-widget
and theheight
is set toauto
. No clue why the width isn't reduced if I set thewidth
toauto
.Image
widget reduces the displayed size of the image (which it should), but there is no way to get that size from python.width
andheight
of theHTMLImageElement
for the image on the front end are always the rendered width/height of the image (which they are supposed to be), and are unrelated to with width/height in the image tag or, as a consequence, the width/height attributes in the back end.Image
widget documentation need some work on explaining sizing.The text was updated successfully, but these errors were encountered: