Claude Opus 5.5 SVG Diagrams: Fix Clipped Labels Without Shrinking Everything

When an Opus-generated SVG label is clipped, inspect the text bounds, its containing shape and the SVG viewport separately. Ask for a local geometry fix instead of shrinking every label. The goal is a diagram that remains readable at its actual display size and still means the same thing after editing.

MDN documents SVG's text element. Text position and the surrounding rectangle are separate properties, so a larger label does not automatically enlarge its box. The example below is an original proposed layout, not a claim about an executed Opus result.

Identify which boundary is wrong

Use a fictional three-step product setup: Unpack, Attach stand, Adjust angle. Suppose the middle card's label now reads “Attach the adjustable stand.” The correct repair depends on what hides the text.

A viewport change will not fix a label that still extends outside its own card. Widening that card will not fix a clip path left at the old size. Ask the model to name the relevant element IDs so a reviewer can inspect the change.

Calculate usable width before choosing a wrap

In a hypothetical 240-unit card with 20 units of left and right padding, the label has 200 units available. If the rendered label measures 224 units, it exceeds that space by 24. A 264-unit card would fit those measured bounds with the same padding, but only if neighboring cards and connectors also have room.

Alternatively, use two lines and increase card height if necessary. Do not estimate rendered width by counting characters: font, weight and language matter. These numbers are a worked layout example, not measurements of an attached file.

Ask Opus for a patch and a render

Use Opus 5.5 to repair the supplied SVG setup diagram. Preserve its three steps, order, wording and connector destinations. Focus on the middle label and identify its text element, card element and any clipping path.
Measure rendered text with the actual font if the environment provides a browser or renderer. If it does not, say the width is unverified. Compare label bounds with the card's inner width and the drawing with the viewBox.
Choose a local fix: meaningful line breaks, more card space or a corrected clip boundary. Do not shrink every font or change the words to hide the problem. Reroute affected arrows without changing their meaning.
Return the edited SVG and a change list. Render at the intended display width and at a narrow phone width. Check for clipped labels, missing fonts and arrow collisions. If you cannot render, report that explicitly rather than claiming visual validation.

Verify the exported file, not only the chat preview

Open the saved SVG in the target browser or design application. Check that the file you opened is the new version, that all three labels appear, and that the connectors still express the intended sequence. An appealing chat preview is not proof that a separate exported file contains the same markup.

For a phone layout, three columns may need to become a vertical sequence. That is a deliberate layout variant, not simply a smaller copy. Preserve the step order and give the file a distinct name so it is not confused with the desktop version.

If the diagram illustrates a product feature, retain the verified geometry and wording as a reference for the advertisement. Use Panelly Studio for the companion image; feature-callout guidance helps connect labels to visible details. This does not imply that Panelly imports editable SVG layers or integrates Opus.

FAQ

Why not just outline all the text?

Outlines can preserve glyph shapes in some handoffs, but reduce text editability and do not fix poor spacing. First solve the layout, then choose a delivery format for the recipient's actual workflow.

Can I accept a model's “all checks passed” message?

Ask which file and render it checked. If no rendering tool ran, treat the statement as a proposed check, not evidence that the output was inspected.

Sources and further reading

• Original reference · developer.mozilla.org