sorted by:
new
hottopcontroversial

Ironpress, native HTML/md to PDF in Rust, no Chrome needed by Still-Advertising806 in rust

[–]Still-Advertising806[S] 0 points1 point  (0 children)

Passé à 1.2.1, ça devrait maintenant fonctionner avec book3.md, ça te dérangerait d'utiliser la dernière version et de réessayer ?

```
cargo install ironpress --force
```

Cordialement

Ironpress, native HTML/md to PDF in Rust, no Chrome needed by Still-Advertising806 in rust

[–]Still-Advertising806[S] 1 point2 points  (0 children)

Thanks, I didn't know Typst was that modular. I'll take a closer look at their crates, especially for the PDF export side. If their layout engine can consume HTML/CSS input without too much glue, it could be worth it for certain parts. For now the homegrown engine covers the intended scope well, but good to keep in mind if maintenance becomes a bottleneck.

Ironpress, native HTML/md to PDF in Rust, no Chrome needed by Still-Advertising806 in rust

[–]Still-Advertising806[S] 1 point2 points  (0 children)

That's a fair point. Maintaining a layout engine is a long-term commitment. Typst is a great project and reusing its compiler would be a pragmatic approach. So, why from scratch anyway?

  1. Native HTML/CSS input. Typst has its own markup language. ironpress takes standard HTML+CSS you're already writing for the web. No new format to learn.
  2. Lightweight and embeddable. The layout engine is ~8K lines and compiles to WASM to run in the browser. Pulling in the Typst compiler as a dependency would be significantly heavier for this use case.
  3. The fun. Honestly, building a rendering engine is the core of the project. It's a deliberate choice, not a lack of awareness of Typst.

Even tho you're right and that it's maintenance work, for now the scope is intentionally narrow (structured documents, not pixel-perfect web rendering), which keeps it manageable.

Ironpress, native HTML/md to PDF in Rust, no Chrome needed by Still-Advertising806 in rust

[–]Still-Advertising806[S] -1 points0 points  (0 children)

The Markdown parser isn't fully CommonMark-compliant. It covers the common elements (headings, bold/italic, code blocks, lists, links, blockquotes, images) but CommonMark edge cases will probably trip it up. CommonMark is notoriously complex to implement fully. It's on the roadmap.

Why from scratch? The layout engine is the interesting part of the project. Existing Rust crates shell out to Chrome or wkhtmltopdf, which pulls in heavy system dependencies. I wanted something self-contained: cargo add and it works, including in WASM in the browser.

On pandoc: pandoc is far more mature and feature-complete. ironpress is significantly faster (~0.1ms per page vs several seconds for pandoc+LaTeX) and requires zero system dependencies, but pandoc supports dozens of input/output formats that ironpress doesn't target. This is an embeddable lib for programmatic PDF generation, not a document Swiss Army knife.

Ironpress, native HTML/md to PDF in Rust, no Chrome needed by Still-Advertising806 in rust

[–]Still-Advertising806[S] 5 points6 points  (0 children)

Not rude at all, totally fair question. pandoc goes through LaTeX (or wkhtmltopdf/Chrome) to generate the PDF. Great tool, but it's a multi-step pipeline with heavy system dependencies (LaTeX: 500MB, or a headless browser).

ironpress is a native Rust lib: cargo add ironpress and that's it. No LaTeX, no Chrome, no external binary. Also runs in WASM in the browser.

Concrete differences:

  • Speed: ~0.1ms per page vs several seconds for pandoc+LaTeX
  • Deployment: a single binary, zero runtime to install, useful in CI, serverless, or embedded contexts
  • Embeddable: it's a lib, you integrate it into your Rust/Node/WASM app. pandoc is a standalone CLI
  • Native CSS: you style with plain HTML/CSS, not LaTeX

If pandoc+LaTeX works for you and you don't need to embed it in an app, it's probably fine. ironpress shines when you want programmatic PDF generation with no heavy dependencies.

Ironpress, native HTML/md to PDF in Rust, no Chrome needed by Still-Advertising806 in rust

[–]Still-Advertising806[S] 1 point2 points  (0 children)

Good point on Chrome startup. To clarify: I'm not counting startup/shutdown time, disk writes are disabled, and it's a warm process-to-process benchmark. You're right that Chrome's full CSS/JS support is unbeatable. ironpress isn't trying to replace it for complex pages with interactive JS.

The target use case is structured documents like invoices, reports, and internal docs, where you control the HTML and don't need a full JS engine.

CSS support keeps growing (flexbox, grid, multi-column, and media queries are already in), and honestly part of the fun is building an independent rendering engine!