[BUG]: Automargin for quiver plots is a little off with `arrowref: 'paper'`
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 4/5
- Geschätzter Aufwand
- 3-5 Tage
- Anfängerfreundlichkeit
- 55/100
- Issue-Typ
- Bug
- Klarheit
- Größtenteils klar
- Aktivitätsstatus
- Aktiv
- Tech-Stack
- javascript
- Bereich
- data-visualization
Rechercherichtung
Beginne in src/traces/quiver/calc.js ungefähr bei den Zeilen 200–206 und reproduziere die bereitgestellte quiver-Abbildung mit arrowref auf paper gesetzt. Verfolge, wie die Endpunkte der Pfeile und die automargin-Ausmaße relativ zu den Achsenskalierungen berechnet werden. Erledigt ist die Aufgabe, wenn der anfängliche Plotbereich alle Pfeilendpunkte enthält, auch wenn sich das Seitenverhältnis der Daten erheblich von 1:1 unterscheidet.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
Desired behavior
Quiver automargin should always result in an initial plot area which contains all arrow endpoints.
Current behavior
The current quiver implementation calculates the arrow endpoints assuming arrowref: 'data', uses those endpoints to compute the automargin extents, and then if arrowref is 'paper'`, applies an adjustment factor to the arrow endpoints.
If the x:y aspect ratio of the data is pretty close to 1:1, this works OK because the arrow endpoints don't change much. But if the aspect ratio of the data is very far from 1:1, this can result in an initial plot where the arrow endpoints extend outside of the plotted area.
Example
Figure definition:
{
"data": [
{
"type": "quiver",
"uhoverformat": ".3f",
"yhoverformat": ".3f",
"xhoverfomrat": ".3f",
"vhoverformat": ".3f",
"x": [0],
"y": [0],
"u": [1],
"v": [0.1],
"arrowref": "paper"
}
],
"layout": {
"width": 800,
"height": 600,
"showlegend": false
}
}
Screenshot:
Notice how the tip of the arrow extends off the right side of the plot.
Fix
The relevant logic is around lines 200-206 in src/traces/quiver/calc.js.
It's a bit of a chicken-and-egg problem, because when arrowref is 'paper', the data position of the arrow endpoints depends on the axis scales, which depend on the position of the arrow endpoints. I think there is probably an algebraic solution but haven't quite been able to figure it out. Alternatively there's probably an iterative or approximate approach we could apply here that would still be an improvement over the current behavior.
- Vorherrschende Sprache
- JavaScript
- Sterne
- 18.3k
- Forks
- 2k
- Ø Merge
- 2 T. 17 Std.
- Gemergte PRs (30 T.)
- 22
Beitragsleitfaden
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus plotly/plotly.js
-
bug
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 85/100
-
chore P3 plotly-internal size: 3 task
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 77/100
-
chore P1 plotly-internal size: 1 task
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 82/100
-
chore P3 plotly-internal size: 1 task
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 65/100
-
bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 65/100
Alle Issues in plotly/plotly.js
Ähnliche Issues
-
Update HugeIcons library Offen
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 65/100
antfu-collective/icones#398 ·
-
ECmail.com Offen
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 90/100
wesbos/burner-email-providers#554 ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 65/100
radiantearth/stac-browser#1023 ·
-
HMR stops working Offen
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
components-web-app/docs#92 ·