Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

51–60 of 191 posts

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

#51

Post by ak217 »

timvdalen wrote: post #49
ak217 wrote: 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…

(How) does it handle CMYK and print PDFs? I see images of printed books created by Paged.js, were these post-processed, or printed using a printer that does a best-effort RGB conversion?

I'm not sure - we don't do color correction on our PDFs because we don't have photos in them and color rendering is not mission critical - but paged.js is focused on the concern of layout for print media. I would imagine color rendering can be solved orthogonally to what paged.js does for you, as long as you specify the color data in CSS. I'm pretty sure paged.js will pass it through without messing with it, so you're good if the browser that Playwright/puppeteer is driving supports the correct color profile when emitting the PDF. I honestly don't know if browsers have sufficient support for that when emitting a PDF, though.

Overall you're right that color correction is another area where you could probably command a premium.

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

#52

Post by Titou325 »

breadwinner wrote: post #50

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 :)

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

#54

Post by calvinmorrison »

nradov wrote: post #31
ramon156 wrote: post #17

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/

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.

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

#55

Post by rapatel0 »

ramon156 wrote: post #17

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

PDF is an incredibly (stupidly) extensible format. There are tons of government forms that (sadly) bake in complex workflows into PDF forms.

Given that the whole world has been running on PDFs for decades it's makes more sense to leverage the existing infrastructure and move it towards something more functional over time. Introducing a new format will just lead to another format the achieves 0.5% marketshare and then is abandoned after a few years. Microsoft basically forcing people to use XPS in windows (>70% market share of computing) still wasn't able to achieve meaningful usage or change.

I expect that PDFs will not go away for 20 years at least, but who knows

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

#56

Post by _puk »

breadwinner wrote: post #50

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

"you can already build such a system yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem."

https://news.ycombinator.com/item?id=8863

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

#57

Post by devsda »

nvr219 wrote: post #27
ramon156 wrote: post #17

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

Yeah let's give XPS another go.

Giving credit where it's due, I can appreciate Microsoft for introducing XPS as an alternative to pdf.

There was a time, when not every software had "export to pdf". So, having a "print to pdf" meant installing (often pirated) Adobe Acrobat or installing a sketchy free(ware) printdriver software downloaded from sourceforge.

MS adding xps print driver to windows enabled sharing docs consistently (within windows ecosystem) without resorting to hacks.

I don't know why it didn't catch up. May be it was the general mistrust of anything MS, it arrived too late or it was something else.

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

#60

Post by AugusteLef »

snadal wrote: post #8
Brajeshwar wrote: post #2

May be this is just me but this looks extremely costly to me! It will cost $2,500 to generate 50,000 PDFs. Are edits/corrections additional cost?

I second this. Maybe I'm missing something in the value proposition, but we already generate PDFs from .docx/.html templates using open source libraries and Docker microservices. Do not misunderstand. A Stripe for generating PDFs can be great, but for a small team, $0.50/PDF is way more than I can afford (after all, you can create a small number of PDFs without too much fuss). Maybe you are oriented towards large com…

Indeed, and as you mentioned, open-source libraries are always an option. It's worth noting that our open-source library assists in document design, allowing freedom in renderer choice. While the open-source library is aimed at individuals, our API targets businesses of any size. Our pricing can be as low as $0.05 per PDF for high-volume or annual commitments. Additionally, we offer cloud hosting for your documents for up to 90 days, and our pricing includes analytics.
Post reply on HN