SD-2468 - fix: image not being contained within cell

[chittolinag]

Issue

When images are inserted into a table cell, depending on the image size, it is overflowing the cell size.

Proposed solution

For inline images, set a maxWidth so it's scaled down (keeping the aspect ratio) when the original size would overflow the parent's size.

[linear]

SD-2468 BUG: Image within Cells not Resizing Still

[chittolinag]

Any thoughts on something that could break by changing this here? To me, this seems like the right approach because maxWidth simply tells the browser to not overflow the maximum allowed width, but it will still try to render the original size of the image. If the parent's size is smaller than the original image size, the image will be contained within.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: fcd6053597

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

Preserve aspect ratio when constraining inline image width

renderImageRun sets both img.width and img.height earlier, so this new maxWidth constraint can shrink only the rendered width in narrow containers while the fixed height remains, which visibly distorts inline images and can still blow out row height in tables. To avoid introducing that regression, the width cap should be paired with auto-height behavior when responsive shrinking occurs.

Useful? React with 👍 / 👎.

[caio-pizzol]

@chittolinag your take on maxWidth: 100% is right — browser shrinks to parent and keeps aspect ratio.

but i don't think this line runs for the ticket's repro. e-sign signatures take a different route (line 5505), and the image there already has maxWidth: 100%; height: auto from existing code.

the actual bug looks like measuring/dom/src/index.ts:1696 — it sizes the cell from the label text ("Signature" ≈ 68px) and ignores the signature image. height has a special case at 1702-1711; width doesn't. matches the ticket's hypothesis.

confirmed by adding a log on this branch — the log didn't fire for signatures.

if your repro was a regular image (not an e-sign signature), ping me — the ticket says that case already works, which is why i went to e-sign first.

[caio-pizzol]

tested this with the ticket's repro — this line doesn't run for e-sign signatures. they take a different route (line 5505), which already sets maxWidth: 100%; height: auto on the image.

what's actually wrong is at packages/layout-engine/measuring/dom/src/index.ts:1696:

const annotationWidth = textWidth + annotationHorizontalPadding;

it sizes the cell from the label text ("Signature" ≈ 68px) and ignores the image. so the cell stays tiny and a real signature gets squeezed in. height has a special case at lines 1702-1711; width doesn't.

was your repro a regular image rather than an e-sign signature?

[chittolinag]

@caio-pizzol thanks for the thoughtful review!

The fix I am proposing here is specifically for signatures drawn on esign that end up populating the signature into the document. When I execute the esign component locally (the demo app), this line gets executed, and that seems to be fixing the issue. Note that we're not talking about the actual component where we draw the signature, but instead the place it's populated into (in the document).

I just added a log there to validate. Let me know if you'd like to join on a call to take a look at it together!