Graphviz的dot不支持逻辑分页,需先输出SVG再按cluster或标签分组切片生成多页PDF;rank=same失效主因是节点跨subgraph,须确保同子图且避免高权值边干扰;JSONB等高级类型需SQL层显式映射;中文模糊需统一字体路径并设fontname,箭头变形应改用open/normal样式。
ER图导出时分页错乱,dot 渲染不自动分页怎么办
graphviz 的 dot 本身不支持逻辑分页——它只按图布局输出单张大图。所谓“分页”,其实是后续用 pdf 工具(如 pdfcrop、ps2pdf -spapersize)或前端库(如 pdf-lib)切片实现的。
常见错误是直接调 dot -Tpdf 期望生成多页 PDF,结果得到超宽/超高不可读的单页;或者用 CSS @media print 强行分页,但 dot 输出的 SVG 没有语义分块,浏览器无法合理断页。
- 真正可控的分页路径:先用
dot -Tsvg输出 SVG → 用脚本解析或自定义label标记逻辑模块 → 按模块分组生成多个 SVG → 各自转 PDF 再合并 - 若必须单次输出,可临时加
-Gpagesize="8.5,11!"(注意末尾感叹号强制缩放),但会牺牲字体清晰度和连线精度 - PostgreSQL 的
pg_dump --schema-only+erd工具链默认不带分页,得在erd的--output-format=svg后接 Python 脚本做viewBox分割
自适应宽度失效,rankdir=LR 和 rank=same 冲突怎么调
ER 图横向展开时,常因实体太多触发 dot 自动换 rank 层级,导致“本该一排”的实体被硬拆成两行,视觉上断裂。根本原因是 rank=same 只在同个子图(subgraph)内有效,而跨 subgraph 的节点无法强制对齐。
典型现象:用户表、订单表、商品表明明写了 {rank=same; user; order; product;},但输出仍错位——大概率它们被分散在不同 subgraph cluster_xxx 里,或被 dot 的边权重干扰了层级计算。
- 检查所有参与对齐的节点是否在同一
subgraph下,且该subgraph未设rankdir(否则覆盖全局) - 避免给连接这些节点的边加
weight=100类高权值,它会让dot优先满足边约束而非 rank 约束 - 临时调试用:
dot -Tsvg -y(Y 轴翻转)有时能绕过某些 rank 计算 bug,尤其含中文标签时
高级扩展类型(JSONB、ARRAY、GENERATED)在 ER 图里显示为问号或空白
erd、dbdiagram.io 或自制解析器读取 PostgreSQL pg_attribute 时,若字段类型是 jsonb、text[] 或 generated always as (...) stored,默认映射表里没对应图标或文字,就回退成 ? 或留空。
这不是渲染问题,是元数据提取阶段就丢失了类型细节——比如 pg_attribute.atttypid 指向 pg_type,但 jsonb 的 typname 是 jsonb,而老版本 erd 只认 json;ARRAY 类型需查 pg_type.typarray 才能还原维度,多数工具直接忽略。
- 手动补全:在生成 DOT 前,SQL 查询里用
CASE WHEN t.typname = 'jsonb' THEN 'JSONB' ...显式转义类型名 - 用
pg_typeof()替代pg_attribute查类型,它能返回完整字符串如jsonb[] - GENERATED 列需额外查
pg_attrdef.adsrc并正则提取表达式,不能只看attgenerated字段
导出 PDF 后中文模糊、箭头变形,fontname 和 arrowhead 怎么配才稳
Graphviz 对中文字体支持极弱,默认用 Times-Roman,遇到中文直接 fallback 到位图字体,放大就糊;arrowhead 在 PDF 后端(如 Cairo)里若未预加载符号字体,实心箭头(arrowhead=vee)可能渲染成空心或错位。
关键不是换字体名,而是确保整个工具链用同一套字体路径:DOT 解析时、Cairo 渲染时、PDF 查看器打开时。三者断一环,就糊一环。
- Linux 下统一用
fc-list :lang=zh找到可用中文字体(如Noto Sans CJK SC),然后全局设-Gfontname="Noto Sans CJK SC"和-Nfontname="Noto Sans CJK SC" - 箭头问题优先换
arrowhead=open或arrowhead=normal,避开vee/crow这类依赖符号字体的样式 - Mac 上如果用 Homebrew 安装的 Graphviz,要确认
brew install graphviz --with-pango,否则 Cairo 不支持复杂文本
分页和自适应本质是妥协的艺术——dot 的布局算法不为打印设计,所有“自动”方案都会在数据量稍大时崩。真要稳定,就得接受手动切子图、固定字体路径、放弃部分高级类型自动识别。这些不是配置问题,是模型边界问题。










