From the ‘JavaScript is Mother, JavaScript is Father’ files:
Is there anything that JavaScript can’t do?
The new Mozilla sponsored pdf.js effort is all about using JavaScript as a the mechanism by which a PDF file is rendered and displayed in the browser.
That’s right no separate Adobe plugin and no Google secret-sauce non-open stuff either.
Well eventually it will work…currently the project is at its 0.2 release and it’s still not quite ready for prime time. As it turns out there is a whole lot of complexity in dealing with different operating systems when it comes to rendering fonts for PDF.
“pdf.js produces different results on pretty much every element in the browser×OS matrix,” pdf.js developers wrote in a blog post. “We said above that pdf.js renders the Tracemonkey paper “perfectly” … if you’re running a Firefox nightly. On a Windows 7 machine where Firefox can use Direct2D and DirectWrite. If you ignore what appears to be a bug in DirectWrite’s font hinting.”
The day will come, thanks to the work of Mozilla developers when PDF will just be, yet another element that a browser handles as part of its core functionality. That’s a good thing.
It will mean that anything that can interact with JavaScript, can interact with the pdf to create all sorts of open inline web experiences. The same JavaScript same origin, XSS, CSRF, clickjacking type policy then *should* and could also apply to PDFs which might just help to further mitigate the risks that PDFs (lately) tend to pose.