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

We do not work with docx and never did it myself but: "DOCX Template API is a tool that allows you to dynamically generate MS Word documents by replacing custom properties using a JSON object that contains your data." I assume this is more or less similar to what you are looking for (?)

Yes - sadly the pricing and docs aren’t the most competitive or intuitive. Hoping someone in the thread has experience with alternatives. Very best of luck with your launch

Thanks for the tip, I will take a look at it asap

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

As of today we are building our solution on top of PrinceXML/DocRaptor which is considered "to be the best PDF generation API, giving complete control over the documents you need to create" (cf. another comment). As we started working on this solution less than 2 months ago, building our own renderer was not an option. But once we have validated the idea, we are definitely going to work on our own renderer to have 100% control over the workflow, and also to be able to offer a better pricing model!

Thanks! We're fine-tuning our pricing model and realize we have some work to do in this area hahaha! Indeed, at a certain scale, per-document pricing becomes almost impossible (we're talking about millions of documents generated daily). As noted in another comment, costs vary significantly depending on the PDF type, from simple receipts to large multi-page reports, especially since we currently rely on other proprietary software that incurs high costs. In the future, we aim to offer more than just document generation (like e-signature, analytics, hosting, editor, etc.) and hope to move away from "per document" pricing for high volumes. That said, our open-source library allows anyone to design a document and use their preferred renderer for PDF conversion, with all the pros and cons each solution provides. There are more comments about pricing providing additional information; feel free to dive in if you have any comments or questions

Indeed it could be a very interesting use case. While we are more "Selling Shovels" it could be interesting to explore this use case and maybe build a simple demo out of it!

And yes, as a big fan of LaTeX myself (I used to do all my research reports on overleaf), we wanted to be able to integrate formulas, code and more into your document very simply. Glad you like it !

We do not. We are also working on getting SOC2 compliant as soon as possible. More about security here: https://docs.onedoclabs.com/ressources/security (especially how we use temporary buckets). Also, you can chose rather to host you generated documents on our platform or to store it on your local system.

But indeed, calling an API means sending documents contents to Onedoc in a way or another. We aim to provide a self-hosted solution in the future to solve this issue

As mentioned in another comment, "Onedoc generates tagged PDFs as long as you add a `title` property to the API call to make the PDF UA/1 compliant."! Hope it helps

We spent many hours designing and generating PDFs at our previous venture.. terrible experience. Which is why we're now focused on solving this issue!