The pricing is a little expensive. Have you heard of https://htmldocs.com/ I've been using them for a year now and it's free
Launch HN: Onedoc (YC W24) – A better way to create PDFs
121–130 of 191 posts
Re: Launch HN: Onedoc (YC W24) – A better way to create PDFs
#122First reaction - congrats guys, this is a problem I have in my own business.
Second reaction - the pricing is way over the top and the model is unusual. In your own pitch you talk about the volume of documents created every day. How does that square with per document pricing?
Re: Launch HN: Onedoc (YC W24) – A better way to create PDFs
#123FYI: the open source state of the art in this area is Playwright (the successor to Puppeteer) with Paged.js ( https://pagedjs.org/ ). I highly recommend that everyone check out and donate to paged.js, it's a fantastic project with lots to like. It certainly blows commercial alternatives like Prince XML out of the water. That forms a solid foundation that I find it hard to imagine paying for. The things where you migh…
We are currently experimenting with this approach. A good thing about paged.js is that we would be able to provide hot-reload and live preview of files without actually converting to PDF. Your second point is very interesting, seems like some kind of .assert('text').isVisible() API. We may want to dig into that further!
Or maybe some visual diffing based on expected output, based on the template/layout/theme used, since you'd want to perform this check on every pdf generated in prod (that has real, sensitive data) , not just in CI or testing mode, if you're aiming for critical docs.
Cool project btw, congrats for the launch!
Re: Launch HN: Onedoc (YC W24) – A better way to create PDFs
#124The 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!
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.
Re: Launch HN: Onedoc (YC W24) – A better way to create PDFs
#125Just out of curiosity, as I've seen a few comments also mentioning PrinceXML. Is OneDoc an API, wrapper, etc, on top of PrinceXML? Or is it a completely new rendering engine?
Thanks!
Re: Launch HN: Onedoc (YC W24) – A better way to create PDFs
#126First reaction - congrats guys, this is a problem I have in my own business. Second reaction - the pricing is way over the top and the model is unusual. In your own pitch you talk about the volume of documents created every day. How does that square with per document pricing?
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
Re: Launch HN: Onedoc (YC W24) – A better way to create PDFs
#127The 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!
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
Re: Launch HN: Onedoc (YC W24) – A better way to create PDFs
#128Just out of curiosity, as I've seen a few comments also mentioning PrinceXML. Is OneDoc an API, wrapper, etc, on top of PrinceXML? Or is it a completely new rendering engine? Thanks!
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!
Re: Launch HN: Onedoc (YC W24) – A better way to create PDFs
#129This looks really interesting! One of the main reasons we've opted to writing a more complex rending code is for speed. We're getting around 500ms for a single document, which is (last I tested) quicker than any headless chrome setup. How long does it take to render using your API? :)
Rendering time scales with the length / complexity of the document. At the moment, our self-serve API renders slower than a headless chrome setup. We are working on speeding this up as it is currently in the order of seconds.
Alright, thanks!
Re: Launch HN: Onedoc (YC W24) – A better way to create PDFs
#130The 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!
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!!