Is a lean, parallel HTML-to-PDF engine in Rust technically realistic, or am I underestimating browser complexity?

I’m building an experimental HTML-to-PDF engine in Rust and would like technical feedback from people who understand browser engines, PDF generation, rendering, or high-volume document systems. The goal is to build a very low-RAM, highly parallel HTML-to-PDF engine for server workloads. Think invoices, reports, tables, receipts, business templates, generated dashboards, and API-based PDF rendering. The motivation is that Chromium/Puppeteer is very compatible, but expensive for high-volume PDF generation because each render can involve a heavy browser process/runtime. I want to explore whether a dedicated engine can cover common server-side HTML-to-PDF use cases with much lower memory and better multi-core scaling. Current architecture: HTML -> html5ever parser -> compact arena DOM -> cssparser stylesheet parsing -> cascade + computed styles -> box tree -> layout / pagination -> display list -> compressed PDF writer Some current design choices: Rust implementation no Chromium or browser subprocess compact arena-based DOM instead of pointer-heavy node graph independent render jobs so many PDFs can render in parallel across worker threads display-list boundary so layout is separate from PDF writing optional bounded pre-layout JavaScript stage behind a trait PDF backend supports compressed streams, selectable text, embedded fonts, Unicode/ToUnicode, and font subsetting work The long-term ambition is “lean and fast HTML-to-PDF with broad CSS and controlled JS support,” but I’m trying to be realistic. I know “full CSS/JS” is basically browser-engine territory, so I’m thinking the practical first target should be server-generated documents rather than arbitrary websites. Questions for the community: Is this technically realistic if the scope starts with business/document HTML rather than full browser compatibility? What are the hardest parts I’m likely underestimating? Which CSS/layout features are absolutely necessary for real-world adoption? Is pre-layout deterministic J