Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

[FEATURE]: get_subplot_geometry()

Offen
  • Stimmt etwas nicht?
#5,554 4 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
35/100
Issue-Typ
Feature
Klarheit
Größtenteils klar
Aktivitätsstatus
Ruhig
Tech-Stack
javascript, jupyter-notebook, python
Bereich
api, data-visualization, frontend

Rechercherichtung

Beginne damit, die Einstiegspunkte von Figure und FigureWidget sowie die bestehende Layout- oder Geometriebehandlung dahinter zu finden. Vergleiche den vorgeschlagenen Pfad über das Live-Graph-div mit dem statischen Kaleido-Pfad und definiere anschließend Tests für die zurückgegebenen Abmessungen von Subplots und Figures, die Filterung und die Einbeziehung von Achsenbeschriftungen. Als erledigt gilt die Aufgabe, wenn eine konsistente Schnittstelle für beide Backends mit dokumentierten Pixelkoordinaten funktioniert.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

feature

[FEATURE]: get_subplot_geometry() — Expose Computed Subplot Cell Pixel Positions

Summary

When building dashboards or figures with custom overlays, users frequently need to know
the exact pixel position and dimensions of each subplot cell. Plotly computes these
internally but never surfaces them. This issue proposes a new method
get_subplot_geometry() that returns the computed pixel boundaries of every subplot
in a figure for production use.

Problem Statement

There is currently no reliable way to answer the question:

"Where exactly, in pixels, does subplot xy start and how wide and tall is it?"

Users who need this information are forced to either:

  • Hardcode pixel values based on trial and error (breaks on resize or data change)
  • Reverse-engineer Plotly's internal domain-to-pixel calculations (brittle, undocumented)
  • Call full_figure_for_development(), which is explicitly not for production use, slow,
    and returns normalized domain values (0–1) rather than actual pixels

This is a recurring pain point for users building:

  • Dashboards where external HTML elements must align with specific subplot axes
  • Stacked figures that need pixel-perfect y-axis alignment across separate charts
  • Custom annotation layers that anchor to subplot cell boundaries
  • Accessibility tools that need to describe where each chart lives on screen
Proposed Solution

A new method on Figure and FigureWidget:

geometry = fig.get_subplot_geometry()
Example Return Structure
{
    "subplots": {
        "xy": {
            "x": 80,
            "y": 60,
            "width": 400,
            "height": 300,
            "x2": 480,
            "y2": 360
        },
        "x2y2": {
            "x": 520,
            "y": 60,
            "width": 400,
            "height": 300,
            "x2": 920,
            "y2": 360
        }
    },
    "figure": {
        "total_width": 1000,
        "total_height": 800
    }
}

x and y are the top-left corner of the inner plotting area (inside the axes,
excluding tick labels and axis titles), measured in pixels from the top-left of
the figure.

Optional Parameters
# Include outer bounding box that covers tick labels and axis titles
fig.get_subplot_geometry(include_axis_labels=True)

# Limit results to specific subplots
fig.get_subplot_geometry(subplots=["xy", "x2y2"])
Two Backend Paths, One Interface
  • FigureWidget in Jupyter: queries the live graph div directly for true
    browser-rendered pixel values
  • Static Figure: falls back to a scoped Kaleido render using the figure's
    explicit width and height

The user does not manage which path is used — the method selects automatically.

JavaScript Access
// No new method needed for JS users
gd._computedLayout.subplots["xy"].x
gd._computedLayout.subplots["xy"].width
gd._computedLayout.figure.total_width
Why Not Use full_figure_for_development()?

full_figure_for_development() exposes normalized domain values (e.g. [0.0, 0.45])
but:

  • Does not return pixel positions
  • Is documented as not for production use
  • Is slow and returns a very large object
  • Does not reflect true browser dimensions when using FigureWidget

This feature is the production-safe, pixel-accurate alternative for layout geometry
specifically.

Prior Art
Tool Equivalent
matplotlib ax.get_position(), ax.get_window_extent()
bokeh plot.inner_width, plot.inner_height
Browser DOM element.getBoundingClientRect()
Backward Compatibility

This is a purely additive change. No existing figures, attributes, or workflows
are affected.

Related Issues

I'm happy to help refine the return structure, naming conventions, or scope.
The goal is to open a concrete discussion rather than a vague wish.

Vorherrschende Sprache
Python
Sterne
18.8k
Forks
2.8k
Ø Merge
13 Std. 28 Min.
Gemergte PRs (30 T.)
20

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus plotly/plotly.py

Alle Issues in plotly/plotly.py

Ähnliche Issues

Weitere Issues zu Python

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.