Exported polygon coordinates exceed the -1..1 range: showCytoArray normalizes against a hardcoded 260px half-extent

[carlosriosilva]

Symptom

The polygon coordinates in the output box are documented and labelled as being in the -1..1 range Cytoscape polygon points use, but they routinely exceed it. Clicking near the right edge of the grid exports values around 2.0; the horizontal centre of the visible canvas does not export 0.

Root cause

showCytoArray in site/src/components/ShapeBuilder/index.js normalizes against a hardcoded 260px half-extent:

const normalized = points
  .map(([x, y]) => [(x - 260) / 260, (y - 260) / 260])

260 assumes a 520x520 canvas. The canvas is not 520x520. CanvasContainer is width: 100%; height: 520px and StyledSVG is width: 100%; height: 100% with no viewBox, so the SVG user coordinate space equals CSS pixels at whatever the viewport gives it. Measured in a real browser at a normal desktop width, the drawing surface is 834x518, not 520x520.

So:

• The X divisor is wrong by the ratio of actual width to 520 - worse the wider the window.
• The Y divisor is off by 2px, and the whole Y axis is offset because the true half-height is 259, not 260.
• The error is viewport-dependent, so two people drawing the same visible shape export different numbers.

Worked example at 800px width: the visible centre reads 0.000, while SVG point x = 400 exports 0.538.

Fix direction

One shared normalizer derived from the rendered SVG rect, used by both the export path and the hover readout, instead of a hardcoded constant:

const normalize = (x, y, halfW, halfH) => [(x - halfW) / halfW, (y - halfH) / halfH];

Take halfW/halfH from svg.getBoundingClientRect() (or from the SVG's own width/height) at the moment of conversion, in both showCytoArray and handlePointerMove. Centred -1..1 semantics are preserved; only the divisor stops being a guess.

An alternative worth considering, if a stable coordinate space is wanted independent of window size: give the SVG an explicit viewBox="0 0 520 520". Then 260 becomes correct again by construction, the exported numbers stop depending on viewport width, and the readout and export agree for free. This changes how the grid scales visually, so it is a design call.

Why this is filed separately

Raised during review of #107 (live mouse coordinate display) and independently flagged there by CodeRabbit. Deliberately not fixed in that PR: the readout feature is additive, whereas this changes the polygon values every existing user copies out of the output box. That is a product-visible output change and deserves its own review rather than riding along in a hover-readout PR.

#107 documents the divergence in a comment at normalizeToCanvas and uses honest rect-derived math for the readout, so after it lands the readout is correct and the export is the remaining wrong half. Worth fixing reasonably soon so the two do not disagree for long.