Seriously, releasing on Google Code Project Hosting instead of GitHub? Even CodePlex is better than that.
PDFium: Chrome’s PDF rendering engine is now open-source
31–40 of 106 posts
Re: PDFium: Chrome’s PDF rendering engine is now open-source
#32Earlier quoted context omitted.
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…
4. It's not proprietary and doesn't restrict people's ability to freely use their web browser.
What do you mean by "proprietary"? Pdfium is BSD-licensed, and pdf.js uses the Apache 2 license; both are extremely permissive.
Re: PDFium: Chrome’s PDF rendering engine is now open-source
#33Earlier quoted context omitted.
https://pdfium.googlesource.com/pdfium/+/master/fpdfsdk/incl... "Original code copyright 2014 Foxit Software Inc. http://www.foxitsoftware.com"
What about this one ? 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 * \ / "
Part of the Windows SDK.
Re: PDFium: Chrome’s PDF rendering engine is now open-source
#34In 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 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.
Re: PDFium: Chrome’s PDF rendering engine is now open-source
#35I 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.
Re: PDFium: Chrome’s PDF rendering engine is now open-source
#36This 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.
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…
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.
Re: PDFium: Chrome’s PDF rendering engine is now open-source
#37Earlier 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 (Android) both Fx and Chrome start downloading pdfs.
Re: PDFium: Chrome’s PDF rendering engine is now open-source
#38This 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.
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).
I think they are pretty open to adding bad pdfs to their test suite if you have any.
Re: PDFium: Chrome’s PDF rendering engine is now open-source
#39[deleted]
Read the description of the project. It's hosted here: https://pdfium.googlesource.com/
Except there is no description there... Not even a README.
Nothing in the wiki either https://code.google.com/p/pdfium/w/list
Re: PDFium: Chrome’s PDF rendering engine is now open-source
#40This 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.
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…
How about converting this viewer through Emscripten using asm.js. Would be interesting to see performance comparison with pdf.js :)