PDF文件生成器

The pack's PDF side works exactly like its PowerPoint side, just with a different end product in mind. Where PresentationGenerator produces the content for a slide deck, PDFMagazineGenerator produces the content for a print-style A4 design magazine - editorial copy, page structure, and one image prompt per page. Its sibling, PDFMagazineMaker, does the actual page drawing afterward. This node is the writer in the pair.

What it is

Another vision-LLM node in the graph, and mechanically it's near-identical to PresentationGenerator: it reads your floor plan with Gemini (default), Ollama, or OpenAI, and asks the model to return a strict JSON structure. The difference is the schema and the extra input. Where the presentation schema is slide-shaped, this one is magazine-shaped - the JSON entries carry a page_type so the maker can lay out covers, contents pages, room pages, a style page, and a summary page differently instead of treating every page the same.

How it works

The node takes your image (the floor plan), encodes it to base64, and sends it with a long structured prompt to whichever provider your LLMManager configured. The response has to be a clean JSON array - the node strips code fences and parses it - and then it splits into the same two outputs as the presentation generator:

• image_prompts - a list of English image prompts, one per page, sized to feed a diffusion model directly;
• json_data - the full structured JSON the maker node will consume.

Because the magazine schema is even more rigid than the deck one, the model is being asked to follow a fairly demanding spec (per-page text lengths, room descriptions, prompts under ~80 tokens). It usually manages on a frontier model and gets sloppy on small local ones.

The inputs that matter

• image - your floor plan. Same advice as the presentation side: a clean, high-resolution plan gets you a much better magazine.
• design_style - the 11 interior styles (現代簡約風 default, 工業風, 北歐風, 日式和風, 地中海風, ...), or 自定風格 plus custom_style.
• custom_scene - optional scene hint (教室, 餐廳, ...) when the plan doesn't self-explain.
• magazine_style - the one input this node has that its sibling doesn't: 時尚雜誌風, 建築專業雜誌, 居家生活雜誌 (default), 設計師作品集, or 房地產DM. This changes the editorial voice the LLM writes in.
• llm_type - Gemini, Ollama, or OpenAI. Gemini is the sane default.

Fitting it into a workflow

floor plan → PDFMagazineGenerator → image_prompts → CLIPTextEncode → KSampler → renders
                                  ↘  json_data ─────────────────────→ PDFMagazineMaker ← floor plan (again)

Each prompt from image_prompts gets rendered to an image; then the batch of renders, the json_data, and the original floor plan all feed into PDFMagazineMaker - note the maker has a separate floorplanimage input because the plan gets drawn into the magazine's contents page, not just analyzed.

Installing and running it

It's one of five nodes in ComfyUI-DesignPack. Install the pack via ComfyUI Manager (search "ComfyUI-DesignPack") or:

cd ComfyUI/custom_nodes
git clone https://github.com/dseditor/ComfyUI-DesignPack
cd ComfyUI-DesignPack
pip install -r requirements.txt

Restart, then run LLMManager once with your Gemini key first - without it, this node returns error strings telling you no key is configured. No model files to download; the brain is a cloud API.

Where it's fragile

Same fragility as its sibling, dialed up: the magazine JSON is complex, so anything that makes the model deviate - a chatty preamble, a refusal, a weak local model - produces an "錯誤: ..." string in your outputs instead of content. If you're going to try the Ollama path, don't be surprised when a 12B model butchers the schema on the first try; this is the node where the cloud default earns its keep. And remember the output is Traditional Chinese by design - a real editorial limitation if your client doesn't read it.