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
101–106 of 106 posts
Re: PDFium: Chrome’s PDF rendering engine is now open-source
#102Earlier quoted context omitted.
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…
Oh, that explains why I thought PDF.js is horrible across the board! If you judged the source of PDF's solely by the ones I read, you'd think every PDF in the world is either produced by LaTeX or is a restaurant menu. Are there statistics about what other sorts of PDF's people read? How else are PDF's made? I always assumed that people that use word processors would exchange files in their word processor's format, bu…
There aren't statistics that I know of. Though anecdotal evidence suggests that there's quite a lot of PDFs with this problem. There are a lot of people whom export to PDF because users then can't "edit" the file.
So far, coalescing works, but we've had to make substantial changes to a lot of places. The hard part is still ensuring it is compliant with PDF specs, which we're in the process of working through before we submit it as a patch to the PDF.js team.
Re: PDFium: Chrome’s PDF rendering engine is now open-source
#103Earlier quoted context omitted.
The DRM sandbox is yet another attack surface, isn't it? Wouldn't it make sense to use NaCl for DRM sandboxing, and then the option is open to use the same sandbox for PDF viewing, and pdf.js can still work, giving users choice. Creating yet another sandbox seems silly, and NaCl hasn't been hit by pwnium, it's only been a stepping stone to the renderer (I'll let comex dive into details here!)
Hey, side question: I assume pdfium runs in the NaCl sandbox - how does that work with v8?
Sorry, I don't check HN often. As we discussed on Twitter & IRC:
It's just an OS sandbox currently. pdfium previously worked with NaCl, with a non-V8 JS VM (work done by Bill Budge). V8-on-NaCl used to work, I think it may have bitrotted since then, but it used NaCl's dyncode modify API to do PIC. The GC moves code too, so extra page permissions need to be changed when that's done, but I think that's the extent of code modification that needs to be handled for a JS JIT to work on NaCl (on top of the sandboxing).
Re: PDFium: Chrome’s PDF rendering engine is now open-source
#104Earlier quoted context omitted.
The DRM sandbox is yet another attack surface, isn't it? Wouldn't it make sense to use NaCl for DRM sandboxing, and then the option is open to use the same sandbox for PDF viewing, and pdf.js can still work, giving users choice. Creating yet another sandbox seems silly, and NaCl hasn't been hit by pwnium, it's only been a stepping stone to the renderer (I'll let comex dive into details here!)
Well, the DRM sandbox has very few exposed APIs, in contrast to the Web sandbox or Pepper. I don't like the DRM sandbox anyhow; it's unfortunate that DRM was added to the Web, forcing a DRM module at all (speaking for myself, not my employer).
I discussed this with Alon on IRC: you wouldn't use pepper to do this. NaCl doesn't imply pepper, you can expose a subset of syscalls into the trusted code base.
I understand the feeling about DRM, but given that sandboxed DRM is going to happen I'd hope that the best efforts possible are put in to make users safe. Good sandboxing seems the right way to go. I'm not any kind of a security expert, but jschuh seems to think the current sandbox isn't sufficient: https://bugzilla.mozilla.org/show_bug.cgi?id=1011491 I hope the right improvements go into tightening the DRM sandbox :)
Re: PDFium: Chrome’s PDF rendering engine is now open-source
#105Earlier quoted context omitted.
That's really weird - I use pdf.js all the time, and suffer no such issues. In particular, I enjoy it's superior font rendering (compared to the chrome implementation). I really don't get why chrome (on windows anyhow) has fairly fuzzy fonts while rendering pdf - noticably worse than pdf.js or acrobat.
The rest of the world seems to have similar experience with mine, if you check the threads at this other HN story: https://news.ycombinator.com/item?id=7716022
If you actually read that thread, you'd notice that many people confirm that lots of pdf's render just fine, and that it's specific workloads where pdf.js lags.
Frankly, it's something I'll gladly put up with in most cases just to avoid bad font rendering - and that's exactly what I do.
BTW, I'm pretty sure that this kind of stuff if pretty platform (and GFX-driver) dependent - and e.g. FF on mac os performs less well IIRC.
Re: PDFium: Chrome’s PDF rendering engine is now open-source
#106Earlier quoted context omitted.
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.
Sumatra just uses muPDF, FWIW.
Not really true. https://news.ycombinator.com/item?id=7788074