Excalidraw+ MCP: generated CJK node and arrow labels have undersized text bounds and appear clipped until editing

Summary

Text labels created through the hosted Excalidraw+ MCP create_diagram tool can appear horizontally clipped in the Excalidraw+ editor. Entering text editing by double-clicking can make the text display correctly/reflow.

This affects both node-bound text and arrow labels. The persisted dimensions for Chinese labels are substantially smaller than browser measurements of the same strings using Excalidraw's Excalifont + Xiaolai fallback stack.

This report concerns the hosted MCP public beta (https://api.excalidraw.com/api/v1/mcp), not the separate open-source excalidraw/excalidraw-mcp server. Please redirect this report if hosted MCP issues belong elsewhere.

Minimal reproduction

1. Call read_diagram_format and create an empty scene.
2. Call create_diagram with the following input, replacing the placeholder with that scene's ID:

{
  "sceneId": "<YOUR_TEST_SCENE_ID>",
  "style": "clean",
  "direction": "RIGHT",
  "layerSpacing": 160,
  "nodes": [
    { "id": "a", "label": "admin · 管理后台\n1 副本", "kind": "service" },
    { "id": "b", "label": "ALB :8443\n后台独立 IP 白名单", "kind": "service" }
  ],
  "edges": [
    { "from": "a", "to": "b", "label": "逻辑备份" }
  ]
}

1. Read the scene with get_scene_content before editing text. No text width/height was manually supplied by the caller.
2. Open the scene in Excalidraw+ and inspect labels before double-clicking. Compare their appearance before/after entering and leaving text editing.

The clipping/edit-to-recover symptom was observed in an existing diagram created through this same API. Fresh independent test scenes reproduced the persisted width values below; their initial appearance has not independently been inspected in an authenticated Excalidraw+ browser session by the testing agent.

Persisted data and browser comparison

The generated text elements use fontFamily: 5 and autoResize: true. Both text and originalText retain the complete strings.

Text (longest line for multiline labels)	Font size	MCP-persisted width	Browser-measured width
逻辑备份	16	40.8064	64.0001
admin · 管理后台	20	128.6960	152.2799
后台独立 IP 白名单	20	118.4040	180.8599
Logical backup (English control)	16	113.5808	110.4002
admin · Management (English control)	20	192.1080	188.5798

All values are in CSS pixels. The arrow label 逻辑备份 has persisted height 20, so this is not the historical zero-height issue.

Browser measurements were executed in Chromium on the official https://excalidraw.com/ page after explicitly loading the relevant fonts, using:

await document.fonts.load('16px Excalifont', 'Logical backup');
await document.fonts.load('16px Xiaolai', '逻辑备份管理后台白名单');
const ctx = document.createElement('canvas').getContext('2d');
ctx.font = '16px Excalifont, Xiaolai, sans-serif';
ctx.measureText('逻辑备份').width; // 64.0001220703125

The measurement context was the official free web app, not the authenticated Plus editor. Different deployed font/core versions may be relevant; the comparison alone does not establish the exact backend cause.

Controls

• A second test used node widths of 360px and explicit line breaks. The Chinese arrow label still persisted with width 40.8064: widening nodes does not change this arrow-label measurement.
• An English-only node/edge-label control produced the English measurements above. Saved widths were slightly larger than browser measurements, unlike the substantial underestimation for Chinese.
• The tests used the recommended semantic create_diagram/label API rather than hand-written text-element geometry.

Expected behavior

Generated node labels and arrow labels should have dimensions consistent with the fonts used by the editor, and should display completely on first load without requiring users to double-click every label.

Investigation suggestion (not a confirmed root cause)

Please check CJK fallback availability and text measurement in the hosted diagram-generation pipeline, as well as whether imported/generated text dimensions are refreshed when the final fonts become available. The hosted implementation has not been inspected, so this report does not assert a missing font or a specific faulty function.

Related references, not asserted to be the same bug:

• #6686: invalid persisted text dimensions and text reappearing on edit (height zero in that case).
• #6367: imported text invisible until editing/reloading, attributed to a version mismatch at the time.
• Restore utilities documentation: refreshDimensions recalculates text dimensions and defaults to false.