3 ms·

PDFium used by Chrome internally uses Foxit PDF library to read and extract information from the PDF. Google basically bought Foxit's library and open sourced

PDFium used by Chrome internally uses Foxit PDF library to read and extract information from the PDF. Google basically bought Foxit's library and open sourced it - but looks like the open source version isn't keeping up with the upstream commercial version of Foxit because the latest Foxit reader doesn't seem to have this bug.

sebazzz 9y ago
Wonder why they didn't go for pdf.js, since Chrome already has (had) superior JS performance.
- izacus 9y ago
  Because PDF.js doesn't come close to performance of native C++ code of pdfium (our tests showed 3-10x slowdown).
  - pier25 9y ago
    Indeed. PDF.js works for simple PDFs but once you start adding complex layouts, big images, vector graphics, etc, the experience becomes horrible on mediocre hardware. At least the last time I evaluated it. Hopefully Web Assembly will change this.
- gcp 9y ago
  There's a long tail of PDF documents that use obscure PDF features that pdf.js doesn't entirely handle correctly.
- Theodores 9y ago
  They probably don't care. All they needed was that aspect covered so that things like ChromeOS could have the functionality. They went for the guaranteed to work solution rather than reinvent the wheel. Okay, the more developed solution. I do not remember seeing PDF documents when I was last buying Google hardware, my impression is that Google don't see a future in the format, it is mere printer driver to them, not where the party is at.
- deleted 9y ago
  [deleted]
- TazeTSchnitzel 9y ago
  I believe pdf.js is newer than the Chrome PDF viewer.
- SigmundA 9y ago
  Performance is not as a good vs native as others have said but its usually good enough for most users with most PDF's. In practice what really prevents it from being viable in my experience is print quality. Since it uses canvas to render the PDF and their print solution just prints the canvas images, they dpi is low and the output is noticeably "fuzzy". PDF being primarily for print this really kills it. You have to save as PDF and print using Acrobat to get good quality. If they ever get their SVG back end working it should solve the print issue, honestly they probably should have started with a SVG back end, this same issue plagues many canvas based libraries. Interestingly they tried to do a canvas based print api (mozPrintCallback) that went nowhere. IMO browsers need better print abilities (see PrinceXML). But at least SVG is rendered to vector on print in all major browsers.

sebazzz 9y ago

Wonder why they didn't go for pdf.js, since Chrome already has (had) superior JS performance.

izacus 9y ago
Because PDF.js doesn't come close to performance of native C++ code of pdfium (our tests showed 3-10x slowdown).
- pier25 9y ago
  Indeed. PDF.js works for simple PDFs but once you start adding complex layouts, big images, vector graphics, etc, the experience becomes horrible on mediocre hardware. At least the last time I evaluated it. Hopefully Web Assembly will change this.
gcp 9y ago
There's a long tail of PDF documents that use obscure PDF features that pdf.js doesn't entirely handle correctly.
Theodores 9y ago
They probably don't care. All they needed was that aspect covered so that things like ChromeOS could have the functionality. They went for the guaranteed to work solution rather than reinvent the wheel. Okay, the more developed solution. I do not remember seeing PDF documents when I was last buying Google hardware, my impression is that Google don't see a future in the format, it is mere printer driver to them, not where the party is at.
deleted 9y ago
[deleted]
TazeTSchnitzel 9y ago
I believe pdf.js is newer than the Chrome PDF viewer.
SigmundA 9y ago
Performance is not as a good vs native as others have said but its usually good enough for most users with most PDF's. In practice what really prevents it from being viable in my experience is print quality. Since it uses canvas to render the PDF and their print solution just prints the canvas images, they dpi is low and the output is noticeably "fuzzy". PDF being primarily for print this really kills it. You have to save as PDF and print using Acrobat to get good quality. If they ever get their SVG back end working it should solve the print issue, honestly they probably should have started with a SVG back end, this same issue plagues many canvas based libraries. Interestingly they tried to do a canvas based print api (mozPrintCallback) that went nowhere. IMO browsers need better print abilities (see PrinceXML). But at least SVG is rendered to vector on print in all major browsers.