Live data from Hacker News

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

github.com

111–120 of 191 posts

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

#111
post #87

Earlier quoted context omitted.

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.

You don't have to pay for message by the kilobyte. This is only true if you use an external vendor for the conversion or use a VAN for transmission: https://en.wikipedia.org/wiki/Value-added_network Source: Worked in EDI for a few years

you absoultely don't need to use a VAN, yet a LOT of people do. Even when they're not using a VAN for comms, they might pay a VAN to host their FTP. The whole thing is backasswards.

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

#112

I see that you support page breaks and headers and footers and stuff which is very cool. Is there some form of widow/orphan control when text wraps from one page to the next? How do you handle things like a large table that is longer than the length of a page?

Also, do you different paper sizes (A4 and Letter)?

[deleted]

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

#113
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.

What are you looking for in programmatic pdf filling?

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

#114

Earlier quoted context omitted.

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.

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

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

#115

The 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!

Indeed, we aim at bundling this in a way that makes it easy and obvious for enterprises to build their PDFs that way.

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

#118
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.

For programmatic filling of PDFs, have a look at DocSpring: https://docspring.com

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

#119

Does Onedoc retain any visibility into, or in any way use or reserve the right to use any content created using its API in any way? Obviously, calling an API means sending document contents to Onedoc.

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

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

#120

This looks interesting! Especially the Markdown and LaTeX components in react-print-pdf. Could be a great way to streamline technical documentation generation in codebases. Would love to see some examples of those in action.

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 !

Post reply on HN