starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Images in rack view not formatted, right hand side is cropped #3369

New Issue
Closed
opened 2025-12-29 18:28:25 +01:00 by adam · 5 comments
adam commented 2025-12-29 18:28:25 +01:00
Owner
Copy Link

Originally created by @tfboy on GitHub (Feb 21, 2020).

Originally assigned to: @jeremystretch on GitHub.

Environment

  • Python version: 3.6.8
  • NetBox version: 2.7.7

Steps to Reproduce

  1. Upload an image formatted to the correct aspect ratio (226x19 was suggested) to a front or rear image of a device type. Save.
  2. Go to a rack view containing device which has had an image uploaded.

Expected Behavior

Image is shown correctly, scaled so that the entirety of it fits the width (and appropriate number of RU height).

Observed Behavior

No matter what I try, the right hand side of the image is always cut off. This happens regardless of the image size / aspect ratio.

Searching into this a bit more, I think the issue is related to the CSS code which enforces a width of 260px when the rectangle box representing the rack is 229px wide.

<image class="device-image" height="20" preserveAspectRatio="none" width="260" x="30" xlink:href="/media/deicetype-images/<filename>" t="0"></image>

Upon further experimenting, if you set the preserveAspectRatio to "yes", then the image's aspect ratio is respected and squeezed to fit inside the width of 230 / 30x number of RU of device and it is also centered. This might be a good way of working around issue of certain images having the rack ears in them (19") or only the "opening" (circa 17.5") width.

Originally created by @tfboy on GitHub (Feb 21, 2020). Originally assigned to: @jeremystretch on GitHub. <!-- NOTE: IF YOUR ISSUE DOES NOT FOLLOW THIS TEMPLATE, IT WILL BE CLOSED. This form is only for reproducible bugs. If you need assistance with NetBox installation, or if you have a general question, DO NOT open an issue. Instead, post to our mailing list: https://groups.google.com/forum/#!forum/netbox-discuss Please describe the environment in which you are running NetBox. Be sure that you are running an unmodified instance of the latest stable release before submitting a bug report. --> ### Environment * Python version: 3.6.8 <!-- Example: 3.6.9 --> * NetBox version: 2.7.7 <!-- Example: 2.7.3 --> <!-- Describe in detail the exact steps that someone else can take to reproduce this bug using the current stable release of NetBox (or the current beta release where applicable). Begin with the creation of any necessary database objects and call out every operation being performed explicitly. If reporting a bug in the REST API, be sure to reconstruct the raw HTTP request(s) being made: Don't rely on a wrapper like pynetbox. --> ### Steps to Reproduce 1. Upload an image formatted to the correct aspect ratio (226x19 was suggested) to a front or rear image of a device type. Save. 2. Go to a rack view containing device which has had an image uploaded. <!-- What did you expect to happen? --> ### Expected Behavior Image is shown correctly, scaled so that the entirety of it fits the width (and appropriate number of RU height). <!-- What happened instead? --> ### Observed Behavior No matter what I try, the right hand side of the image is always cut off. This happens regardless of the image size / aspect ratio. Searching into this a bit more, I think the issue is related to the CSS code which enforces a width of 260px when the rectangle box representing the rack is 229px wide. `<image class="device-image" height="20" preserveAspectRatio="none" width="260" x="30" xlink:href="/media/deicetype-images/<filename>" t="0"></image>` Upon further experimenting, if you set the preserveAspectRatio to "yes", then the image's aspect ratio is respected and squeezed to fit inside the width of 230 / 30x number of RU of device *and* it is also centered. This might be a good way of working around issue of certain images having the rack ears in them (19") or only the "opening" (circa 17.5") width.
adam added the type: bugstatus: accepted labels 2025-12-29 18:28:25 +01:00
adam closed this issue 2025-12-29 18:28:25 +01:00
adam commented 2025-12-29 18:28:26 +01:00
Author
Owner
Copy Link

@tfboy commented on GitHub (Feb 21, 2020):

Now I can see where the initial 226x19 comes from: 230 - 2x2 pixels for width border and 220 - 1px for height.

However, the aspect ratio of 226x19 is ~18.895
If we include rack ears, then physical dimension for 1RU of a standard 19" rack is 19" x 1.75", i.e. AR ~10.857
If we exclude rack ears, then physical dimension for 1RU is approx 17.5" x 1.75", i.e. 10.

So it might be worth considering resizing the aspect ratio of the rectangular box representing a rack to be closer to the 10-11 aspect ratio for each RU rather than the 18-19 it is at the moment if we want to support images more or less accurately and not have them too distorted / stretched horizontally.

I find the current height of the rack drawing OK (~20px per RU). If we make it larger, then it will be difficult to have an entire rack fit in a typical 1920x1080 px screen resolution. In other words, keep the height the same and maybe reduce the width.

My racks have devices with fairly long names, but those names still only occupy less than half the width, so I think it would be easy to reduce the width of racks to get closer to the true aspect ratio of equipment without making a mess of device labels when images are not shown / not present.

@tfboy commented on GitHub (Feb 21, 2020): Now I can see where the initial 226x19 comes from: 230 - 2x2 pixels for width border and 220 - 1px for height. However, the aspect ratio of 226x19 is ~18.895 If we include rack ears, then physical dimension for 1RU of a standard 19" rack is 19" x 1.75", i.e. AR ~10.857 If we exclude rack ears, then physical dimension for 1RU is approx 17.5" x 1.75", i.e. 10. So it might be worth considering resizing the aspect ratio of the rectangular box representing a rack to be closer to the 10-11 aspect ratio for each RU rather than the 18-19 it is at the moment if we want to support images more or less accurately and not have them too distorted / stretched horizontally. I find the current height of the rack drawing OK (~20px per RU). If we make it larger, then it will be difficult to have an entire rack fit in a typical 1920x1080 px screen resolution. In other words, keep the height the same and maybe reduce the width. My racks have devices with fairly long names, but those names still only occupy less than half the width, so I think it would be easy to reduce the width of racks to get closer to the true aspect ratio of equipment without making a mess of device labels when images are not shown / not present.
adam commented 2025-12-29 18:28:26 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Feb 21, 2020):

There are a couple factors in play here, so I'm going to comment inline.

I think the issue is related to the CSS code which enforces a width of 260px when the rectangle box representing the rack is 229px wide

It looks like this stems from a bug introduced in #3986, where the rectangles which represent devices are drawn using an absolute position rather than a width:

end_cordinates = (legend_width + unit_width, end_y)

If we remove legend_width the rectangles are correctly rendered to the specified unit_width.

However, the aspect ratio of 226x19 is ~18.895

This is only ~11.9, but regardless: device blocks should render as 230x20. Once that's fixed, it gives us a ratio of 11.5:1, whereas the real physical aspect ratio of a rack unit is 10:1 as you've mentioned.

So it might be worth considering resizing the aspect ratio of the rectangular box representing a rack to be closer to the 10-11 aspect ratio for each RU

Right. We can either make each unit taller in height, or narrower in width to get a 10:1 aspect ratio.

I find the current height of the rack drawing OK (~20px per RU). If we make it larger, then it will be difficult to have an entire rack fit in a typical 1920x1080 px screen resolution. In other words, keep the height the same and maybe reduce the width.

I worry about reducing the unit width as it's already pretty short on space for text, but we do want to try and keep the whole rack visible without scrolling.

@jeremystretch commented on GitHub (Feb 21, 2020): There are a couple factors in play here, so I'm going to comment inline. > I think the issue is related to the CSS code which enforces a width of 260px when the rectangle box representing the rack is 229px wide It looks like this stems from a bug introduced in #3986, where the rectangles which represent devices are drawn using an absolute position rather than a width: ```python end_cordinates = (legend_width + unit_width, end_y) ``` If we remove `legend_width` the rectangles are correctly rendered to the specified `unit_width`. > However, the aspect ratio of 226x19 is ~18.895 This is only ~11.9, but regardless: device blocks should render as 230x20. Once that's fixed, it gives us a ratio of 11.5:1, whereas the real physical aspect ratio of a rack unit is 10:1 as you've mentioned. > So it might be worth considering resizing the aspect ratio of the rectangular box representing a rack to be closer to the 10-11 aspect ratio for each RU Right. We can either make each unit taller in height, or narrower in width to get a 10:1 aspect ratio. > I find the current height of the rack drawing OK (~20px per RU). If we make it larger, then it will be difficult to have an entire rack fit in a typical 1920x1080 px screen resolution. In other words, keep the height the same and maybe reduce the width. I worry about reducing the unit width as it's already pretty short on space for text, but we do want to try and keep the whole rack visible without scrolling.
adam commented 2025-12-29 18:28:26 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Feb 21, 2020):

We do need the legend width to appropriately move the rack beside the legend I believe, unless we do this another way

@DanSheps commented on GitHub (Feb 21, 2020): We do need the legend width to appropriately move the rack beside the legend I believe, unless we do this another way
adam commented 2025-12-29 18:28:27 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Feb 21, 2020):

Yeah it was just a bug: Instead of being drawn from X position 30 to 260, it was being drawn from position 30 to a width of 260 (instead of 230).

@jeremystretch commented on GitHub (Feb 21, 2020): Yeah it was just a bug: Instead of being drawn from X position 30 to 260, it was being drawn from position 30 to a _width_ of 260 (instead of 230).
adam commented 2025-12-29 18:28:27 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Feb 21, 2020):

My PR above compromises on adjusting the default width and height to (220, 22). This achieves the desired 10:1 aspect ratio without increasing the image size too much, I think. If it does present a problem we should look into determining the user's viewport size dynamically and requesting a specific size SVG to fit.

@jeremystretch commented on GitHub (Feb 21, 2020): My PR above compromises on adjusting the default width and height to (220, 22). This achieves the desired 10:1 aspect ratio without increasing the image size _too much_, I think. If it does present a problem we should look into determining the user's viewport size dynamically and requesting a specific size SVG to fit.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label status: accepted type: bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#3369
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?