PDF

PDF - Document Production Workbench

Script Path Setup (MANDATORY before any script call)

All paths are relative to $PDF_SKILL_DIR. Resolve it once before calling any script:

PDF_SKILL_DIR="<skill_directory>"   # ← parent directory of this SKILL.md

For Python imports (when generation code needs to import skill modules):

import sys, os
PDF_SKILL_DIR = "<skill_directory>"
_scripts = os.path.join(PDF_SKILL_DIR, "scripts")
if _scripts not in sys.path:
    sys.path.insert(0, _scripts)

Triage

Determine task weight to control how much context to load:

⚠️ Pre-Routing Checks (run BEFORE matching brief)

1. Emoji Check - Scan user content for intentional emoji (decorative 📊🎯🔥, not OS-level emoji input). If found → force Creative pipeline (Fixed-Canvas or Flow depending on document type) regardless of original routing. ReportLab renders emoji as □ squares; LaTeX drops them entirely.
2. CJK Check - Chinese/Japanese/Korean content needs font coverage. Report brief must register CJK fonts - probe first with ls /usr/share/fonts/truetype/chinese/ (Linux) or check $FONT_DIR (macOS) to confirm which fonts exist, then register accordingly (prefer NotoSerifSC > Noto Sans SC; never hardcode a font name without verifying it exists). Creative Fixed-Canvas and Creative Flow briefs must load Google Fonts Noto Sans SC with font-display: swap; Academic brief must use \usepackage{ctex}.
3. Size Check - Non-standard page sizes (not A4/Letter/A3) → prefer Creative brief (Playwright handles any dimension). ReportLab can do custom sizes but pagination is manual.
4. Character Safety Check - Before writing any content string, scan for Japanese kana (の、が、は etc.), unusual Unicode symbols, or non-CJK characters that may corrupt during encoding transit ( Especially when code is written via heredoc/base64/LLM output). Replace with plain Chinese equivalents: の→之/的/缔, 々→omit or write full character. If content must preserve Japanese, use only standard CJK Unified Ideographs (U+4E00-U+9FFF) and common kana; avoid rare/private-use codepoints.

Briefing

Match the user's intent to a production brief. Each brief contains the full workflow, tech stack specifics, and references to shared typesetting assets.

User Request
│
├─ Work with existing PDF? ─────────────┬─ Extract/merge/split/fill/convert → briefs/process.md
│                                       ├─ Reformat/redesign → briefs/process.md (extract) → delegate to report or creative brief
│                                       └─ User provides a PDF template/reference to match style
│                                          → briefs/process.md "Template-Guided Reformat" → delegate to matched brief
│
├─ Report / proposal / white paper / contract / analysis?
│  └─ ────────────────────────────────── → briefs/report.md   (ReportLab)
│
├─ Poster / invitation / infographic / dashboard / creative layout?
│  └─ ────────────────────────────────── → briefs/creative-fixed-canvas.md  (Playwright, fixed-canvas)
│
├─ Guide / handbook / catalog / introduction / collection (text-heavy + design)?
│  └─ ────────────────────────────────── → briefs/creative-flow.md  (Playwright, flowing content)
│
├─ Academic paper / thesis / math / IEEE / ACM / LaTeX?
│  └─ ────────────────────────────────── → briefs/academic.md  (Tectonic)
│
├─ Math-heavy doc / TikZ diagram / algorithm pseudocode / Beamer slides?
│  └─ ────────────────────────────────── → briefs/academic.md  (Tectonic, Scenarios A-D)
│
├─ Document needs complex embedded diagrams (flowcharts, architecture, neural nets)?
│  └─ Route by target brief:
│     ├─ Report → Playwright+CSS → PNG → ReportLab Image() flowable
│     ├─ Creative → directly in HTML (CSS flexbox/grid + connectors)
│     └─ Academic → complexity-based:
│        ├─ Simple (≤6 nodes, linear/tree) → TikZ native (vector)
│        └─ Complex (>6 nodes, branches, annotations) → Playwright+CSS → PNG → \includegraphics
│
└─ Resume / CV?
   ├─ ATS-safe / corporate ─────────── → briefs/resume.md
   ├─ Creative / design industry ────── → briefs/creative-fixed-canvas.md   (resume sub-section)
   └─ Academic CV / publications ────── → briefs/academic.md   (resume sub-section)

Detection Keywords

Complete Scenario Routing Matrix

Below is an exhaustive map of every known PDF request type to its handling strategy. If a scenario is not listed, route to the closest match or ask the user.

Creation (Generate PDF from scratch)

Processing (Manipulate existing PDF)

Special Routing Rules

** Emoji rule (CRITICAL - check FIRST)**: Content with intentional emoji (📊🎯🔥💡 etc.) → force Creative pipeline (use briefs/creative-fixed-canvas.md for visual-first designs, briefs/creative-flow.md for text-heavy documents) regardless of original routing. ReportLab renders emoji as □ squares; LaTeX silently drops them. This rule overrides Report/Academic routing. Even if the user says "report" - if the content has emoji, use a Creative brief.

Non-standard page size rule: Dimensions other than A4/Letter/A3 → strongly prefer Creative pipeline (briefs/creative-fixed-canvas.md or briefs/creative-flow.md). Playwright handles any arbitrary page size natively. ReportLab requires manual pagination math.

Academic auto-detect: Papers, theses, or heavy math → briefs/academic.md even without explicit "LaTeX" mention.

Template-guided rule: When the user uploads a PDF and says "match this template" / "follow this style" / "reformat like this" → briefs/process.md Template-Guided Reformat section. This is a Standard triage (not Light), because it involves design decisions.

Resume routing: Default to Resume brief (ATS-safe). Creative industry → Creative brief. Academic CV with publications → Academic brief.

Shared Assets

These are referenced by multiple briefs. Each brief tells you when and what to load.

Content Rules

• Language: Match user's query language. Chinese query → Chinese PDF.
• Page/word count: Respect explicit constraints (±20%). Unspecified → completeness over brevity.
• Outline: User-provided outlines are sacred. No reordering without asking.
• Citations: No fabrication. Chinese → GB/T 7714, English → APA. Search to verify.
• Multi-part requests: Generate ALL parts - never silently drop a component.

Content Depth and Richness Standards (Anti-Shallow Writing)

PROBLEM TO AVOID: Shallow content with paragraphs containing only 1-2 sentences, or sections with minimal text under headings.

Minimum Content Standards

1. Paragraph Depth

   • Each paragraph MUST contain at least 3-5 sentences
   • Single-sentence paragraphs are FORBIDDEN (except for transitional statements)
   • Each paragraph should develop ONE complete idea with supporting details

2. Section Completeness

   • Each section heading MUST be followed by substantial content (minimum 150-200 words)
   • NEVER create a section with only 1-2 short sentences
   • If a section cannot meet minimum length, merge it with related sections

3. Content Enrichment Techniques

   • Include specific examples, data points, or case studies
   • Provide context and background information
   • Explain the "why" and "how", not just the "what"
   • Add comparisons, contrasts, or alternative perspectives where relevant
   • Include implications, consequences, or recommendations

Writing Quality Checklist

Before finalizing ANY written document, verify:

• No paragraph has fewer than 3 sentences
• No section has fewer than 150 words of body content
• Each main point is supported by examples or evidence
• Technical terms are explained when first introduced
• Transitions connect ideas between paragraphs and sections

Content Expansion Strategies

When writing feels thin, apply these techniques:

For Analysis/Reports:

• Add background context (history, current state, trends)
• Include multiple perspectives or stakeholder views
• Provide specific metrics, statistics, or quantitative data
• Discuss limitations, challenges, or counterarguments
• Offer actionable recommendations with rationale

For Explanatory Content:

• Use analogies to clarify complex concepts
• Provide step-by-step breakdowns where applicable
• Include real-world applications or use cases
• Address common questions or misconceptions
• Add visual descriptions or diagram explanations

FORBIDDEN PATTERNS:

• Section with heading followed by only 1-3 sentences
• Bullet lists without explanatory context
• Conclusions that merely restate the introduction
• Sections that say "as mentioned above" without adding new value

Language Consistency Rule

Always use the same language as the user's input language for:

• The response and document content
• Any generated report, PDF, or plot/diagram
• Cover page: All text on the cover (title, subtitle, tags, author, footer) MUST match the user's prompt language. Chinese prompt → Chinese cover; English prompt → English cover. Mixing is forbidden.
• Charts and figures: Before generating any chart or figure, determine the user's language. Ensure that the title, legend, labels, and other textual elements are consistent with the user's language. If any element cannot use the user's language, explicitly explain the reason.

HTML Image Source Path Rules

When embedding images in HTML documents (Creative pipeline, Playwright-rendered diagrams, or any HTML→PDF flow):

Iron rules:

1. NEVER use absolute paths for local files in HTML <img>, <source>, CSS url(), or any other asset reference (e.g. /Users/alice/project/img.png). Absolute paths break portability across machines and environments.
2. Always use relative paths anchored to the HTML file's own directory. If the image lives in a subdirectory, use images/foo.png or ./images/foo.png.
3. Remote URLs (http:// / https://) are fine as-is - do not convert them to local paths.
4. When generating HTML from a script or blueprint, ensure all referenced assets are either (a) in the same directory as the output HTML, or (b) in a clearly named subdirectory (e.g. assets/, images/), and referenced with relative paths.
5. If a build script needs to resolve paths programmatically, compute relative paths at generation time (e.g. os.path.relpath(image_path, html_dir)) rather than embedding absolute filesystem paths.

Figure & Diagram Embedding (All Briefs)

Iron Rule: Figures Are Block-Level

Figures, diagrams, and charts MUST be independent block elements occupying full width. Never float/wrap figures alongside body text - this causes the text-diagram overlap badcase.

Complex Diagram Strategy

When a diagram has >12 nodes, >3 subgroups, or intricate connections, do NOT try to render it as one giant figure. Instead:

1. Table for details - structured data (phases, components, specs) goes into a proper table
2. Simplified overview diagram - a stripped-down flowchart/Mermaid showing only the top-level flow (≤8 nodes)
3. Cross-reference - table caption + diagram caption reference each other

This "table + simple diagram" pattern prevents:

• Diagrams overflowing page boundaries
• Text becoming unreadably small to fit everything
• Layout engines mishandling oversized graphics

Diagram Content Quality Rules (Cross-reference: charts)

The rules above handle how to embed diagrams in PDF. For what the diagram itself looks like (node layout, connector routing, color, readability), follow the charts skill rules:

Before generating ANY flowchart/diagram for PDF embedding, check these:

1. Connectors must not pass through nodes - If 3+ layers exist, connect adjacent layers only (top→mid, mid→bottom). Never draw top→bottom lines through middle nodes. Use detour paths if cross-layer links are needed.
2. Multiple arrows into one node must not pile up - Distribute entry points evenly along target edge, or use merge-then-enter pattern (sources converge to a vertical merge line, then single arrow to target).
3. Low-saturation fills only - Node backgrounds must be pale (#EFF6FF, #F0FDF4). High-saturation colors (#3B82F6, #10B981) only for borders or small accents. No children's-art color schemes.
4. Phase titles vs sub-steps must be visually distinct - Different background color, font size, and font weight. Never same-style boxes for both.
5. Font sizes must be readable at final output size - Sizes depend on the embedding context:

   Output context	Node title min	Description min	Label min
   Standalone PNG (web/presentation, ≥1200px wide)	14px	12px	11px
   Embedded in A4 PDF (ReportLab/LaTeX, ~450pt content width)	10pt	8pt	7pt
   Embedded in slide deck (landscape, ~720pt wide)	12pt	10pt	9pt

   Principle: After embedding, the smallest text in the diagram must still be legible when the document is viewed at 100% zoom. If the diagram is scaled down to fit page width, recalculate: effective_size = original_size × (display_width / canvas_width). If effective size drops below the minimum, either increase original font size or reduce diagram complexity.
6. Legend/annotations must not overlap content - Separate container, ≥ 40px gap from last node, fully within canvas bounds.

For Playwright-rendered diagrams: Use low-saturation fills (#EFF6FF, #F0FDF4), CSS flexbox/grid for node layout, SVG <line>/<path> for connectors, and verify no overlap at final render size. For ReportLab-drawn diagrams: Same principles apply - use Drawing() with explicit coordinates, check node bounding boxes for overlap before finalizing.

Diagram Generation Strategy (Per-Brief)

Diagram rendering depends on the target brief - NOT a one-size-fits-all TikZ pipeline.

Playwright+CSS diagram pipeline (Report & Academic-complex):

# 1. Write diagram HTML (CSS grid/flexbox + connectors)
cat > diagram.html << 'EOF'
<!-- LLM generates: nodes as divs, arrows as SVG/CSS -->
EOF

# 2. Screenshot at 2× for print quality (300dpi equivalent)
python3 "$PDF_SKILL_DIR/scripts/pdf.py" convert.blueprint diagram.html --device-scale-factor 2 --output diagram.png
# Or via Playwright directly:
# page.screenshot(path='diagram.png', scale='device', device_scale_factor=2)

# 3a. Embed in ReportLab (Report brief)
from reportlab.platypus import Image
img = Image('diagram.png', width=450)  # auto height via aspect ratio
story.append(img)

# 3b. Embed in LaTeX (Academic brief, complex diagrams only)
# \includegraphics[width=\columnwidth]{diagram.png}

🚫 FORBIDDEN for Report/Creative briefs: Do NOT use TikZ standalone → compile → pdftoppm → PNG pipeline. This route has no LaTeX compiler and the extra compilation steps are error-prone.

TikZ remains valid ONLY for:

• Academic brief with simple diagrams (≤6 nodes, linear/hierarchical)
• Direct tikzpicture embedding in LaTeX documents
• Math-annotated diagrams where LaTeX math rendering matters

See briefs/academic.md Scenario B for TikZ templates (simple diagrams only).

Vector Rendering Iron Rule

The final PDF MUST be generated via page.pdf() (Playwright) or ReportLab/LaTeX native output - NEVER via screenshot-to-PDF.

Why: page.pdf() produces vector text + vector shapes. Text remains selectable, sharp at any zoom, and file size is smaller. Screenshot-based PDFs are raster images - blurry when zoomed, unsearchable, and 3-5× larger.

The ONLY place screenshot/PNG embedding is acceptable:

• Diagrams embedded as sub-elements inside a larger document (e.g., flowcharts in a Report). These use page.screenshot() at 2× device scale factor for 300dpi print quality, then embed via Image() (ReportLab) or \includegraphics (LaTeX).
• Chart images generated by matplotlib/plotly saved as PNG, then embedded.

These are sub-elements, not the document itself. The document-level PDF output must always be vector.

Quick test: Open the generated PDF, zoom to 400%. If text is blurry, you used a screenshot pipeline. Fix it.

HTML→PDF Engine Selection Rules

There are two dedicated scripts for HTML→PDF. Choose based on document type:

Poster / Single-Page Long-Image → html2poster.js

node "$PDF_SKILL_DIR/scripts/html2poster.js" poster.html --output poster.pdf --width 720px

html2poster.js automatically:

• Forces overflow: hidden on .poster / .page containers (clips decorative overflow)
• Injects @page { margin: 0 } (zero margins always)
• Syncs html/body background with poster background color
• Measures .poster scrollHeight and uses it as PDF height
• Generates a single-page vector PDF with exact content dimensions

Use this for ANY fixed-width, dynamic-height, single-page design.

Documents / Multi-Page → html2pdf-next.js

node "$PDF_SKILL_DIR/scripts/html2pdf-next.js" input.html --output output.pdf --width 210mm --height 297mm
# Or via pdf.py wrapper:
python3 "$PDF_SKILL_DIR/scripts/pdf.py" convert.html input.html --output output.pdf

Pre-render hooks auto-handle Mermaid/KaTeX rendering, overflow detection, and font loading. Paged.js polyfill is injected for pagination (break-inside/before/after, orphans/widows, named pages). Use --nopaged flag to fall back to Chromium native @page pagination if needed.

⚠️ Iron Rule: No Hand-Written Playwright Scripts

Common issues with hand-written Python page.pdf() (the dedicated scripts handle these automatically):

1. Missing @page rule → browser default margin causes content overflow to second page or white edges
2. Oversized elements not fixed → large elements with break-inside: avoid block pagination, content gets truncated
3. Rendering before fonts are loaded → Chinese text displays as squares or falls back to wrong font
4. No overflow detection → content exceeds page boundary without awareness
5. No metadata → PDF title, author, and other info missing

Iron rule: Posters and cover pages use html2poster.js, multi-page documents use html2pdf-next.js. Do not write hand-written Python Playwright scripts.

⚠️ Cover page gotcha: Cover HTML uses position: absolute for layout. Always use html2poster.js for cover pages — html2pdf-next.js + Paged.js would re-layout absolute-positioned elements into flow, destroying the cover design.

No overflow:hidden on Fixed-Size Pages

NEVER set overflow: hidden on html, body, .page, or the main container in HTML intended for PDF conversion. Paged.js handles content chunking and pagination natively — it does not need overflow clipping.

Note: This rule does NOT apply to posters rendered via html2poster.js - that script automatically adds overflow: hidden to .poster/.page containers to clip decorative overflow.

Always pair fixed-size pages with @media screen auto-scale so the full page is visible in any browser window without scrolling. See briefs/creative-fixed-canvas.md § 0.5 for the CSS pattern.

Full-Bleed Rule (No White Margins)

When generating HTML for Playwright page.pdf(), the content MUST fill the entire page with zero margins. White side margins = broken layout.

Mandatory CSS for any HTML → PDF:

@page {
  size: <width> <height>;  /* e.g., 720px 960px, or A4 */
  margin: 0;
}
html, body {
  margin: 0;
  padding: 0;
}

Common causes of white margins:

1. Missing @page { margin: 0 } - browser default margins kick in (~1cm each side)
2. Content width doesn't match page width - e.g., canvas is 720px but page is A4 (794px)
3. Missing @page { size } declaration in the HTML
4. Content has explicit max-width that's narrower than the page

For blueprint pipeline: design_engine.py now injects @page { size: var(--canvas-w) var(--canvas-h); margin: 0; } automatically. For raw HTML: YOU must include the @page rule. No exceptions. For direct Playwright: Pass margin: { top: 0, right: 0, bottom: 0, left: 0 } to page.pdf().

Background Color Consistency (No Color Mismatch)

html / body background color must match the content canvas background color.

Playwright page.pdf({ printBackground: true }) renders the body background color. If body is white while the content area is gray/colored, color-inconsistent borders/gaps will appear in the PDF.

Single-color documents (all pages same background)

/* MANDATORY: body background = content background */
html, body {
  margin: 0;
  padding: 0;
  background: var(--c-bg);  /* Same color as content canvas */
}

Multi-page documents with mixed backgrounds (e.g. dark cover + white body pages)

Root cause: Playwright resolves .page { width: 210mm } and @page { size: 210mm } to slightly different sub-pixel values (e.g. 793.688px vs 793.701px). This creates a <1px gap at the right/bottom edge of each .page div where body's background shows through. On dark pages, a white body background makes this gap visible as a white edge.

Fix - set body background to the document's dominant dark color:

:root {
  --primary: #0f172a;  /* darkest page background */
}
html, body {
  margin: 0;
  padding: 0;
  width: 210mm;  /* match @page size */
  background: var(--primary);  /* fallback for sub-pixel gaps */
}

Why this works and doesn't break white pages:

• Dark pages: sub-pixel gap reveals dark body → gap invisible.
• White pages: .page-white { background: #ffffff } fully covers body → dark body never visible.
• The gap is <1px - even on white pages, the dark body at the extreme pixel edge is imperceptible after anti-aliasing.

Rule: when generating multi-page HTML with mixed backgrounds, always set html, body { background } to the darkest page's background color. If all pages are light/white, use the lightest content background (e.g. #f8fafc). Never leave body background unset (browser default = white = guaranteed white edges on dark pages).

### Content Centering (No Left/Right Drift)

**After HTML-to-PDF conversion, content must be centered, no left or right drift allowed.**

Common drift causes:
1. `@page { margin }` not 0 - browser default margin causes drift
2. `.safe-zone` or content container `inset` / `padding` left-right asymmetric
3. Content container has `max-width` but no `margin: 0 auto`
4. Grid components only occupy partial column width (e.g. `1/1 → X/7` only uses left half)
5. **Decorative elements overflow page boundary** - elements with `width > 100%` or negative offsets (e.g. glow circles, gradient overlays) inflate `scrollWidth` beyond page width. Playwright shrinks all content to fit, causing left-shift. **Fix: constrain decorative elements within page bounds** (`width` ≤ 100%, no negative `left`/`right` offsets). See `briefs/creative-fixed-canvas.md` §0.75 and `typesetting/overflow.md` §3.5 for details.

### Anti-Void Edges (No Large Blank Margins)

**Content should not have large meaningless whitespace at page edges, top, or bottom.**

- Content should make full use of page area; do not cram all content in the top half while leaving the bottom blank
- For multi-page documents, each page's fill rate should be ≥ 60% (see `pagination.md` last page ≥ 40% rule)
- For single-page posters/infographics, fill rate should be ≥ 70%

---

## Preflight (Quality Assurance)

Every PDF must pass preflight checks before delivery. Each brief specifies the exact commands.

### HTML Pre-Render Validation (MANDATORY for ALL HTML→PDF paths)

**Before** calling `html2pdf-next.js`, `html2poster.js`, `convert.blueprint`, or any Playwright `page.pdf()`, run:

```bash
python3 "$PDF_SKILL_DIR/scripts/poster_validate.py" check-html <your_file>.html

Key checks:

• OVERFLOW_HIDDEN_CONTAINER (error): overflow:hidden on html/body/.page clips content and hides layout bugs. Paged.js handles pagination without needing overflow clipping
• FIXED_SIZE_NO_SCREEN_ADAPT (warning): fixed-size page without @media screen auto-scale - browser preview requires scrolling
• SCREEN_ADAPT_NO_SCALE (warning): @media screen exists but lacks scale/transform/zoom
• FONT_NO_FALLBACK (error): font-family without generic fallback
• COLOR_CONTRAST (warning): text/background contrast ratio < 3:1
• Plus: remote images, absolute paths, missing margin reset, tiny fonts, background mismatch, etc.

This applies to all three HTML routes: Creative blueprint pipeline, Report HTML covers, and bypass/custom HTML.

Overflow Prevention System

→ Full spec: typesetting/overflow.md - read it for any document with tables, images, or multi-column layouts.

Core principles:

1. Measure first, draw second - never render content without pre-calculating its dimensions
2. Bounding Box constraint - every element's width ≤ its parent container's Max_Width
3. Text: use font metrics, not character count, for width calculation
4. Images: proportional scaling - never insert at original size
5. Tables: weight-based column width + Paragraph() wrapping (never plain strings)
6. Fallback ladder: wrap → shrink font (max -3pt) → reduce padding → split element → log warning
7. Vertical: KeepTogether for heading+body, chart+caption; repeatRows=1 for long tables

Table Overflow Prevention (ReportLab)

Most common layout bug: table columns exceed page margins.

Before building any ReportLab Table:

1. Calculate available_width = page_width - left_margin - right_margin
2. Use proportional colWidths ([0.25, 0.40, 0.20, 0.15] × available_width) or fixed+flex pattern
3. sum(colWidths) must be ≤ available_width - verify this in code
4. Long text columns must use Paragraph() wrapping, not plain strings (plain strings don't wrap)
5. CJK text is wider: budget ~12pt per character at 10pt font size

See briefs/report.md § "Table Width Management" for code patterns.

Table Overflow Prevention (LaTeX/Academic)

Most common bug in dual-column papers: wide tables overflow single-column width.

Before writing any LaTeX table:

1. Count data columns - ≤ 4 fits single column; 5-6 needs \small; 7-8 needs \resizebox; ≥ 9 use table* (full width)
2. Use tabular*{\columnwidth} or tabularx{\columnwidth} instead of plain tabular for 5+ columns
3. Never use plain tabular with 8+ columns in twocolumn layout - guaranteed overflow
4. \resizebox{\columnwidth}{!} as last resort - verify smallest text ≥ 6pt after scaling

See briefs/academic.md § "Table width management" for LaTeX patterns.

Playwright PDF CSS Blacklist

These CSS properties silently break in Playwright's PDF renderer:

• backdrop-filter / -webkit-backdrop-filter - drops entire element content. Use solid rgba() backgrounds.
• overflow: hidden on content containers - clips content. Only safe on small decorative elements (< 200px).

After generating any Playwright PDF, verify every page has content (pypdf text extraction, check non-empty).

PDF Metadata (all briefs)

ALL PDFs must have: Title, Author (default "Z.ai"), Creator, Subject.

Delivery Summary (all briefs)

Report to user: file path, size, page count. Academic adds word/image count. Creative adds per-page verification.

HTML→PDF route deliverables (MANDATORY - applies to ALL briefs that use Playwright/HTML to generate PDF): Whenever the HTML→PDF pipeline is used (Creative route, Report cover bypass, Direct HTML Flow posters, or any Playwright page.pdf() path), you MUST deliver both files to the user:

1. HTML - the source HTML file, so the user can edit and reuse the design
2. PDF - the final vector PDF (page.pdf() output)

Optionally also provide: 3. Image - a full-page screenshot/preview image (PNG or JPG) for quick sharing on chat/social media

All file paths must be reported to the user. Never deliver only the PDF without the HTML source.

Tooling Reference

CLI: python3 "$PDF_SKILL_DIR/scripts/pdf.py" <command>

# Environment
env.check                    # Check deps
env.fix                      # Auto-install missing

# Quality
code.sanitize <script>       # Sanitize forbidden Unicode
content.sanitize <file> [--apply]  # Fix content issues (CJK, encoding)
meta.brand <pdf>             # Add Z.ai metadata
font.check <pdf>             # Scan for missing glyphs
toc.check <pdf>              # Validate TOC

# Conversion
convert.blueprint <llm_json_response.md> -o final.pdf  # CRITICAL FOR CREATIVE: Auto-extracts JSON, compiles, and renders PDF.
convert.html <html>          # HTML → PDF (Playwright)
convert.latex <tex>           # LaTeX → PDF (Tectonic).

…(truncated)