Comment by userbinator | Hacker News Reader

Comment by userbinator | Hacker News Reader

pdf.js uses HTML canvas elements to render each PDF page

If it's doing this for text or vector graphics content, then I'm of the strong opinion that they're doing it very wrong - HTML already has facilities to render text, and browsers support SVG for vector graphics. The canvas elements should be used for bitmap images only, since that's what they were designed for.

Edit: this thought occurred to me because the Chinese site Baidu has an online document viewer which basically converts uploaded PDFs into HTML and does it without needing to canvas everything; here's an example:

http://wenku.baidu.com/view/544340cea1c7aa00b52acb38.html

In my Chrome it takes ~60M sitting on the first page, complete with all the other pieces of the page (including ads). Scrolling through all the pages of the document, it ends up at ~130M.

Here is the original document:

http://www.promelec.ru/pdf/MBI5030%20Preliminary.pdf

When it is opened in PDF.js (v1.0.277) to the first page, I see ~95M and scrolling through all the pages makes it peak at ~270M; and this is just for the PDF viewer only, so there is clearly much room for improvement.

Sorry, but this is definitely a case where code speaks louder than words. PDF.js was a miracle for its time, and the guys behind it definitely aren't amateurs.

The PDF standard is far richer than the SVG object model, and not to mention SVG performance in just about every browser except for Chrome has always sucked balls.

Using canvas seems a solid trade off - pay upfront with RAM in order to consistently render and cache a page once, or try to jerry-rig some nasty translation to SVG that's painfully slow to zoom or scroll, and no longer renders consistently across browsers.

I'm not doubting that PDF.js is an amazing work of effort -they have essentially replicated the entire PDF rendering engine - but that considering a different approach, with a different set of tradeoffs, could yield a solution requiring far less memory and still have practical use.

When considering memory, keep in mind that using too much - combined with every other process the user could be running - means a higher chance of needing to use the swapfile, and then any performance advantage otherwise gained disappears rather quickly. It should be noted that browsers already cache rendered page images (from HTML) in memory and are very good at that, along with rendering HTML.

> SVG performance in just about every browser except for Chrome has always sucked balls.

That seems like a self-fulfilling prophecy to me. If it's broke, fix it. Don't do clunky workarounds that mean that it's less likely to be fixed in the future.

I don't agree with you. HTML has some facilities to render text, but I expect it's an intractable problem to use them to accurately render a PDF. SVGs might be easier, but I'm not sure they have the required facilities to allow for accurate PDF rendering either.

IMO, if Mozilla chose to use Canvas then there's a good reason for it.

So your argument is that because Mozilla does it they must have a good reason for it?

The argument is that you shouldn't unthinkingly assume they don't have a good reason for it.

No - the argument is that it's likely pretty difficult to implement an accurate PDF renderer with HTML and SVG. There might be ways around that, but they folks at Mozilla are pretty smart and very aware of the limits of their technology, so if they decided that Canvas was better, I have no reason to argue with that - especially given that there are obvious reasons that might be the case.

It's a good thought, and it does seem a much better way to go at face value. However, I strongly suspect there are good technical reasons why you basically need to use canvas, to get the complete, pixel-perfect control over the layout and font rendering that you'd need for PDFs.

to get the complete, pixel-perfect control over the layout and font rendering that you'd need for PDFs.

I suspect this is part of the problem too - the desire to render every pixel of fonts the same as the native application. But honestly, 99.9% of the time I'm reading a PDF, I don't care if each pixel is in exactly the same place as it would be in some other reader application so long as I can read the content, and would be willing to sacrifice that if it meant a drastic decrease in memory consumption (and possibly better performance.) That doesn't mean a "precise mode" is a bad idea, so maybe make this an option - you can either have pixel-perfect rendering but use more memory and CPU, or have a "close enough" rendering that doesn't.

If you don't care you should feel free to replace pdf.js with a degraded version, but I'd expect something which claims to render PDFs to actually do that.

Seems to me that the development time spent maintaining two different modes might be better spent simply improving the efficiency of the one correct version.

"But honestly, 99.9% of the time I'm reading a PDF, I don't care if each pixel is in exactly the same place as it would be in some other reader application so long as I can read the content"

No, you don't actually want that. I've seen this in Linux where a PDF gets rendered with the wrong font because the correct one wasn't on my system or embedded in the PDF. It becomes illegible. PDFs are deeply pixel perfect in specification; you can't just decide to not worry about that anymore and expect anything legible to come out the other side. It is not HTML under the hood; it's a printer format under the hood.

Spot on. Pixel-perfection is probably the single most compelling thing about PDF, and it certainly is a fundamental design goal of pdf.js.

It’s worth pointing out that an accessible content structure is presented to assistive technology, and you can also find-in-page without any problem.

It already appears to use html to display text. View a pdf.js demo (google pdf.js and click demo button on project page). Select some text and inspect it in your browser dev tools. It's a div.

No, it isn't. The div that you see is probably inside an element named textLayer, which is there to enable copy-pasting. The actual rendering is on a canvas.

The example is quite illustrative of the difference in what is possible in either method. Figure 1 is not displayed correctly in baidu's viewer, and it's not a matter of details like line width (which are present and quite obvious), but it also fails to display some content (vertically oriented text).

See http://imgur.com/a/khf0F

I don't see any reason why canvases should use more memory than content in general. Content uses content layers to store pixel data; canvases use canvas layers. Either way, the image data is only stored once.

It comes down to tuning more than anything fundamental.

Reply on news.ycombinator.com