Text To Comic

text-to-comic v2

Purpose

Turn user-provided text, photo descriptions, dialog, diary entries, poems, or knowledge notes into a visual deliverable that fits the material best:

• multi-panel comic
• picture-book spread
• infographic
• hybrid comic + diagram page

Preserve the strong parts of v1:

• automatic content-type judgment
• visual-form selection
• style recommendation
• character consistency
• scene continuity
• clean-image assembly

Add v2 structure so results are easier to control and revise:

• style presets from presets/styles.json
• structured panel plan from schemas/panel-plan.schema.json
• per-panel render task and retry record from schemas/render-task.schema.json
• panel-by-panel rendering instead of one-shot full-page generation

When to use

Use this skill when the user wants to:

• draw a story as a comic or picture book
• convert dialog into a 4-panel or short comic
• turn a concept or workflow into a visual infographic
• convert travel notes, diary entries, or photo notes into illustrated output
• iterate on style, storyboard, or single-panel fixes instead of regenerating everything

Do not use this skill when the task is mainly:

• pure text writing with no visual output
• exact imitation of a living artist's distinctive signature style
• direct reproduction of copyrighted third-party material

How it differs

• Not a one-shot image generator. It produces a storyboard and panel plan you can revise before rendering, and supports per-panel retry instead of redrawing the whole page.
• Not a style-cloning tool. It recommends from curated presets and refuses to imitate a living artist's signature style.
• Not a research tool. It visualizes material you already have; it does not go find or verify the source content for you.

Decision flow

1. Classify the input as one of:
   • narrative
   • dialog
   • knowledge
   • poetic
   • hybrid
2. Choose a visual form:
   • comic
   • picture-book
   • infographic
   • hybrid
3. Pick a default format:
   • 4-panel for short dialog or punchline-based requests
   • 6-panel to 8-panel for short narrative arcs
   • single for infographic or single illustration
   • webtoon for vertical, dramatic, mobile-first storytelling
4. Pick a style preset from presets/styles.json.
5. Build a compact panel plan.
6. Render panel by panel.
7. Validate, retry if needed, then assemble the final output.

Compatibility with v1

Keep the old experience as the default:

• If the user simply says "画成漫画" or gives a short story, still auto-select a reasonable format and style.
• Keep broad support for comics, picture books, and infographics.
• Keep the v1 ideas of storyboard confirmation, character cards, scene labels, clean-image suffixes, and PIL-based assembly.

New in v2:

• Use style IDs instead of only prose style names.
• Store storyboard as structured JSON.
• Track retries and fallbacks per panel.
• Make single-panel regeneration a first-class path.

Core workflow

1. Analyze the request

Identify:

• content type
• likely visual form
• target audience
• tone
• whether the request contains a stable protagonist, multiple scenes, or mainly conceptual information

If the task is obvious, present a compact plan and continue. Ask the user to confirm before rendering when any of the following is true:

• the content could reasonably become more than one visual form
• the style choice materially changes tone
• the story needs more than 8 panels
• the request contains private or sensitive photo material
• the user supplied copyrighted third-party source text that may need summarization first

2. Create the story/panel plan

Represent the visual plan with the schema in schemas/panel-plan.schema.json.

Requirements:

• one key beat per panel
• panel count should match narrative complexity
• the last panel should carry payoff, twist, conclusion, or CTA
• keep dialog short enough to remain readable after layout
• if scenes change, make transitions legible

For infographic mode:

• use visual_form = infographic
• use format = single
• still produce a panels array, usually with one major page and multiple structured sections inside the scene/action/must_include fields

3. Create a character bible when needed

If a stable protagonist or recurring cast exists, create a compact character bible and reuse the same visual anchors in every panel.

Minimum character anchors:

• age/gender presentation when relevant
• hair
• face shape
• eyewear if any
• outfit
• accent color
• body build or silhouette
• vibe/expression

Keep these anchors stable across all panels.

4. Select and compile style preset

Use presets/styles.json as the source of truth for supported styles.

Each render prompt should combine:

• style positive template
• character-bible summary
• panel scene
• panel action
• shot type
• emotion
• must-include list
• avoid list
• global clean-image suffix

If the user gives a reference style image or a very specific style direction:

• preserve the selected style_id
• add a short reference-derived modifier instead of replacing the whole preset
• do not promise exact style cloning

5. Render panel by panel

Do not render the full page in one shot unless the request is explicitly a single illustration or infographic.

For comics or picture books:

• generate each panel independently
• keep output paths and retry records separate
• prefer clean images without embedded panel numbering
• if in-image text is unavoidable, keep it short and in English for image generation reliability
• add Chinese captions, narration, or labels during assembly when possible

6. Validate each panel

Validate against these priorities:

• character consistency
• scene continuity
• clean image without watermark/signature/panel numbering
• readable composition
• dialog within text_budget
• no obviously broken face or limb rendering

If a panel fails validation, retry with a bounded mutation ladder.

7. Retry policy

Use schemas/render-task.schema.json for retry bookkeeping.

Retry ladder:

1. shorten dialog or move text out of the image
2. simplify background and reduce secondary props
3. switch to a more stable shot such as medium
4. reduce side characters
5. fall back to a more stable style preset when appropriate

Stop conditions:

• default maximum 2 retries per panel unless the user explicitly wants more
• if the panel still fails after fallback, return the best valid storyboard plus the strongest attempt rather than silently looping

8. Assemble final output

Assembly defaults:

• 4-panel: 2x2 grid
• 6-panel or 8-panel: balanced grid with consistent gutters
• webtoon: vertical stack
• single: single page or single image

Assembly rules preserved from v1:

• crop to target ratio before final resize
• avoid panel numbering inside generated images
• keep a clean margin and readable caption area
• use warm off-white backgrounds for comic boards unless the chosen style clearly calls for another background

Hard constraints

Character consistency

If the story has a main character, every panel should clearly look like the same person. Reuse the same core descriptors and avoid drifting outfit, hair, face shape, or accent color.

Language separation

Prefer:

• English for minimal in-image text if generation quality depends on it
• Chinese for captions, narration, or post-assembly overlay

If the user explicitly wants all-Chinese bubbles, try it, but still favor readability and brevity.

Chinese dialogue and layout (中文对白与排版约束)

When the target language is Chinese (zh-CN), enforce these extra readability rules on top of text_budget. These are document-level guidance for planning and assembly; the JSON schemas are unchanged.

对白与旁白的字数上限（基于中文排版可读性）：

• 单个对话气泡：建议 ≤ 16 字（含中文标点占位，超出则拆句，不放第二行硬塞）
• 整格内所有对白合计：建议 ≤ 40 字（含标点）
• caption / 旁白单格：建议 ≤ 25 字（含标点）
• 上述字数按"每个全角字符占 1 字"计数（含标点）；若必须放入英文、数字或拼音，按 1 个半角字符 ≈ 0.6 字折算占用，避免超限

中文标点规范：

• 对话内一律使用中文标点：逗号「，」、句号「。」、问号「？」、感叹号「！」；不用半角 , . ? !
• 省略号用中文「……」；引号内对话用「」或“”；破折号用「——」
• 不使用连排标点（如 。。 ！！）；标点占位会影响字数预算

气泡内的排版建议：

• 单气泡内不换行过多：短句优先（一句一个停顿）
• 整格对白超 40 字时，拆到多格 / 多气泡，或用旁白承接，绝不让一格塞满小字
• 心情、环境等"可画出来"的信息不要写进对白，留给画面

竖排文字场景：

• 默认对白用横排（现代中文阅读习惯 + 生图可读性）
• 仅在标题、古风 / 竖排叙事、或用户明确要求时使用竖排；竖排时每列 ≤ 12 字，气泡按列排布，拼版时再叠文字
• 生图阶段文字不可控，竖排文字一律在拼版层处理，不在格内依赖 AI 直出

拼版时中文标题区建议：

• 若作品有中文标题，拼版时预留独立标题区（顶部标题条或封面区），不在第一格内直接画字
• 中文标题建议 ≤ 12 字；副标题 ≤ 20 字
• 标题区需匹配正文字体族（同一套 CJK 字体），避免系统字体缺字（如宋体 / 黑体未覆盖的生僻字）

Scene continuity

Use clear indoor/outdoor/street/home/office/etc. tags in planning when scene continuity matters. Add a transition panel if a major scene jump would feel abrupt.

Clean image rule

Use a clean-image suffix equivalent to:

• no border
• no panel frame
• no watermark
• no AI signature
• no accidental page numbering
• edge-to-edge composition

Copyright boundary

Allowed:

• user-owned stories
• user summaries of ideas or experiences
• original educational reframing

Disallowed:

• direct transformation of substantial copyrighted text or art into near-derivative output
• exact imitation of a protected living artist's signature style

Output contract

Default user-facing output should include:

• a compact explanation of chosen visual form and style
• a short storyboard summary
• final image(s) or assembled page
• concise notes if any panel required retries or fallback

Internally keep these artifacts whenever useful:

• panel_plan.json
• per-panel render task records
• retry notes

Do not force raw JSON on the user unless they ask for it or the task benefits from editable intermediate output.

Style system

Supported style presets live in presets/styles.json.

v2 keeps the spirit of the v1 style library while making it easier to render and retry:

• bright cute cartoon
• warm watercolor picture book
• Japanese shonen manga
• colorful slice-of-life manga
• Chinese gongbi comic
• ink wash comic
• 3D cartoon animation
• claymation
• sci-fi future comic
• vintage watercolor travelogue
• doodle sketch comic

When a request is ambiguous, recommend 2 to 3 styles instead of forcing a single one.

Example resources

If you need a concrete starting point, read:

• examples/four-panel-demo.json
• examples/chinese-webtoon-demo.json (zh-CN diary/slice-of-life webtoon example)
• presets/styles.json
• schemas/panel-plan.schema.json
• schemas/render-task.schema.json

Revision behavior

When the user asks for changes:

• prefer single-panel repair when the issue is local
• change style preset only if the issue is stylistic, not compositional
• change the storyboard only if the problem is narrative
• carry forward the validated character bible and successful panels whenever possible