3 ms·

With superb open source, cross platform libraries like pdfium available to the public, why won't I just do this on the client?

by devxpy 7y ago

slowenough 7y ago
OK, that's a good point. I think the only reason was I looked at PDF.js and felt the quality was not so good, and then I tried ImageMagick and found it gave good quality, so I just went with that. Another reason is I made this to convert the PDF (or Word doc, XLS, etc) remotely without the file ever touching the user's device. So they couldn't be exposed to any exploits contained in the file or of the PDF engine (PDFium recently caused a Chrome 0 day I think).
- mirimir 7y ago
  That's a great point. I typically don't like using remote resources for stuff that I can do locally. But for iffy pdfs, it's a good tradeoff. Edit: Nice to see the PDF capability added :)
  - slowenough 7y ago
    Thanks, I remember you commented on my first share of the remote browser thing :)
- devxpy 7y ago
  Wow, wasn't expecting such a well constructed counter argument.
  - slowenough 7y ago
    Thank you. The internet, eh? You never know what you're gonna get.
- vyuh 7y ago
  "to convert the PDF (or Word doc, XLS, etc) remotely without the file ever touching the user's device" This made me think that the site accepts a URL to a PDF/XLS/DOC file and returns PNG.
  - slowenough 7y ago
    It sounds like that makes you think the site accepts a link to a PDF/XLS/DOC and returns a PNG. Actually, that is basically what happens in the original context for this service. If you take a look at https://free.cloudbrowser.xyz https://free.cloudbrowser.xyz open a remote browser, then search for a PDF/XLS/DOC etc and then click on it, you'll see a dialog which says the file is transferred. What's happening is the remote browser downloads the file to a temp directory in the cloud, then some software does a POST request with that file to the service (Simple PDF to PNG Server) and gets the viewing link back immediately, before the conversion has completed. It then sends the viewing link back to the remote browser which opens a tab. The client can then view the document as images securely without the file ever touching their device. Originally, I didn't intend to release this viewer as a separate thing/product/service. If you use the viewer (without the remote browser) you do have to submit the file. I didn't make it to fetch them. I made it as a "secure document viewer" for the remote browser product.
redman25 7y ago
I used PDF.js in a side project for comparing pdfs and it worked quite well. It runs completely client side, so I can build the site with a static site generator and html: https://www.parepdf.com/ https://www.parepdf.com/ It can start to bog down with large image heavy pdfs. But overall it runs performantly.

With superb open source, cross platform libraries like pdfium available to the public, why won't I just do this on the client?

by devxpy 7y ago

With superb open source, cross platform libraries like pdfium available to the public, why won't I just do this on the client?

slowenough 7y ago

OK, that's a good point. I think the only reason was I looked at PDF.js and felt the quality was not so good, and then I tried ImageMagick and found it gave good quality, so I just went with that. Another reason is I made this to convert the PDF (or Word doc, XLS, etc) remotely without the file ever touching the user's device. So they couldn't be exposed to any exploits contained in the file or of the PDF engine (PDFium recently caused a Chrome 0 day I think).

mirimir 7y ago
That's a great point. I typically don't like using remote resources for stuff that I can do locally. But for iffy pdfs, it's a good tradeoff. Edit: Nice to see the PDF capability added :)
- slowenough 7y ago
  Thanks, I remember you commented on my first share of the remote browser thing :)
devxpy 7y ago
Wow, wasn't expecting such a well constructed counter argument.
- slowenough 7y ago
  Thank you. The internet, eh? You never know what you're gonna get.
vyuh 7y ago
"to convert the PDF (or Word doc, XLS, etc) remotely without the file ever touching the user's device" This made me think that the site accepts a URL to a PDF/XLS/DOC file and returns PNG.
- slowenough 7y ago
  It sounds like that makes you think the site accepts a link to a PDF/XLS/DOC and returns a PNG. Actually, that is basically what happens in the original context for this service. If you take a look at https://free.cloudbrowser.xyz https://free.cloudbrowser.xyz open a remote browser, then search for a PDF/XLS/DOC etc and then click on it, you'll see a dialog which says the file is transferred. What's happening is the remote browser downloads the file to a temp directory in the cloud, then some software does a POST request with that file to the service (Simple PDF to PNG Server) and gets the viewing link back immediately, before the conversion has completed. It then sends the viewing link back to the remote browser which opens a tab. The client can then view the document as images securely without the file ever touching their device. Originally, I didn't intend to release this viewer as a separate thing/product/service. If you use the viewer (without the remote browser) you do have to submit the file. I didn't make it to fetch them. I made it as a "secure document viewer" for the remote browser product.

redman25 7y ago

I used PDF.js in a side project for comparing pdfs and it worked quite well. It runs completely client side, so I can build the site with a static site generator and html: https://www.parepdf.com/ https://www.parepdf.com/ It can start to bog down with large image heavy pdfs. But overall it runs performantly.