Earlier quoted context omitted.
Thanks! This is Claudio, PSPDFKit's CTO. At this point in time the price is per generated document - irrespectively of how complicated the operation is. Because you can combine operations in one http call, you're incentivised to do that as opposed to perform separate calls which increase the possibility of errors and cost for all sides. Happily taking feedback though - your comment around hard-cap is definitely sound…
> At this point in time the price is per generated document - irrespectively of how complicated the operation is. As part of an integration for a few customers we do relatively simple PDF operations. Combining a few TIFFs into a PDF, or splitting a PDF into separate PDF per page for example. Think invoices vs orders. Can be a royal PITA though due to edge cases in terms of whatever generated the TIFFs or PDFs. Howeve…
Show HN: PDF API – Generate, convert, and modify PDF documents
51–60 of 125 posts
Re: Show HN: PDF API – Generate, convert, and modify PDF documents
#52How well does this handle large tables that span pages? That seems to be a key differentiator for most PDF libs I sampled. I'd assume this works well if it's coming from Chromium
Re: Show HN: PDF API – Generate, convert, and modify PDF documents
#53How well does this handle large tables that span pages? That seems to be a key differentiator for most PDF libs I sampled. I'd assume this works well if it's coming from Chromium
Re: Show HN: PDF API – Generate, convert, and modify PDF documents
#54dawg why can't you just make a normal program I don't want a REST API
Re: Show HN: PDF API – Generate, convert, and modify PDF documents
#55Re: Show HN: PDF API – Generate, convert, and modify PDF documents
#56Earlier quoted context omitted.
That's a great point. For folks that have strong privacy needs, we do have an on-premise product that provides the same functionality [1]. [1] https://pspdfkit.com/server/processor/
So what exactly does that leave? A wrapper that you've created around weasyprint, pandoc, latex, ghostscript, imagemagick, and stuff like that? Sounds to me like an unnecessary extra expense for an unnecessary extra layer of abstraction. And there's a risk factor that comes with it: Say I make a nontrivial investment, like write a book that I'm planning on typesetting with this, or write a reporting infrastructure th…
- We do build on top OSS (just not those programs you listed - see https://pspdfkit.com/legal/acknowledgements/processor-acknow... for a complete list). The layer we build is quite large though, and it would take many person-years to replicate in its entirety. It’s possible though that you don’t need that at all and a focused program that wraps other ones might do the trick for your use case.
- If you build a product based on our tech, you’re taking a conscious decision about risk: while I do think we’re gonna be in business in 10 years (we have solid revenue and last year we got backed by a large investor, Insight), that we would version APIs and support you (not just during upgrades), the reality is that it is indeed possible that we’re not gonna be around anymore, like every other company on the planet. As a consumer, this is the reality for most of the things we buy nowadays. We do take deprecation seriously, as sell SDKs, and I’m sure in case of the company shutting down you would have enough time to migrate.
- Depending on what you need to build, using our product may shortcut your development time by a large factor. It may not, if you just need to rotate pages of a PDF document and there’s a reliable OSS package that does that in your language of choice. It really depends on what you need to do.
- Even if you package everything with OSS, waiting 10 years is a sufficiently large amount of time that it may not work and you have to fork and rebuild yourself. It’s a different type of risk, but still a risk. 10 years ago Docker had just been launched. Whether you build something on OSS or commercial, you would wanna test things once a year to see if they still work or keep up with security and bug fixes.
Ultimately, there are situations where the approach you described is sound: for example, I do my taxes in plain text accounting, using ledger and emacs. I generate the reporting via a couple of Ruby scripts. I do that exactly because I care about longevity: I do my taxes once a year, I don’t wanna spend time fixing the toolchain every time I have to do them. Yet every year I hit a couple of snags I have to fix, but I consider that acceptable.
Re: Show HN: PDF API – Generate, convert, and modify PDF documents
#57Just an FYI but PSPDFKit has a very predatory sales model. Our organization received pricing that was generally very high and we pushed back on it because we were a startup and it was outside of our budget. I've connected with several other customers of PSPDFKit over the years and they almost all have much more reasonable pricing. Beware!
I experienced the same. We ended up developing our own solution and no longer have to rely on any 3rd party framework.
Re: Show HN: PDF API – Generate, convert, and modify PDF documents
#58Earlier quoted context omitted.
For higher volume, but simpler operations (merge, watermark, encrypt/decrypt, etc.) you can try https://www.pdfblocks.com/api . You get 10K docs processed for $29/mo, and 1M for $99/mo. We don't have conversion, OCR, generation, or chained operations though. Source: I work at PDF Blocks
Is it appropriate to have multiple competitors pitch their own products in an Ask HN? this should not be such an opportunity
Also, it’s a Show HN.
Seems reasonable to share alternatives.
Re: Show HN: PDF API – Generate, convert, and modify PDF documents
#59Which rendering engine are you using in the backend?
The metadata on an output PDF I tested says Skia (though I guess that could be being wrapped by another library)
Re: Show HN: PDF API – Generate, convert, and modify PDF documents
#60Long story short, instead of that we spent a few two-week sprints of two-men team and were able to successfully fulfill our needs using open source software. $Company saved hundreds of thousands per year. We also tried to influence company to donate to OSS, that unfortunately never happened, but that's another story.
So please be aware of vendor lock-in and of possible price increase. Always think of a plan-b.