5 ms·

Your approach to sandboxing browser PDF rendering is to just not do it..? You realize this particular problem requires JS to solve, right? It's not just there

Your approach to sandboxing browser PDF rendering is to just not do it..? You realize this particular problem requires JS to solve, right? It's not just there arbitrarily. That's like saying your approach to web application hardening is to disable all inbound connections. You quite necessarily need those for a web application. I can't see how this would be pragmatic or productive, or maybe it's not meant to be.

amluto 2y ago
> You realize this particular problem requires JS to solve, right? It's not just there arbitrarily. Most of the time, you get better results by just serving up the PDF as Content-Disposition: inline. 90% of JavaScript PDF viewers are crap (although PDF.js is decent), but the browser on all dignified platforms still does better than any fancy JavaScript I’ve ever seen. Loads faster, too.
- deleted 2y ago
  [deleted]
- megadal 2y ago
  People don't usually use PDF.js just to render PDFs. You can also extract text to use within a web application, preview a PDF, have users sign PDFs and fill forms in the browser (where their authenticated context resides) and a host of other things. I don't think anyone but a bored hobbyist is implementing or using a JS PDF renderer solely for rendering and the people who are using it for the aforementioned reasons don't care about load times, the document has to be processed somehow by the user agent. The suggestion that JS is optional here is nonsense and that the built in browser PDF renderer (written in a lower level language than JS) is faster is common knowledge. Again, I don't see how this suggestion is pragmatic or productive, but still, maybe we're not trying to be here.
  - kevin_thibedeau 2y ago
    PDF forms don't require JS.
    - megadal 2y ago
      They do if your want to fill them out in the browser coupled with an authenticated context, which is usually pretty important for forms. Usually you don't just want random users filling out any data within your enterprise. You also can prepopulate the form with user input from previous webpages/the user account. This is how a lot of HRISes do it. Usually people want onboarding to be as frictionless as possible. Downloading the PDF and using some editor outside the website then coming back to upload it counts as friction. And this conversation is still far away from the point: you need JS for a JS based PDF renderer, and there are valid uses cases where one is required.
      - amluto 2y ago
        > They do if your want to fill them out in the browser coupled with an authenticated context, which is usually pretty important for forms. Usually you don't just want random users filling out any data within your enterprise. > Usually people want onboarding to be as frictionless as possible. Downloading the PDF and using some editor outside the website then coming back to upload it counts as friction. Wait, are you saying there's a workflow for which the most frictionless solution is to have the user fill out a PDF, on an authenticated website and submit the PDF in the browser? As opposed to, say, <form>? Can you elaborate?
        megadal 2y ago
        Tax documents. I'm going to discontinue this conversation though.
        amluto 2y ago
        I once had the displeasure of submitting a Form W-9 on an authenticated website. It was an unmitigated disaster involving one time codes distributed over email via a team of apparent actual people outsourced outside the US, a website, PDFs POSTed to said website, and marked-up copies of said PDFs emailed back by said outsourced team asking inane questions. And, presumably since the whole mess wasn’t actually machine-readable, the form still got entered wrong and incorrect tax forms were issued. It would have worked much better as an emailed PDF, or a simpler form. Or an ordinary non-PDF form that would generate a filled-in PDF that the user could then sign. > I'm going to discontinue this conversation though. Oh, well.
  - amluto 2y ago
    From personal experience browsing websites, especially sites that display catalogues, manuals, or specifications, a whole lot of them produce PDF content and then go out of their way to render it with JavaScript. The worst use horribly performing systems that make consuming the content miserable. Better commercial systems are a step up (Issuu is a whole company that seems to be developed around doing this). Even better ones use PDF.js. But the best ones... drumroll please... just link to the PDF as Content-Disposition: inline. If users want to save it, then they click save. And this is great -- you want your users to have the easiest time possible interacting with your marketing material. > fill forms in the browser (where their authenticated context resides) I have never, in my entire life, seen a web form implemented as a PDF where this was anything other than miserable. Use a form, thank you very much. The less SPA magic and the fewer intermediate submit buttons, the better. (Maybe, if the actual goal is for a user to fill out a form and print the result, offer PDF.js to users on Windows who might otherwise be stuck with Acrobat. I distinctly remember Acrobat being the best PDF-form-filling software maybe 20 years ago, but Acrobat has gotten, if anything, worse, and basically every other package out there runs circles around it.)
- bguebert 2y ago
  I mean firefox's built in pdf reader is PDF.js. Also the desktop version of adobe reader used to run javascript embedded in pdfs by default as a "feature". I'm not sure you can get away from it at this point, but it would be nice to have the option to just use a desktop pdf reader that doesn't even support javascript or running any code embedded in the pdf. Maybe my use case is limited but I don't see the point of it. If you want interactivity you can use a website so people can expect that sort of stuff.

amluto 2y ago

> You realize this particular problem requires JS to solve, right? It's not just there arbitrarily. Most of the time, you get better results by just serving up the PDF as Content-Disposition: inline. 90% of JavaScript PDF viewers are crap (although PDF.js is decent), but the browser on all dignified platforms still does better than any fancy JavaScript I’ve ever seen. Loads faster, too.

deleted 2y ago
[deleted]
megadal 2y ago
People don't usually use PDF.js just to render PDFs. You can also extract text to use within a web application, preview a PDF, have users sign PDFs and fill forms in the browser (where their authenticated context resides) and a host of other things. I don't think anyone but a bored hobbyist is implementing or using a JS PDF renderer solely for rendering and the people who are using it for the aforementioned reasons don't care about load times, the document has to be processed somehow by the user agent. The suggestion that JS is optional here is nonsense and that the built in browser PDF renderer (written in a lower level language than JS) is faster is common knowledge. Again, I don't see how this suggestion is pragmatic or productive, but still, maybe we're not trying to be here.
- kevin_thibedeau 2y ago
  PDF forms don't require JS.
  - megadal 2y ago
    They do if your want to fill them out in the browser coupled with an authenticated context, which is usually pretty important for forms. Usually you don't just want random users filling out any data within your enterprise. You also can prepopulate the form with user input from previous webpages/the user account. This is how a lot of HRISes do it. Usually people want onboarding to be as frictionless as possible. Downloading the PDF and using some editor outside the website then coming back to upload it counts as friction. And this conversation is still far away from the point: you need JS for a JS based PDF renderer, and there are valid uses cases where one is required.
    - amluto 2y ago
      > They do if your want to fill them out in the browser coupled with an authenticated context, which is usually pretty important for forms. Usually you don't just want random users filling out any data within your enterprise. > Usually people want onboarding to be as frictionless as possible. Downloading the PDF and using some editor outside the website then coming back to upload it counts as friction. Wait, are you saying there's a workflow for which the most frictionless solution is to have the user fill out a PDF, on an authenticated website and submit the PDF in the browser? As opposed to, say, <form>? Can you elaborate?
      - megadal 2y ago
        Tax documents. I'm going to discontinue this conversation though.
        amluto 2y ago
        I once had the displeasure of submitting a Form W-9 on an authenticated website. It was an unmitigated disaster involving one time codes distributed over email via a team of apparent actual people outsourced outside the US, a website, PDFs POSTed to said website, and marked-up copies of said PDFs emailed back by said outsourced team asking inane questions. And, presumably since the whole mess wasn’t actually machine-readable, the form still got entered wrong and incorrect tax forms were issued. It would have worked much better as an emailed PDF, or a simpler form. Or an ordinary non-PDF form that would generate a filled-in PDF that the user could then sign. > I'm going to discontinue this conversation though. Oh, well.
- amluto 2y ago
  From personal experience browsing websites, especially sites that display catalogues, manuals, or specifications, a whole lot of them produce PDF content and then go out of their way to render it with JavaScript. The worst use horribly performing systems that make consuming the content miserable. Better commercial systems are a step up (Issuu is a whole company that seems to be developed around doing this). Even better ones use PDF.js. But the best ones... drumroll please... just link to the PDF as Content-Disposition: inline. If users want to save it, then they click save. And this is great -- you want your users to have the easiest time possible interacting with your marketing material. > fill forms in the browser (where their authenticated context resides) I have never, in my entire life, seen a web form implemented as a PDF where this was anything other than miserable. Use a form, thank you very much. The less SPA magic and the fewer intermediate submit buttons, the better. (Maybe, if the actual goal is for a user to fill out a form and print the result, offer PDF.js to users on Windows who might otherwise be stuck with Acrobat. I distinctly remember Acrobat being the best PDF-form-filling software maybe 20 years ago, but Acrobat has gotten, if anything, worse, and basically every other package out there runs circles around it.)
bguebert 2y ago
I mean firefox's built in pdf reader is PDF.js. Also the desktop version of adobe reader used to run javascript embedded in pdfs by default as a "feature". I'm not sure you can get away from it at this point, but it would be nice to have the option to just use a desktop pdf reader that doesn't even support javascript or running any code embedded in the pdf. Maybe my use case is limited but I don't see the point of it. If you want interactivity you can use a website so people can expect that sort of stuff.