基于 Hyperframes Embedded Captions 的排版预设体系：cap-* 样式、tone 语气与按栏宽缩放的字号矩阵

基于 Hyperframes Embedded Captions 的排版预设体系：cap-* 样式、tone 语气与按栏宽缩放的字号矩阵

【免费下载链接】hyperframesWrite HTML. Render video. Built for agents.项目地址: https://gitcode.com/GitHub_Trending/hy/hyperframes

Hyperframes 仓库内置的embedded-captions技能（SKILL.md）提供了一整套把字幕"嵌入"真人出镜视频的排版系统，而 typography-presets.md 正是这套系统的排版字典：五个cap-*命名样式、独立的tone（soft/present）语气通道、按 caption 栏宽缩放的字号矩阵，以及"什么不能做"的硬约束。它解决的问题是——同一个计划文件plan.json里，每一行字幕应该如何根据语义角色（开场白、主句、情感高峰、梦境回忆、高潮收束）选择字号、字重、斜体和动效气质。读完本文，你将掌握这套五样式预设的完整参数表、自动选型决策树、跨栏宽/横竖屏/透视旋转的字号换算规则，以及如何在模板 CSS 中依据场景亮度调整文字颜色，并能结合仓库源码理解这些规则在plan.json中的落地方式。

一、五个命名样式：cap-*的语义分工

typography-presets.md定义了五种命名样式，它们对应模板中的cap-*CSS 类。核心思想是：每一行字幕（caption group）不是平等的，字号、字重、斜体都是语义的视觉翻译。选型依据是该行的语义角色（semantic role），而不是机械地"每一行都一样大"。

值得注意的细节：intro与dream都是斜体，但字重不同（500 vs 700），斜体在此处承担的是"低视觉重量 / 记忆想象"的语义符号；emph与crown都是正体且字号递增（92 → 140），字重 800 → 900，形成"强调 → 压倒性高潮"的递进。这种"斜体表诗意、正体表陈述、越大越重越接近高潮"的设计语言，在 typographic-moves.md 中被进一步展开为完整的"排版动作"调色板（italic contemplative opener、upright pivot、uppercase climax 等）。

二、tone字段：独立于样式的动效气质通道

每个 caption group 除了style，还有独立的tone字段，取值soft或present。样式决定"静态长相"，tone 决定"入场动效气质"。

• soft—— 轻柔淡入 + 8px 纵向漂移入场，power2.out缓动。整体感觉飘浮、怀旧。用于记忆、开场、梦境。
• present—— 干脆利落的 6px 纵向位移 + 1.04 倍缩放弹出，power3.out缓动，transformOrigin居中。整体感觉笃定、当下在场。用于强调与 crown。

这组数值在 DNA 层有精确的源码对应。以仓库中creamDNA（dna/cream.json）为例，其motion配置正是这套参数的落地：

"motion": { "soft": { "y": 8, "blur": 2.5, "dur": 0.5, "ease": "power2.out" }, "present": { "y": 6, "blur": 1.5, "scale": 1.03, "dur": 0.3, "ease": "power3.out" }, ... }

可以推断，soft的y:8与power2.out、present的y:6+scale弹跳与power3.out在渲染时被编译进 GSAP 时间线，实现"飘浮怀旧 vs 当下笃定"两种截然不同的观感。tone与style正交组合，意味着同一种字号可以有两种气质——这是整个系统表达力强的原因之一。

三、自动选型：一行字幕的决策树

typography-presets.md给出了一个可执行的自动选型流程：扫描每个 group 的词，按优先级依次判定：

1. 是否含最高级词汇（incredible、best、only、never、always）或品牌/专有名词？→emph+present
2. 是否以话语标记词开头（you know、so、well、look）或很短（≤3 词）？→intro+soft
3. 是否涉及梦想、希望、记忆、过去时动词（如 "was dreaming"）？→dream+soft
4. 是否为收尾点睛句、感觉像标题/头条？→crown+present（每个视频仅一次）
5. 否则 →phrase+ （跟随相邻 group 的 tone；默认soft）

这套决策树与分组逻辑紧密衔接——caption-grouping.md 规定了如何把 Whisper 词级转录切分成groups[]（停顿 ≥500ms 断句、句号/问号/感叹号终止、强逗号、话语重置词、每组最多 6 词或 2.5 秒等），并在"Style & tone"一节明确交叉引用本预设文档：第一组默认intro+soft，情绪升格时进入present，crown最多保留一个、通常是最后一行。该文档还给出了 champion 示例的完整分组 JSON——"You know, for me…" 开场为intro，主体陈述为phrase，高潮句 "I've achieved incredible things" 为emph+present，"dreaming of becoming number one" 为dream，"Wimbledon Champion" 为crown——正好是五样式决策树的完整走查样例。

四、字号随栏宽缩放：核心矩阵

预设样式默认值是按约 560px 栏宽（最初的 champion 构图）调校的。当 caption plane 比这个宽时，字体显得"重量不足"——文字周围负空间过多。需要相应放大。

补充规则：

• crown 尺寸假设横屏（1920×1080）。竖屏 1080×1920 时，所有 crown 尺寸除以 1.5。
• 整幅 crown= 居中，设计为跨越0.8 × 帧宽以上、穿过人物身体。仅在 layout-heuristics.md § Crown placement 的条件满足时使用——该文档给出了三个量化条件：主体大致居中（|body_center_x − frame_width/2| < frame_width × 0.10）、两侧安全区各 ≥15% 帧宽、crown 词宽 > 主体宽 + 400px（否则字母被身体吞掉）。
• 仅安全区 crown= crown 放置在某个安全区内，字号更小，尾字母轻轻触及主体。当居中 crown 会吃掉过多画面时作为兜底。
• 若 plane 的rotateY非平凡（比如 >8°），有效可见宽度会收缩，字号需上调约 10% 补偿。

从 layout-heuristics.md 的实战样例可以印证这套矩阵的实际使用：champion 场景（1920×1080、书架背景）使用corner-column-crown模板，wall_position: { top: 40, left: 40, width: 720, height: 420, rotateY: 4 }、crown_position: { top: 440 }——720px 的栏宽恰好落在 600-760px 中档区间，对应矩阵中phrase108px、crown220px 这一档。而 bespoke-vs-presets.md 记录的 champion 实际调校值（cap-intro52 /cap-phrase60 /cap-emph70 /cap-crown140）则说明矩阵是"起点"而非"铁律"——具体场景仍需按需微调。

五、硬约束：什么不能做

typography-presets.md明确列出四条禁区，这些约束防止预设系统被滥用而失去意义：

• 每次渲染最多一个 crown。它的全部意义就在于"唯一的回报时刻"。
• emph使用不超过约 30% 的 group。处处强调等于没有强调。
• 不要因为词短就给主内容选intro。如 "I won"（2 词）应是emph或crown，而不是intro。
• 不要无理由地在soft和present间交替。tone 应跟随叙事弧线：soft 开场 → present 推进 → emph 高峰 →（可选）crown 高潮收束。

这些约束在技能层有更广的呼应：SKILL.md 的 Non-negotiables 一节把"嵌入是稀缺且有间隔的"列为不可妥协原则（每句/每拍最多 1 个 embed，apex全片仅一个），而 composition-craft.md 给出的对比度下限（climax 必须比 body-emphasis 大 ≥1.8×、比最小层级大 ≥2.5×）则是emph → crown递进关系的量化版本。简言之：预设系统的美学逻辑建立在"层级对比"而非"统一放大"之上。

六、场景亮度影响颜色选择

默认文字颜色是暖骨白#fff5df。当场景主色偏移时，在模板 CSS 中调整：

• 墙面以暖木色/棕褐为主 → 保持默认，或偏冷#e8f0ff
• 墙面为冷蓝/科技实验室 → 推暖#fff0c0
• 墙面有强烈主色 → 去饱和默认色，亮度优先

这些调整发生在 HTML 模板中，而不是plan.json中。如果反复需要不同调色板，应制作新的模板变体。这一点与 bespoke-vs-presets.md 的规则完全一致——Cinematic 模式不允许在plan.json里覆盖颜色或混合模式（make-composition.cjs会忽略plan.cap_color/blend_mode/text_shadow/text_filter），模板的mix-blend-mode+ 填充色是locked DNA。#fff5df正是 dna/cream.json 中palette.cap_color的值，佐证了预设与 DNA 层的直接对应关系。选色的正确姿势是：用 caption 区域亮度探测（<60 暗场 / 60-180 中间调 / >180 亮场）来选择本来就匹配的模板，而不是给模板改色。

七、预设与源码的落地链路

从仓库源码结构看，这套排版预设贯穿了 embedded-captions 技能的三层管线：

1. 作者层：在plan.json的每个 group 中写"style": "intro|phrase|emph|dream|crown"与"tone": "soft|present"，或者通过"custom_css"覆盖具体字号（bespoke-vs-presets.md 展示了"custom_css": ".cap-intro { font-size: 52px; } .cap-phrase { font-size: 60px; }"的写法，并建议对照本预设文档的字号矩阵确定目标值）。
2. 编译层：scripts/fill-timings.cjs→scripts/fit-fonts.cjs→scripts/make-composition.cjs把 plan 编译成index.html，每个 group 写入<div id="cg-N" class="cap-…">。
3. 校验层：scripts/check-occlusion.cjs、check-overflow.cjs、check-timing.cjs等门禁在渲染前验证遮挡、溢出与时序（composition-craft.md 给出了预估公式：max_font_px = frame_width / (chars × char_ratio × letter_spacing_mult)，大写 900 的 char_ratio 约 0.62）。

三个关键约束在整个链路上被反复强调：crown 一次只能一个、emph不超过约 30%、tone 跟随叙事弧线——它们保证了这套五样式预设在任何场景下都不会退化成"平平无奇的统一字幕"。对于想深入了解的读者，建议按序阅读 typography-presets.md（本文档）、typographic-moves.md（更自由的排版动作调色板）、layout-heuristics.md（crown 放置与安全区数学）以及 caption-grouping.md（分组与选型的衔接）。

【免费下载链接】hyperframesWrite HTML. Render video. Built for agents.项目地址: https://gitcode.com/GitHub_Trending/hy/hyperframes