Live data from Hacker News

Launch HN: Onedoc (YC W24) – A better way to create PDFs

github.com

71–80 of 191 posts

Re: Launch HN: Onedoc (YC W24) – A better way to create PDFs

#71

I've also spent much longer than I'd like on this same problem. Having a lightweight-enough service to convert html->pdf on the fly, with good fidelity, and that can create an accessible pdf seems to be impossible. If you can nail accessible PDFs then you'd open up a very big government market.

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.

Re: Launch HN: Onedoc (YC W24) – A better way to create PDFs

#72
post #31

Earlier quoted context omitted.

For supply chain workflows the ASC X12 Electronic Data Interchange (EDI) industry standard works much better than PDFs. Unfortunately, despite being around for decades in has only been adopted by forward thinking organizations such as Walmart. Most smaller companies and their vendors still haven't implemented EDI. https://developer.walmart.com/home/us-edi/

Insanity. EDI is the only place where people are regularly still paying for message by the kilobyte, where unsecured FTP over the open internet is still a norm, and where entire cottage industries exist to support AVOIDING using EDI. Source: I work in EDI. it's a pain in the rump. Also, EDI is really only good for things like PO's, shipping notices, invoices, sales orders, etc.

> Also, EDI is really only good for things like PO's, shipping notices, invoices, sales orders, etc.

Don't forget health insurance claims, eligibility & benefits, and prior auth requests!

Re: Launch HN: Onedoc (YC W24) – A better way to create PDFs

#74

I've also spent much longer than I'd like on this same problem. Having a lightweight-enough service to convert html->pdf on the fly, with good fidelity, and that can create an accessible pdf seems to be impossible. If you can nail accessible PDFs then you'd open up a very big government market.

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.

Can you directly answer whether your tool generates tagged PDFs?

Of course, you can't guarantee that the resulting document is 100% compliant because you can't enforce that the input is valid, but are you at least outputting a complete tag tree with as much semantics as possible given the input?

Re: Launch HN: Onedoc (YC W24) – A better way to create PDFs

#75
post #42

FYI: 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…

I think https://github.com/diegomura/react-pdf is closer to what this company is doing.

In fact their open source library, https://github.com/OnedocLabs/react-print-pdf, seems like a higher-level library that sits above react-pdf. Reminds me a lot of the set of react-pdf based components I built for a corporate job where letting users create PDFs was a huge part of the value proposition.

They're solving a really cool problem, actually, because building out into certain difficult use cases like SVG support was a huge pain.

Re: Launch HN: Onedoc (YC W24) – A better way to create PDFs

#76

Really interesting product. I do agree that the pricing seems steep ($0.25/document on Pro on the most generous tier) but I don't know enough about pricing B2B products to know if that would be a blocker. I agree that HTML -> PDF can be a really powerful tool. I worked on the UK government's tool to generate energy efficiency labels for consumer goods [0] and we ended up doing PDF generation with SVG templates, using…

The pricing does go down for larger volumes and is something we still have to narrow down to the exact place that makes sense to companies and is also viable. - We do not force PDF/* profiles down to the user, but it seems that for most of them PDF/UA-1 would be a sensible default. We can extract most of the tags from the HTML semantics by themselves which makes it much easier. - We target the PDF 1.7 spec. Color pro…

So are you saying that you don't output tagged PDFs now?

For those who don't know, if you use Chromium's print-to-pdf feature you get a tagged PDF. And it's scriptable from the command-line too.

Re: Launch HN: Onedoc (YC W24) – A better way to create PDFs

#77
Hmm interesting... I just went through this user experience on iOS generating PDF invoices locally. I attempted the HTML > PDF route, but Webkit is thorny wrt to layouts (as you mentioned). I did settle in with drawing everything from the ground up > which with LLMs wasn't as hairy as it used to be, even got a little Swift framework out of the deal.

Am I understanding the docs correctly that you don't have a local library available (the SDKs are just calling the APIs right?)? Mind going through why you chose a remote API?

Re: Launch HN: Onedoc (YC W24) – A better way to create PDFs

#78

How is this better than writing out an HTML file, then using headless chrome to export to PDF, like this: "C:\Program Files\Google\Chrome\Application\chrome.exe" --headless --disable-gpu --print-to-pdf=C:\temp\foo.pdf --no-margins --print-to-pdf-no-header C:\temp\test.mhtml

This brings its own set of challenges. Headers and footers are strictly limited in terms of features, you cannot add footnotes, the notion of page spreads is harder to implement. Then you need to combine that with having a Chrome instance at hand + exposing the needed assets for URL resolution. Definitely not difficult let alone impossible, but not the easiest way to get started :)

The easier way costs $0.05 cents per page. Imagine sending an invoice to your customer and the invoice itself costs 5 cents per page! That's prohibitively expensive for many applications. I wouldn't consider any solution that costs more than 1 cent per page.

Re: Launch HN: Onedoc (YC W24) – A better way to create PDFs

#80

Earlier quoted context omitted.

This brings its own set of challenges. Headers and footers are strictly limited in terms of features, you cannot add footnotes, the notion of page spreads is harder to implement. Then you need to combine that with having a Chrome instance at hand + exposing the needed assets for URL resolution. Definitely not difficult let alone impossible, but not the easiest way to get started :)

The easier way costs $0.05 cents per page. Imagine sending an invoice to your customer and the invoice itself costs 5 cents per page! That's prohibitively expensive for many applications. I wouldn't consider any solution that costs more than 1 cent per page.

We bill per document, so the number of pages wouldn't impact the pricing. A 5 pages invoice would come at 1 cent per page. However, it seems that each and every company has different needs and the pricing may or may not make sense for them. There are alternative billing options that we are considering but we want to keep it easy to grasp rather than go into billing kilobytes or ms of execution. We would be more than happy to discuss use cases and see what can work for each company :)
Post reply on HN