11–20 of 106 posts
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?
Foxit isn't open-source, so I don't think it would be legal to release a derivative under the BSD license (IANAL).
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?
Foxit isn't open-source, so I don't think it would be legal to release a derivative under the BSD license (IANAL).
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.
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.
In case the authors are lurking here, what are the main differences between this and poppler?
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.
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…
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.
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?
"Original code copyright 2014 Foxit Software Inc. http://www.foxitsoftware.com"
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?
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.
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…
May be Opera should adopt this.
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?