10 ms·
PDFium: Chrome’s PDF rendering engine is now open-source
- yincrash 12y agoIt'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 12y agoFoxit isn't open-source, so I don't think it would be legal to release a derivative under the BSD license (IANAL).
- awda 12y agoIt'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.
- tfinniga 12y agoRight, and probably some money changing hands.
- yincrash 12y agoI 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.
- keeperofdakeys 12y agoIt'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 12y agohttps://pdfium.googlesource.com/pdfium/+/master/fpdfsdk/include/javascript/app.h https://pdfium.googlesource.com/pdfium/+/master/fpdfsdk/incl... "Original code copyright 2014 Foxit Software Inc. http://www.foxitsoftware.com" http://www.foxitsoftware.com"
- chilledheart 12y agoWhat about this one ? https://pdfium.googlesource.com/pdfium/+/master/core/src/fxge/Microsoft%20SDK/include/GdiPlus.h https://pdfium.googlesource.com/pdfium/+/master/core/src/fxg... "/\ * * Copyright (c) 1998-2000, Microsoft Corp. All Rights Reserved. * * Module Name: * * Gdiplus.h * * Abstract: * * GDI+ Native C++ public header file * \/ "
- gcp 12y agoPart of the Windows SDK.
- chilledheart 12y agoCorrect me if I am wrong. I saw no evidence in the project showing that this file has BSD-style license.And since it is part of the windows SDK, it is nearly impossible to be BSD-style licensed. Maybe it was included from foxit's code or other codebase but it is better to be put into the thirdparties directory due to the license issue. Edited: Thanks for pointing out my misconception about Windows SDK.
- magicalist 12y agoThe SDK has a very permissive license (including redistribution), since it's obviously designed to be used, and it's convenient to developers to be able to redistribute parts of it to ease development. Agreed it is always nice to have these things in a thirdparty directory, though, but the larger Chromium project actually does appear to have all of pdfium in third_party, which helps keep that clear.
- e98cuenc 12y agoIn case the authors are lurking here, what are the main differences between this and poppler?
- chuckledog 12y agoAlso curious how it compares to mupdf?
- fithisux 12y agoAs 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.
- deleted 12y ago[deleted]
- Ologn 12y agoWhile 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/TextOutputDev.cc 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 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.
- reedlaw 12y agoThis 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 12y agoKpartsplugin 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).
- azakai 12y agoWell, 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 12y agoWell, 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.
- zobzu 12y agoi 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
- scrollaway 12y agoI 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/ https://pdfium.googlesource.com/.
- deleted 12y ago[deleted]
- crazysim 12y agoRead the description of the project. It's hosted here: https://pdfium.googlesource.com/ https://pdfium.googlesource.com/
- JBiserkov 12y agoExcept there is no description there... Not even a README. Nothing in the wiki either https://code.google.com/p/pdfium/w/list https://code.google.com/p/pdfium/w/list
- crazysim 12y agoClick on the OP's link and use your browser to find "PDFium is an open-source PDF rendering engine." Read the next line.
- deleted 12y ago[deleted]
- ksec 12y agoWhy 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 12y agoEven codeplex is better than google code. I really hope they either make the switch or improve it.
- hendzen 12y agoGoogle code is heavily used internally at Google.
- iamsalman 12y agoIt 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?
- ksec 12y agoThat 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.
- ksec 12y agoThat 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 12y agoNot everything should move to GitHub (although i prefer GitHub also)
- ksec 12y ago
- nppc 12y agoFor some one using PDF.js (which works great both on Chrome & Firefox) for my company's enterprise app - does this matter much ?
- emn13 12y agoUnlikely, given that this is native code, and pdf.js is web-app friendly js.
- ahmett 12y agoSeriously, releasing on Google Code Project Hosting instead of GitHub? Even CodePlex is better than that.
- wooptoo 12y agoI 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 12y agoChrome's PDF Viewer is a plugin. You can see it by opening chrome://plugins/.
- rushi_agrawal 12y agoIsn'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 12y agoThis 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 12y agoI'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.
- gsnedders 12y agoSumatra just uses muPDF, FWIW.
- johnx123-up 12y agoNot really true. https://news.ycombinator.com/item?id=7788074 https://news.ycombinator.com/item?id=7788074
- fithisux 12y agoI 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 12y agoI found it interesting that it seems to use Antigrain by Maxim Shemanarev in https://pdfium.googlesource.com/pdfium/+/master/core/src/fxge/agg/agg23/agg_array.h 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-shemanarev 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!
- gkya 12y agoJust 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 12y agoNot 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 12y agoSo, apparently somebody still uses Google Code.¨ edit: .... just not for the actual code.
- steipete 12y agoSadly no tests, no documentation (except the documentation from FoxIt). Not even source code documentation.
- async5 12y agoIt 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/ https://hacks.mozilla.org/2014/05/how-fast-is-pdf-js/ was published? Competition FTW!
- gue5t 12y agoIn 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?
- async5 12y agoPer https://code.google.com/p/pdfium/issues/detail?id=1 https://code.google.com/p/pdfium/issues/detail?id=1 : "Looks like the standalone build system is not yet present."
- ferongr 12y agoIt'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/ https://hacks.mozilla.org/2014/05/how-fast-is-pdf-js/
- gsnedders 12y agoAnd 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 12y agoSo it seems the SDK has the basic plumbing to make a commandline tool out of it: https://pdfium.googlesource.com/pdfium/+/master/fpdfsdk/src/fpdfview.cpp https://pdfium.googlesource.com/pdfium/+/master/fpdfsdk/src/... Anyone interested?