3.5 KiB
iftypeset — Competitor / Positioning Matrix (v0.1)
This is a practical market map to keep us honest about what exists today and what iftypeset is trying to be.
The category we’re building
Not “Markdown to PDF” (that’s solved), but:
Deterministic publishing CI: Markdown → styled output plus enforceable QA gates (widows/orphans/overflow/keeps/link wrap) with machine-readable reports and coverage tracking.
High-level landscape
A) Renderers / converters (output-first)
Great at converting formats, but usually do not ship “layout QA gates” as a product.
- Pandoc (+ LaTeX) / Quarto / RMarkdown
- Typst
- LaTeX toolchains
- Markdown site tools that export PDF (MkDocs, Docusaurus, GitBook, Notion exports)
B) Paged-media engines (layout-first)
Excellent at pagination + print rules, but they don’t give you a Chicago/Bringhurst rule registry or a publishing QA runtime by default.
- PrinceXML
- Antenna House Formatter
- WeasyPrint
- Vivliostyle / Paged.js
- wkhtmltopdf (HTML → PDF, limited paged-media fidelity)
C) SaaS PDF rendering APIs
Operational convenience; QA gates are typically “your responsibility”.
- DocRaptor (Prince-powered)
- Various HTML→PDF APIs (vendor-specific)
Feature comparison (typical, not absolute)
Legend:
- ✓: first-class / native
- ~: possible but not the default product shape
- —: not typical / not supported
| Capability | iftypeset (goal) | Pandoc/Quarto | Typst | LaTeX | Prince/AH | WeasyPrint | Vivliostyle/Paged.js |
|---|---|---|---|---|---|---|---|
| Markdown → HTML | ✓ | ✓ | ~ | ~ | — | — | ✓ |
| Markdown → PDF | ✓ (via adapters) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ (via headless browser) |
| Deterministic artifacts (stable HTML/IDs) | ✓ | ~ | ~ | ~ | ~ | ~ | ~ |
| Profile tokens (web_pdf/print_pdf/etc.) | ✓ | ~ | ~ | ~ | ~ | ~ | ~ |
| Rule registry w/ pointers (no quotes) | ✓ | — | — | — | — | — | — |
| Lint + autofix (editorial hygiene) | ✓ | ~ | ~ | ~ | — | — | — |
| Post-render QA gates (widows/orphans/overflow) | ✓ | — | — | — | ~ | ~ | ~ |
| Coverage reporting for implemented rules | ✓ | — | — | — | — | — | — |
| Degraded-mode handling (garbage inputs) | ✓ | ~ | ~ | ~ | — | — | — |
What’s actually different about iftypeset
-
Quality is a build gate
Not “this looks nice”, but “this fails CI if link-wrap/table overflow/stranded headings exceed thresholds”. -
Rules are a registry (not hardcoded CSS) Chicago/Bringhurst become paraphrased, pointer-backed records you can audit, diff, and expand over time.
-
Renderer-agnostic
The PDF engine is pluggable. The “meaning” is in tokens + QA + reports, not the renderer choice. -
Traceability-compatible Machine outputs (reports/coverage) can be hashed/signed and attached to IF.TRACE receipts.
Who pays for this (practical)
- Teams who must ship PDFs that survive scrutiny:
- GRC / security (SOC2/ISO evidence packs, policy docs)
- research/publishing (tech reports, standards commentary)
- legal/professional services (deliverables that must look “court-ready”)
- vendor marketing with constraints (docs that must be consistent across versions)
Messaging that is honest
- “Markdown in, publication-quality out — with QA gates and receipts.”
- “It fails the build if the PDF is sloppy.”
- “Rules are paraphrased + pointer-backed; no book text shipped.”