Skip to content

Comment on PDFium: Chrome’s PDF rendering engine is now open-sourceparent

Comments

Well, Chrome could make this viewer not increase the surface area of the browser just by changing it to a NaCl plugin. After all, it already exposes the ability to run native code inside NaCl to the web. ;p

I like the concept of pdf.js, but it's still significantly slower, and thus provides a worse experience to the user, than native viewers.

A large part of why PDF.js is slow is because it doesn't have text coalescing. http://www.NotablePDF.com/ is based on PDF.js and has a coalescing code in production which has improved performance substantially.

It's been a significant effort on our part, and we'll be contributing it back to the PDFjs code base. Opera also has a similar coalescing effort underway by Christian Krebs.

Would you mind explaining what text coalescing is in this context?

Well, Chrome could make this viewer not increase the surface area of the browser just by changing it to a NaCl plugin. After all, it already exposes the ability to run native code inside NaCl to the web. ;p

Will V8 run inside NaCl? As I understand it, the NaCl JIT functionality is pretty slow for use cases like polymorphic inline caching.

I like the concept of pdf.js, but it's still significantly slower, and thus provides a worse experience to the user, than native viewers.

Most of the issues in pdf.js are actually rendering-related, not JavaScript-related—that is, they wouldn't be fixed just by changing the language to native code.

Will V8 run inside NaCl? As I understand it, the NaCl JIT functionality is pretty slow for use cases like polymorphic inline caching.

Would that matter for PDFs? I thought js in PDFs is mostly used for form validation, which isn't very compute-heavy.

i dont know, on recent computers, more often than not i dont really see a diff between pdf.js and others as a user.

it seems to only be an issue on really heavy pdfs, which are pretty rare

I've found pdf.js to be a negative user experience on most pdfs I try to view. From what I've read, this is mainly because pdf.js directly renders to a canvas, and doesn't store decoded vector information. Other readers seem to be able to zoom instantly, even for vector graphics.

Firefox also seems to register two separate mime-types for pdf, only giving an option to use pdf.js on one of them. I've yet to dig into firefox and fix this.

The speed of pdf.js on older computers is abysmal compared to native applications like okular.

Think mobile.

On mobile (Android) both Fx and Chrome start downloading pdfs.

On mobile, both Firefox and Chrome download PDFs to be rendered by another app on Android. I'm unsure about Chrome on iOS. There is no Firefox for iOS because Apple.

Well, Chrome could make this viewer not increase the surface area of the browser just by changing it to a NaCl plugin. After all, it already exposes the ability to run native code inside NaCl to the web. ;p

AIUI from the NaCl guys, it already does.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.