Hacker News Reader

Comment by egnehots | Hacker News Reader

The main issue is conflating templating and pdf generation.

Using html to pdf solutions allow to do the templating in html, where it is pretty much a solved issue.

And as many said, headless chrome is a robust html to pdf solution, even though it feel like a hack.

But, yeah, there seems to be a lack of awareness about these options within corporations. So, kudos to you for addressing a genuine problem!

View on HN

Indeed, we aim at bundling this in a way that makes it easy and obvious for enterprises to build their PDFs that way.

Typst is a typesetting language that makes programmatic layout and processing JSON input pretty darn simple. I make invoices by having a Typst template read line items from a JSON file.

https://github.com/typst/typst

Just spent my Sunday creating my invoice template in typst as well. I enjoyed it, and I could do what I wanted quickly!

Never used it actually, is it in between LaTeX and Markdown with the possibility to process JSON input?

I'd describe Typst as somebody wanted a TeX reimplementation in Rust with better syntax and modern ideas, and made that their Masters projects.

It's markdown-like (but definitely not exactly CommonMark, don't expect that), with # acting as escape into the world of layout and programming. Templates are just functions that return a datatype called a content block, and so on.

https://typst.app/docs/tutorial/writing-in-typst/

Ok very interesting, i'll give it a try! Thanks for sharing

The problem with chrome is the performance, it is very slow and uses a bunch of memory. There was a neat post here awhile ago about generating pdfs faster https://news.ycombinator.com/item?id=39379690

Indeed, speed is an issue (and it's hard to tackle). Additionally, when using Chrome, what you see is not always what you get. The layout often doesn't match expectations, especially with complex elements. It's ok for simple use cases, but for professional and scalable solutions, you usually need to switch to something else!!

Yes, that's a hard issue for arbitrary/user-provided HTML pages. But with templates under your control, the context is different. Your designers do not have to trust Chrome; they can preview, tweak using print media queries, and provide robust templates that print to acceptable PDF.

The speed issue is also real, but you can scale horizontally by spawning other chromium instances (with gotenberg containers for ex). Not really efficient but it can certainly help alleviate most of the load...

Absolutely! It's all about finding the right balance between granting users complete control over the layout and restricting it to ensure specific use cases through templates. As for scaling, indeed, horizontal scaling is an option, but there's a limit to its practicality. It would be interesting to conduct a resource/time analysis over the various solutions available on the market in different situations/use cases

There are also a few good options in a lot of languages for streamlining chromium use.

In C# I'd look to use the Playwright library or perhaps even embed chromium via CerSharp if I were trying to avoid extra processes.

It seems there isn't a solution that satisfies everyone so far, indeed. With concerns about languages supported, functionalities, security, etc., there's certainly a lot of room for improvement in this space to offer a better solution!

Reply on news.ycombinator.com