Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PDFium: Chrome’s PDF rendering engine is now open-source

code.google.com

Post reply on HN
Print view View original

91–100 of 106 posts

Re: PDFium: Chrome’s PDF rendering engine is now open-source

#91

Post by gsnedders »

ferongr wrote: post #81

It's interesting that this came, seemingly out of the blue, a little after it was made widely known (from the mozhacks article [1]) that Opera developers were working towards integrating pdf.js into their Chromium fork. [1] https://hacks.mozilla.org/2014/05/how-fast-is-pdf-js/

And Opera announced their move to the Chromium Content API and WebKit around a fortnight before Blink was announced.

And note that isn't the first time there's been Opera interest in pdf.js — I spent the majority of summer 2012 working on trying to get pdf.js running well in Presto, as was relatively well known around pdf.js contributors.

Re: PDFium: Chrome’s PDF rendering engine is now open-source

#92

Post by gsnedders »

TillE wrote: post #59
zx2c4 wrote: post #51

This is great because it is now the best open-source PDF rendering library. GhostScript, Poppler, XPdf, pdf.js -- they all sort of work alright, but are pathetic compared to FoxIt, on which this source code is based. What we now have with this source is a high performance highly compliant clean codebase of C++ PDF rendering code. Excellent news. Expect lots of future PDF innovations to be based on this.

I've had by far the best performance with Sumatra, which is open source but unfortunately Windows-only. I try Chrome's PDF reader once every few months, hoping it'll improve, but I always disable it when I see it's still disappointingly sluggish.

Sumatra just uses muPDF, FWIW.

Re: PDFium: Chrome’s PDF rendering engine is now open-source

#93

Post by dchest »

prima-facie wrote: post #35

I believe this is the source of the PPAPI plugin, and not something built into Chrome. Anyway, this is great news for Chromium, as the PDF plugin can now be shipped to distro repos.

Chrome's PDF Viewer is a plugin. You can see it by opening chrome://plugins/.

Re: PDFium: Chrome’s PDF rendering engine is now open-source

#94

Post by bla2 »

pcwalton wrote: post #74
comex wrote: post #16

Earlier quoted context omitted.

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.

> 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…

> 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.

Re: PDFium: Chrome’s PDF rendering engine is now open-source

#95

Post by chrisrohlf »

jfbastien wrote: post #83
pcwalton wrote: post #72

Earlier quoted context omitted.

> You don't increase the surface area by also sandboxing the PDF plugin -- either the sandboxing mechanism works or it doesn't. Adding more C++ to the browser certainly does increase the attack area. Sandboxes that expose enough functionality to run a modern browser engine commonly end up with holes here and there (e.g. the Pwnium vulnerabilities) and it's best to not use them as the only layer of defense; moreover,…

The DRM sandbox is yet another attack surface, isn't it? Wouldn't it make sense to use NaCl for DRM sandboxing, and then the option is open to use the same sandbox for PDF viewing, and pdf.js can still work, giving users choice. Creating yet another sandbox seems silly, and NaCl hasn't been hit by pwnium, it's only been a stepping stone to the renderer (I'll let comex dive into details here!)

NaCl is not exactly a stepping stone to the renderer. NaCl modules live outside the renderer process in a much tighter sandbox that uses control flow integrity and software fault isolation. Gaining code execution within the NaCl sandbox (easy since you can just send the user a NaCl module) does not expose the same attack surface as gaining code execution within a renderer process.

Re: PDFium: Chrome’s PDF rendering engine is now open-source

#96

Post by ehsanu1 »

garblegarble wrote: post #86
Hengjie wrote: post #66

Earlier quoted context omitted.

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?

Hengjie explains here: https://news.ycombinator.com/item?id=7783622

Re: PDFium: Chrome’s PDF rendering engine is now open-source

#97

Post by frik »

Ologn wrote: post #34
e98cuenc wrote: post #3

In case the authors are lurking here, what are the main differences between this and poppler?

While the main poppler developers, who IIRC are three guys from Spain, have made a heroic effort, poppler is really not that good. Poppler was created by ripping out code from Xpdf and making it into a library. If you look at the code, it is not really well architected. Here is a file I found a problem in - http://cgit.freedesktop.org/poppler/poppler/tree/poppler/Tex... . Take a look at that file and judge for yourse…

I compared the speed (plain text extraction) of xpdf, poppler and mupdf on 100k PDFs. mupdf is in 95% cases the fastest, then comes xpdf and then poppler (the latter two crashed on a few files). SumatraPDF viewer went from poppler-only to two engines (poppler & mupdf) to mupdf+patches. At the moment from my experience SumatraPDF has the fastest and most reliable PDF engine, that is open source. So it will be interesting how this Chrome PDF open source engine (based on Foxit?) performs outside of Chrome as standalone library/commandline tool.

Re: PDFium: Chrome’s PDF rendering engine is now open-source

#98

Post by fithisux »

zx2c4 wrote: post #51

This is great because it is now the best open-source PDF rendering library. GhostScript, Poppler, XPdf, pdf.js -- they all sort of work alright, but are pathetic compared to FoxIt, on which this source code is based. What we now have with this source is a high performance highly compliant clean codebase of C++ PDF rendering code. Excellent news. Expect lots of future PDF innovations to be based on this.

I use ghostscript consistently more than ten years. No serious issues. I use it to read/print pdfs/pss from arxiv org. Last six years I also use sumatra. Faster but I prefer mupdf reader.

Re: PDFium: Chrome’s PDF rendering engine is now open-source

#99

Post by JohnTHaller »

Jyaif wrote: post #28
zobzu wrote: post #21

Earlier quoted context omitted.

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

Think mobile.

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.

Re: PDFium: Chrome’s PDF rendering engine is now open-source

#100

Post by acdha »

pjmlp wrote: post #48
emn13 wrote: post #45

Earlier quoted context omitted.

That's really weird - I use pdf.js all the time, and suffer no such issues. In particular, I enjoy it's superior font rendering (compared to the chrome implementation). I really don't get why chrome (on windows anyhow) has fairly fuzzy fonts while rendering pdf - noticably worse than pdf.js or acrobat.

The rest of the world seems to have similar experience with mine, if you check the threads at this other HN story: https://news.ycombinator.com/item?id=7716022

A few other people on HN is not “the rest of the world”, particularly when most of the complaints either don't reproduce at all or are significantly less problematic than claimed.

It's dead certain that PDF.js has plenty of room to improve but that requires solid benchmarking, not anecdata. I would hope Mozilla is collecting telemetry data about common bottlenecks from millions of users and triaging to see which problems are core or artifacts from local system configuration, graphics drivers, etc.

Post reply on HN