Pdf.js Reaches First Milestone

theweatherelectric writes "The pdf.js project aims to implement a PDF viewer using standards-compliant Web technologies. The project has reached its first milestone: it renders the sample PDF (a paper on Mozilla's Tracemonkey JavaScript engine) perfectly. However, that perfection currently comes with some caveats: 'pdf.js produces different results on pretty much every element in the browser×OS matrix. We said above that pdf.js renders the Tracemonkey paper "perfectly" if you're running a Firefox nightly. On a Windows 7 machine where Firefox can use Direct2D and DirectWrite. If you ignore what appears to be a bug in DirectWrite's font hinting. The paper is rendered less well on other platforms and in older Firefoxen, and even worse in other browsers. But such is life on the bleeding edge of the web platform.'"

Comments

Re:Wow

[Spad]

If you read the article (I know, I know)...

pdf.js has now reached the point where a significant portion of its issues are actually browser-rendering-engine bugs, or missing features. Finding these gaps and filling some of them has been one of the biggest returns on our investment in pdf.js so far.

The problem isn't what they've written so much as the browsers not being able to support the latest and greatest HTML5/JS functionality.

goal to make things suck?

[Anonymous Coward]

I can understand the use of this to find and fix browser bugs.

But it seems amazingly inferior to a platform native PDF reader, on any platform imaginable. It will be slower the native x86/ARM code by far, and won't integrate well with the desktop environment.

What's with this trend recently to build everything on fundamentally sucky technologies?

Re:goal to make things suck?

[Vellmont]

But it seems amazingly inferior to a platform native PDF reader, on any platform imaginable. It will be slower the native x86/ARM code by far, and won't integrate well with the desktop environment.

What's with this trend recently to build everything on fundamentally sucky technologies?

You're absolutely right. A platform native PDF reader is technically superior. But opening up a new window for each PDF you display really sucks as a user experience. To eliminate this sucky UI experience, browsers support PDF natively (I'm not sure why this hasn't happened), and not rely on Adobe reader, or some other helper application. Even if all the major browsers supported that TODAY, it would be literally years before a broad enough spectrum of people upgraded to use inline PDFs in a design.

What implementing a PDF reader in javascript accomplishes is across the board inline PDFs today. No upgrades required. I think that's worth some sucky technology and inefficient code.

Re:Wow

[Lunix Nutcase]

They've actually failed to grasp the point of PDF. You might as well go back to HTML if your PDF reader can't render the same everywhere considering that was the whole point of PDF to begin with.

The one true markup

[Ed Avis]

This is really cool. Now we just need to have web2js instead of web2c, and we can typeset documents with TeX in the browser.

Re:Can it be closed?

[headbulb]

I have it disabled since it's buggy and it's a huge security risk.

Fun fact:

[giuseppemag]

I can render a PDF perfectly on all OSes I own (Windows, OS X, iOS, Windows Phone 7) already!

Re:"older Firefoxen"??

[Maclir]

No. The plural of "fox" is "foxes".

If someone can't use the English language correctly, how seriously do you expect me to take anything they write?

Re:Wow

[PybusJ]

Or perhaps you've failed to grasp the point of a v0.2 pre-release on github? In fact TFA specifically states that pixel perfect rendering _is_ their goal.

The blog post describes the current progress; it now has good rendering on one platform, progress from last week.