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

https://code.google.com/p/pdfium/

by andybons • 12 years ago

421 97 12 years ago

code.google.com

yincrash2• 12 years ago

It's really interesting to see that there are foxit employees on the list of committers. I assume that means that it was initially a fork of the foxit PDF reader?

barbs• 12 years ago

Foxit isn't open-source, so I don't think it would be legal to release a derivative under the BSD license (IANAL).

awda• 12 years ago

It's perfectly legal for Foxit to license their own software to Google to be released under the terms of the BSD license. This would be with Foxit's consent, of course.

yincrash2• 12 years ago

I used the term 'initially' for a reason. My guess would be that the Chrome team used the Foxit SDK to get it out the door quickly, then over time and with Foxit guidance, replaced parts with their home grown source. That's just a guess, though.

keeperofdakeys2• 12 years ago

It's important to understand that a license isn't on the code itself, but merely on a copy of the code. A copyright owner reserves full rights to whatever the hell they want to do with their code; open-source projects just release a version with a specific set of restrictions. It gets more interesting with contributors, and specifying a license for the contributed code.

hidamon• 12 years ago

https://pdfium.googlesource.com/pdfium/+/master/fpdfsdk/incl...

chilledheart2• 12 years ago

What about this one ?

https://pdfium.googlesource.com/pdfium/+/master/core/src/fxg...

e98cuenc• 12 years ago

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

chuckledog• 12 years ago

Also curious how it compares to mupdf?

fithisux2• 12 years ago

As a developer I see it posing many problems since it is in C++. Mupdfs is in C and plays nice with many languages. Even golang.

Ologn• 12 years ago

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 yourself if it follows "Code Complete" type suggestions.

One reason I looked in that file is poppler does not deal well at all with many map PDFs like http://web.mta.info/nyct/maps/busqns.pdf or some others I have on my hard drive. They take forever to load.

Some PDFs have caused the applications using poppler to crash, although some of those have been patched. It's not as bad as it used to be, but still. My patch to speed up the bus map PDFs was not accepted. Then there are features like being able to enter data into PDFs and such. Compare and contrast Adobe's official Acrobat app for Linux and a PDF reader based on poppler like evince.

So the answer is a standard one - code architecture, bugs and features. The answer would be to take the PDFs that Adobe Acrobat handles but which poppler doesn't in terms of bugs and features, and see how pdfium handles them.

Of course, it's possible pdfium will handle those but fail on an entirely different class of PDFs and their pdfium specific bugs.

The PDF standard is a fairly large one. What features does pdfium handle which poppler doesn't? What percentages of PDFs crash the viewing application, or don't render correctly compared to poppler? And so forth.

I should also add that poppler usually depends on cairo for vector graphics. So once in a while the fail for a pdf is on cairo, not poppler. I have seen some of those fixed, some not.

frik• 12 years ago

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.

lvillani• 12 years ago

For us, that would be the license. BSD is far more palatable than GPL (LGPL would be fine) when we have to embed a PDF viewer in a client's project.

reedlaw• 12 years ago

This is good news because it renders PDFs a lot faster and better than pdf.js that Firefox uses. Also, I would have to install this binary blob to get Chromium to render PDFs. It seems Chromium could easily adopt this, but I'm not sure about Firefox.

shmerl• 12 years ago

Kpartsplugin with Okular also render PDFs faster in Firefox than pdf.js. I'd expect that all native plugins should be faster (if they are well written).

azakai2• 12 years ago

Well, it wouldn't make sense for Firefox to adopt this:

1. It is tied to v8 (PDFs can run JS, this PDF viewer uses v8 do so - see CJS_Context::RunScript etc), so it would mean bundling 2 JS engines, with all the security downsides of that.

2. This is written in C++. You can sandbox C++ in various ways, but that would still increase the surface area of the browser, compared to pdf.js which only uses things normal web content would use.

3. pdf.js is not just meant to render pdfs, it's also a useful project to push forward the web platform. Areas where pdf.js was slow turned out to be things that were worth optimizing anyhow. This doesn't benefit people viewing pdfs directly, of course, but it's still an interesting aspect of the project.

comex• 12 years ago

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.

ksec4• 12 years ago

Then I would rather I have the choose of using PDF with this and Javascript disabled.

May be Opera should adopt this.

yarrel• 12 years ago

4. It's not proprietary and doesn't restrict people's ability to freely use their web browser.

pjmlp2• 12 years ago

Yeah, but with Chrome reading PDFs is almost like seeing a normal web page, whereas with pdf.js my i7 jumps to 100% CPU usage.

In any case, I use a native viewer, which provides the best overall user experience.

v413• 12 years ago

How about converting this viewer through Emscripten using asm.js. Would be interesting to see performance comparison with pdf.js :)

teacup50• 12 years ago

Your arguments aren't supported by the facts:

1. It's not tied to V8.

It uses V8 currently, but:

- The vast majority of the code has nothing to do with JS.

- Almost all of the JS-related PDF code is independent of V8.

- The use of V8 is abstracted out sufficiently via IFXJS_Runtime etc that with a bit more work, a different JS runtime could be easily integrated.

2. You note that C/C++ can be sandboxed, but then claim that it "still increases the surface area of the browser".

This is nonsense: Firefox's 11 million lines of code are also written in C/C++, and should be sandboxed. You don't increase the surface area by also sandboxing the PDF plugin -- either the sandboxing mechanism works or it doesn't.

3. If anything, pdf.js's continued poor performance and operation demonstrates why forcing everyone to operate inside of a JS runtime is incredibly harmful to the web platform's progress.

e12e• 12 years ago

I don't really mind pdfjs being slow (it's not really slow enough that I've noticed) -- but it has some serious issues with printing/fonts (not sure quite which) -- even for "simple" pdfs from latex source (your typical paper or math homework) I've had to print from Adobe Acrobat (and, I think evince is also better -- but it's been a long while since I've printed from Linux -- for entirely unrelated reasons).

stuaxo• 12 years ago

I think they are pretty open to adding bad pdfs to their test suite if you have any.

Hengjie3• 12 years ago

Latex documents are typically slow on PDFjs because it positions characters individually. I think it's because Latex has some specific formatting that the PDF spec/apps can't handle well enough. So for text selection PDFjs wraps each character with it's own absolutely positioned element. The massive number of DOM elements cause browsers to slow down to 5-6fps.

I've been working on coalescing the elements and you can see the fruits of my labour by dropping a PDF into https://web.notablepdf.com which is an annotation app based on PDF.js.

TwoBit• 12 years ago

99% of the PDFs I read work fine with the pdf.js reader, and I feel a bit more safe using it than a binary reader.

oblio• 12 years ago

Agreed. pdf.js has come quite a long way from its beta.

In most situations I don't feel the need for a native reader, anymore.

scrollaway• 12 years ago

I thought Chromium's PDF engine was based on Foxit; did they change that?

EDIT: I see there are Foxit employees in the commit list. Well, that explains that!

Anyway this is great news. Kudos Google.

By the way, for those confused, the source is not on svn like Google Code fails to communicate but on https://pdfium.googlesource.com/.

ksec4• 12 years ago

Why did they close down something like Google Reader and Not Google Code Hosting? Do anyone actually use it?

I wish they could either make Google Code decent or simply kill it and use GitHub instead.

Is this a new implementation? Of did Foxit release it as Open Source?

gosukiwi• 12 years ago

Even codeplex is better than google code. I really hope they either make the switch or improve it.

hendzen• 12 years ago

Google code is heavily used internally at Google.

iamsalman• 12 years ago

It shows that the original code was Foxit's so would that mean that Foxit released the code or did Google purchase code rights and then decided to open source? Anyways, why would they host it on Google code?

ksec4• 12 years ago

That is the point. If Foxit opened it up then they deserve some credit. Otherwise the web is going to publish this as another Google PR without acknowledging their work.

NicoJuicy• 12 years ago

Not everything should move to GitHub (although i prefer GitHub also)

ksec4• 12 years ago

I know. I dont want everything to be in GitHub either. It could even be BitBucket. The point is Google Code is so terrible that i refuse to even look at it for more then a minutes.

gkya2• 12 years ago

What's wrong with Google Code? I'm not telling that it is decent in any way, but it is usable. The repository hosting is there, the wiki is there, some sort of issue-tracking is there. And, if I were a Google employee, I'd rather use my companies code hosting than some others, because what if those lot get interested in founding a tea-shop?

nppc• 12 years ago

For some one using PDF.js (which works great both on Chrome & Firefox) for my company's enterprise app - does this matter much ?

emn133• 12 years ago

Unlikely, given that this is native code, and pdf.js is web-app friendly js.

ahmett• 12 years ago

Seriously, releasing on Google Code Project Hosting instead of GitHub? Even CodePlex is better than that.

prima-facie• 12 years ago

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.

dchest• 12 years ago

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

rushi_agrawal• 12 years ago

Isn't it annoying to see code.google.com as the medium of sharing code? I've got so used to Github that google code seems like an old 20th century thing..

zx2c4• 12 years ago

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.

TillE• 12 years ago

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.

gsnedders3• 12 years ago

Sumatra just uses muPDF, FWIW.

fithisux2• 12 years ago

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.

atesti• 12 years ago

I found it interesting that it seems to use Antigrain by Maxim Shemanarev in https://pdfium.googlesource.com/pdfium/+/master/core/src/fxg... (Chrome uses Skia). Unfortunately the author of Antigrain died: http://beta.slashdot.org/submission/3154635/rip-maxim-sheman... It's nice to see the fascinating Antigrain code to be used for PDF viewing every day!

dman• 12 years ago

Did not know about this. As an agg user this made me sad.

hrjet• 12 years ago

Nice to hear that AGG lives on. I remember exploring it in around 2002 and being mighty impressed with it.

gkya2• 12 years ago

Just glanced the source code, and, isn't it bad to “#include "../../../sth.h"”? Wouldn't it be better to set the include path while compiling and just “#include "sth.h"”?

frabcus• 12 years ago

Not really, having an explicit path seems more useful and clearer to me. Easier to read the code and find the file. Things like "gf" in vim will definitely work on it to open it up too.

runn1ng• 12 years ago

So, apparently somebody still uses Google Code.¨

edit: .... just not for the actual code.

steipete• 12 years ago

Sadly no tests, no documentation (except the documentation from FoxIt). Not even source code documentation.

async53• 12 years ago

It looks like they did it in a hurry (on the next day) just after https://hacks.mozilla.org/2014/05/how-fast-is-pdf-js/ was published? Competition FTW!

gue5t• 12 years ago

In typical corporate code-dump style, no README and no clear instructions on how to build or what form the output takes. I installed gyp to try it and get a variety of errors depending on what I try (the furthest I got was complaints about v8.gyp being missing; does this have to build within the Chromium source tree?). Does any Google insider want to explain their internal build practices so a mere mortal can try to compile this code?

async53• 12 years ago

Per https://code.google.com/p/pdfium/issues/detail?id=1 : "Looks like the standalone build system is not yet present."

ferongr• 12 years ago

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/

gsnedders3• 12 years ago

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.

MrBuddyCasino• 12 years ago

So it seems the SDK has the basic plumbing to make a commandline tool out of it: https://pdfium.googlesource.com/pdfium/+/master/fpdfsdk/src/...

Anyone interested?

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

Related Stories