Live data from Hacker News

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

github.com

31–40 of 191 posts

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

#31

Can we not have an alternative to PDFs? I get that they're more standardized but why would everyone let adobe have the hammer for a file type that's so important

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/

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

#34
post #14

So are you using PrinceXML for your "completely separate engine where typography is a first-class citizen"?

Yes, we use an API layer on top of PrinceXML with additional polyfills to support modern features. This is a meh solution but it allowed us to iterate quickly and get to work with customers without building a full blown PDF engine firsthand. However building this engine ourselves is the key to reduced latency and overall better feature support. But we need to engage with our users first and see exactly where we should head first :)

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

#35
post #22

Glad to see people building in the PDF space, which as a format is unfortunately both awful and ubiquitous. Are you planning to build any support for programmatically filling out existing PDF forms? That's a huge pain point our product is facing that doesn't seem easy to solve.

Yes, our focus is on programmatic interactions with PDFs, form filling is on our roadmap, alongside programmatic digital signature and many more.

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

#37
We're using Gotenberg[1] to convert a rendered web page (with Elixir/Phoenix, in our case) to PDF. Works like a charm and we can use our existing frontend code/styling (including SVG graph generators) which is a huge bonus.

1: https://gotenberg.dev/

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

#38
post #22

Glad to see people building in the PDF space, which as a format is unfortunately both awful and ubiquitous. Are you planning to build any support for programmatically filling out existing PDF forms? That's a huge pain point our product is facing that doesn't seem easy to solve.

Yes, our focus is on programmatic interactions with PDFs, form filling is on our roadmap, alongside programmatic digital signature and many more.

Amazing, is there anywhere I can follow along to find out when form filling will be available?

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

#39
post #28

Earlier quoted context omitted.

I'm with you.. We ended up writing a similar wrapper around https://github.com/jung-kurt/gofpdf library. We haven't open sourced it yet. But it's made it a lot easier to deal with rendering a PDF, especially over pagebreaks ect.

Yes, page breaks are probably the most significant difference between the layout of a web page and a PDF document, and thereby a major drawback when using HTML-to-PDF. There is little to no tooling for this in the web. If you want granular control over how your PDF will look with content that is more than one page long, you will have a hard time using html.

We actually provide helpers to do that in our React library https://react.onedoclabs.com/components/shell#pagebreak

CSS actually implements the break-before property to control this https://developer.mozilla.org/en-US/docs/Web/CSS/break-befor... which is also supported by the Print to PDF dialog in modern browsers.

Post reply on HN