Thank you for taking the time. It really helps us define our value proposition and outline the next steps in product development. As you mentioned, the challenge isn't the inability to produce something in-house but rather other product-roadmap priorities. Our goal is to ensure that companies needing to produce many documents —where documents are necessary but not core to their business— can use our solution at a fair price and limiting the pain of creating such solution in house. OnPrem + fixed rate seems to be the best option for high volume. We'll explore this and see what future solutions we can offer to meet these needs!
Street smart! But yes, programmatic merging does get complex, especially with large document sizes. It's a balancing act between functionality and handling those technical challenges!
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!
We've updated our pricing, and it can go as low as $0.005 per document. True, you'll still need to work with a third-party vendor, but isn't it worth considering if the features are competitive and the interface is user-friendly? It would be interesting to know what might convince you to switch from Puppeteer to another solution—or if you're completely satisfied and wouldn't switch regardless of the offerings, which is perfectly fine.
We've adjusted our pricing based on your comments and advice. It's not 100% free, but it now seems to make more sense to most of you. What do you think?
We'll adjust the wording until we have a faster renderer. Also, the playground might take a bit longer to render since there's a queue and it's been heavily used! We're on it, thanks!
Exactly. We are aiming at offering a solution to build complex PDF design. Which means having 100% control over the layout (margin, header, footer), the style and also the content. That's why we integrated Tailwind, CharkraUI, Markdown, LaTeX, and also wanted to support SVG etc.
certifications (SOC2 / ISO27001) and offer an on-premise solution! I see there's already a discussion about pricing, so I'll leave that be. However, would an unlimited volume at a fixed cost (and self-host) be an attractive solution? It could be interesting for very high volumes.
Sorry for the misunderstanding, we indeed "meant something more like a viewer for Adobe's PDF format rather than Adobe's viewer for PDFs.". We will make sure to change the wording. Thank you!
True. Security is a significant concern, and in our discussions with businesses, we realised that most of them do not want any kind of data leaving their own systems. This is especially true in the biotech/healthcare industry, but also in legal and banking. That's why we're considering an on-premises solution for the future (as we're focusing on B2B). However, I assume most people were talking about personal use cases or non-sensitive documents, hence the fact that no one mentioned SSRF (yet ;)).
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 (?)
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
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!!
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
Exactly, that's one of the main reasons we began working on this. We aim to bring the modern web technologies used for website design into the document world. This includes enabling the use of React and, of course, Tailwind, Chakra UI, etc.
Makes sense. Actually, if you keep the layout/content very simple, aren't constrained by throughput, and don't need to integrate dynamic data or other similar processes, then simple FOSS could indeed get the job done! That's exactly why we developed the open-source library react-print-pdf
Editors such as Overleaf, and those offered by MS and Adobe, have been around for a long time. Recently, companies like Pandadoc and Docusign have started offering services around PDFs (generation or other aspects of their lifecycle).
It might seem odd, given our long history with PDFs, but I believe there's still much to be done with these documents. They're everywhere—invoices, tickets, reports, etc.—yet the technology for generating and managing them hasn't evolved much in years. Our approach is to apply the same modern technologies used for web design to document design.
We felt the same, and that's precisely why we built this tool! The key, as you mentioned, is fidelity, especially for designing complex layouts. We hope to bring something new and valuable to the table. And yes, documents are central to many industries including government, legal, banking etc.
Indeed, we need to give credit to MS for what they did. However, it didn't catch up as you mentioned, maybe due to timing, skepticism toward MS, or the complexity of moving from Adobe to MS for PDF management. I will dig a bit into it and come back later if I find anything interesting.
Thanks! We try to make our product as accessible as possible for anyone to use (or at least to test). It's good to hear that our efforts have been worthwhile!