Show HN: I taught Claude Code to draw diagrams – the XML pitfalls were brutal

Show HN: I taught Claude Code to draw diagrams – the XML pitfalls were brutal(github.com)

2 points by ekusiadadus 152 days ago | 3 comments

vunderba 152 days ago |

Wow that does sound like a pain. This might be a bit of a long shot, but depending on the requested diagram, you might be able to deterministically figure out whether it could be adequately represented as Mermaid UML and then import it into draw.io, since it has a built-in Mermaid importer.

I mention this because in my experience Claude is really good at one‑shotting Mermaid UML diagrams.

gonc_cc 152 days ago |

This looks useful. I’m curious how the diagram generation handles layout constraints in draw.io, especially for arrow routing and CJK text sizing. Is most of this heuristic-based or driven by draw.io’s internal layout rules?

ekusiadadus 152 days ago | |

  Great question! The current implementation is relatively straightforward:

  Layout: The diagram generation uses fixed coordinate positioning (x, y values) calculated heuristically based on node indices and predefined
  spacing. For example, flowcharts use a simple vertical layout with consistent spacing. There's no automatic layout engine - it's manual
  coordinate calculation.

  Arrow routing: Currently uses simple direct connections between source and target nodes. draw.io handles the actual path rendering, but we don't
   leverage draw.io's advanced edge routing algorithms (orthogonal routing, etc.) - arrows just connect the specified entry/exit points.

  CJK text sizing: This is actually an area that could use improvement. The current implementation doesn't dynamically calculate text width for
  CJK characters. Node widths are set to fixed values (e.g., 120px for flowchart nodes), which works reasonably for short labels but may clip
  longer CJK text. draw.io does handle CJK rendering internally, but we're not pre-measuring text to adjust geometry.

  So to directly answer: it's mostly heuristic-based with fixed layouts, not leveraging draw.io's internal layout rules. The .drawio XML format
  gives us the geometry, and draw.io renders it. Future improvements could include:
  - Auto-layout algorithms (dagre.js style)
  - Text measurement for proper sizing
  - Smarter edge routing

  Thanks for the interest!

Great question! The current implementation is relatively straightforward: Layout: The diagram generation uses fixed coordinate positioning (x, y values) calculated heuristically based on node indices and predefined spacing. For example, flowcharts use a simple vertical layout with consistent spacing. There's no automatic layout engine - it's manual coordinate calculation. Arrow routing: Currently uses simple direct connections between source and target nodes. draw.io handles the actual path rendering, but we don't leverage draw.io's advanced edge routing algorithms (orthogonal routing, etc.) - arrows just connect the specified entry/exit points. CJK text sizing: This is actually an area that could use improvement. The current implementation doesn't dynamically calculate text width for CJK characters. Node widths are set to fixed values (e.g., 120px for flowchart nodes), which works reasonably for short labels but may clip longer CJK text. draw.io does handle CJK rendering internally, but we're not pre-measuring text to adjust geometry. So to directly answer: it's mostly heuristic-based with fixed layouts, not leveraging draw.io's internal layout rules. The .drawio XML format gives us the geometry, and draw.io renders it. Future improvements could include: - Auto-layout algorithms (dagre.js style) - Text measurement for proper sizing - Smarter edge routing Thanks for the interest!