91–100 of 125 posts
Earlier quoted context omitted.
> Office to PDF is an extremely standard need Is it really an extremely standard need or just something that appears in the bs corners of our jobs a few times a year.
Yes, if you're working with documents a lot it is. Word docs are not portable and people don't like them because they can be changed easily, not to mention not everybody has Word. You also can't display them in inline in a browser.
dawg why can't you just make a normal program I don't want a REST API
What languages do you need support for?
Not a good usecase for an online API. To the extent that those PDFs could include sensitive information, there's a huge security/privacy headache there, with no real benefit when compared to performing these functions offline. It also seems to me a lot more expensive than alternative ways of doing the same thing.
> with no real benefit when compared to performing these functions offline Most organizations these days are developing in the cloud. I assume you don't mean "offline" but rather performing these functions yourself . I've tried, but it's a huge pain in the butt. PDFs are very quirky. Things work well 95% of the time and the 5% takes a lot of time to figure out. When trying to do this myself in an app deployed to AWS,…
By "offline", I mean "offline" w.r.t. their servers. The point is: I have some kind of an environment that I'm already using for handling the data underneath the PDFs I'm trying to produce. That environment has a given amount of attack surface area. If they hand me a program that I can run in my environment and that doesn't communicate outside that environment, I have gained additional functionality. This is additional stuff I can do that I couldn't do before, and I've achieved this without increasing the attack surface area that might lead to that data getting compromised.
If I do it the other way around, i.e. instead of them handing me a program, I am handing them my data, then the attack surface area increases. Because every attack against my pre-existing environment continues to be an attack that will compromise my data. But also: Some attacks against their environment would now also end up compromising my data. So it's worse for security.
If I have a car in a garage, and I give the key to the garage to 3 people, it's going to be more secure than if I give the key to 4 people. Because there's one less person who might lose the key and enable a robber to get in.
I don't understand the logic behind the converse idea at all. The idea seems to be: Azure/AWS/whatever is "the cloud". Therefore my data is already in "the cloud". Random company X is also in "the cloud". So I might as well send my data to company X. -- This sounds to me like the What-The-Hell Effect. Like: I've broken my diet because I ate a hamburger. Now I might as well quit the diet. No: Eating fewer hamburgers tomorrow is still better than eating more.
I also don't understand why things have to be architected that way in order to "just work". Weasyprint just works. Pandoc just works. LaTeX just works. I can put them on a computer with no network connection, and they'll happily do their job for me. They give me a lot of functionality and ask very little trust in return. That's a good thing. Whenever that's an option, that's what I'm going to do.
Earlier quoted context omitted.
We're based on PDFium, but there's a lot more going on than just that - see https://pspdfkit.com/blog/2019/contributing-to-pdfium/ for an overview.
So, no compliance with printing industry standards. That's a pity.
Just 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!
Their prices may be too high, so you declined to pay. I don’t see that as predatory.
Earlier quoted context omitted.
This really does not resonate at all, and I have the scars to prove it. I used to work on a browser-based document management system, and I would have used (or at least tried) all of these APIs without hesitation. PDFs are a pain and the mish mash of poor functioning tools that exist provides a constant headache. 1) OCR'ing of a PDF is difficult. The only good service is Google, but requires that you break it into pa…
I agree many of these things are a pain. This often reflects a workflow that is approaching things from entirely the wrong direction. ("If I wanted to go there, I wouldn't start from here.") E.g. instead of trying to OCR a PDF, go back to the source document or database or whatever from which the PDF was generated. (Yes, I know that's not always an option. But it should be the first avenue to explore. We should push…
To add to that, a lot of PDFs (e.g. financial reports) are generated procedurally with ancient code that would have to be rewritten to generate a different format. The underlying database format is often many layers of abstraction different than the final output.
I find this utterly bizarre. Once upon a time, if you wanted to left pad a string, you would just do it. A while later, people discovered that you could use a library. (I’m joking a bit here, but libraries are genuinely useful.). With a library, you get to pick from various schemes and schedules for updating the library, but you have a degree of control. But now apparently you’re supposed to use a web API and depend…
Taking a quick look at https://pspdfkit.com/api/documentation/tools-and-api/ , I'm puzzled.... what distinguishes a "PDF Generator" from a "PDF Creator" from a "PDF Writer"? How would I know which one I want? Oh, looks like they're the exact same thing: a webpage-to-PDF service. Then there are a whole bunch of "PDF Converter" options, including "HTML > PDF", which seems to be yet another name for the same thing. For…
Not a good usecase for an online API. To the extent that those PDFs could include sensitive information, there's a huge security/privacy headache there, with no real benefit when compared to performing these functions offline. It also seems to me a lot more expensive than alternative ways of doing the same thing.