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
Launch HN: Onedoc (YC W24) – A better way to create PDFs
111–120 of 191 posts
Re: Launch HN: Onedoc (YC W24) – A better way to create PDFs
#112I 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)?
Re: Launch HN: Onedoc (YC W24) – A better way to create PDFs
#113Glad 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.
Re: Launch HN: Onedoc (YC W24) – A better way to create PDFs
#114Earlier 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.
Re: Launch HN: Onedoc (YC W24) – A better way to create PDFs
#115The 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!
Re: Launch HN: Onedoc (YC W24) – A better way to create PDFs
#116Re: Launch HN: Onedoc (YC W24) – A better way to create PDFs
#117Re: Launch HN: Onedoc (YC W24) – A better way to create PDFs
#118Glad 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.
Re: Launch HN: Onedoc (YC W24) – A better way to create PDFs
#119Does 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.
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
#120This 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.
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 !