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

61–70 of 106 posts

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

#61

Post by oblio »

TwoBit wrote: post #25
reedlaw wrote: post #4

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.

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.

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.

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

#62

Post by keeperofdakeys »

barbs wrote: post #8
yincrash wrote: post #2

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

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

#63

Post by frabcus »

gkya wrote: post #54

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"”?

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.

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

#64

Post by keeperofdakeys »

zobzu wrote: post #21
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.

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

I've found pdf.js to be a negative user experience on most pdfs I try to view. From what I've read, this is mainly because pdf.js directly renders to a canvas, and doesn't store decoded vector information. Other readers seem to be able to zoom instantly, even for vector graphics.

Firefox also seems to register two separate mime-types for pdf, only giving an option to use pdf.js on one of them. I've yet to dig into firefox and fix this.

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

#65

Post by teacup50 »

azakai wrote: post #14
reedlaw wrote: post #4

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…

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.

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

#66

Post by Hengjie »

comex wrote: post #16
azakai wrote: post #14

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

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.

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.

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

#67

Post by Hengjie »

e12e wrote: post #22
reedlaw wrote: post #4

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.

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

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.

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

#68

Post by orbifold »

zobzu wrote: post #21
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.

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

The speed of pdf.js on older computers is abysmal compared to native applications like okular.

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

#69

Post by Steuard »

Hengjie wrote: post #67
e12e wrote: post #22

Earlier quoted context omitted.

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

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…

Thank you for that explanation! LaTeX docs constitute the vast majority of PDFs that I view, and I've wondered for ages why PDF.js seemed to be so laggy so much of the time.

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

#70

Post by orbifold »

stuaxo wrote: post #38
e12e wrote: post #22

Earlier quoted context omitted.

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.

Pretty much any math and physics paper I tried was rendered with broken fonts and incorrect layout. It is horribly slow and renders a lot of pdfs incorrectly.
Post reply on HN