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?

[DrXym]

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

I think it's becoming increasingly obvious that browsers need something that allows native client functionality without the burden of shoe horning everything through Javascript's loosely typed, garbage collectioned, non addressable world. LLVM is gaining a lot of steam so perhaps it should be that with each app seeing a limited API that maps out onto the DOM. Perhaps that can even be created from JS, e.g. an vmEval(url, canvas) function that loads bitcode from some url, turns it into an invokable object which is associated with a drawing region.

Re:goal to make things suck?

[jlebar]

It will be slower the native x86/ARM code by far, and won't integrate well with the desktop environment.

Does your PDF reader integrate well with the browser environment?

One of the major benefits of rendering PDFs in the browser, aside from the fact that users don't have to download, trust, and run a separate PDF viewer, is that you reduce the security vulnerability surface area. PDFs (well, Adobe Reader) is a major vector for attacks, but that goes away when you sandbox it in the browser.

I think you might also be surprised how fast one can make something like this in JS. Most of the expensive paths, like drawing to the screen, are exported to C++ code.

Re:goal to make things suck?

[hedwards]

If it's a vulnerability thing, then what you really need to do is go over to Adobe and bitch smack the moron there that decided that it was a good idea to include scripting and linking abilities into a document format. And if you choose the Seattle branch you're just a short ways from MS so you can bitch slap the hell out of them for doing the same sort of bullshit with .DOC.

Documents are for reading, if you want people to be able to fill in a form, then they should have to use a separate program. It's just way too easy to exploit that "feature" when very few people actually want to edit their PDFs anyways. I can't personally recall the last time that I needed that functionality.

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:goal to make things suck?

[pond0123]

But opening up a new window for each PDF you display really sucks as a user experience.

Having "defected" from Win XP to Mac OS X back when Vista was released, it's been many years since I used Windows or Linux for long periods of time, rather than temporarily in VMs for work purposes. Now and then, stories like this, or even entire pieces of technology like the renderer in question, remind me just how awful things still are on other platforms.

Another poster asked if the PDF renderer was integrated into the browser, rather than the OS. What a bizarre question. My PDF renderer is integrated into both, because it's part of an OS framework that understands how to render to and from a whole bunch of stuff, PDF included. Adobe's PDF reader is not installed, has never been installed and will never be installed. PDF is just another datatype that the OS already understands.

I can open a PDF in the same window or a new window if I want, or download it directly, or open it into a new tab, just in the same way as I can open any link in the same window, a new window, a tab, or download it - the right-click / Ctrl+Click context menu. There's nothing special going on. It's just another resource that my browser can handle. Quite why other browsers and operating systems insist upon treating PDFs as some incredibly hard, exotic, special and magical thing that must be treated differently from other page content in this day and age is beyond me.

It's not a kludge, it's not a bodged add-on, it's an extensible, intelligent, well integrated piece of technology that's part of a wider architecture that makes more sense than any other OS architecture I've seen above kernel level. It goes hand in hand with other excellent ideas like Core Audio, Core MIDI, Core Image, Core Animation and Core Data. It's one of many technical reasons why I chose Mac OS X - not some turtleneck wearing barely-existent clichéd stereotype of a technologically illiterate individual who doesn't know better. I made an informed choice based on the technology, despite my dislike then and dislike to this day of the company that makes it; a computer is a tool, not a religion.

I can see why this JS renderer is needed, even though it'll make the web worse for Mac users by making their PDF experience suck more - non-integrated, slow, PDF trapped in the page by the JS renderer... But it's necessary for all the other operating systems or browsers that think PDF is just Too Hard. While we can all laugh at Microsoft's ineptitude, the open source community hasn't managed to get this kind of architecture level stuff sorted out across Linux distributions either, so Mac OS X is your only mainstream alternative. And that's really quite sad.

Can it be closed?

[hackertourist]

I currently have PDFs set to be downloaded and opened in an external application, because PDF rendering in a browser tab (using Adobe's PDF plugin) fucks up important shortcuts: Cmd-W no longer closes the tab but throws up an annoying dialog. That alone would be reason enough to switch.

Re:Can it be closed?

[headbulb]

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

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:The one true markup

[TheRaven64]

I've written a clang plugin that translates C to JavaScript, so it should be possible to chain that with web2c to produce JavaScript...

Re:Wow

[QuasiSteve]

I'm guessing you're modded Funny because - sadly - this hasn't been true of PDF in a long time now.

Even between desktop PDF readers there's now too much of a difference to even remotely be able to 'rely' on it. Even bitmaps are getting less and less reliable with applications choosing to either respect or ignore gamma tags, let alone color profile information.

As it is, I used to use FoxIt, but that started to get bloaty and including oddball toolbars. So I switched to PDF-Xchange. I'm about to switch again (Sumatra, maybe?) because PDF-Xchange takes far too long to render pages with lots of graphics. And neither FoxIt nor PDF-Xchange render vector content with anti-aliasing correctly.
http://i.imgur.com/f8udg.png
( original image source: sinfest.net . Note that left image was at 172% zoom, right image was at 150% zoom, to get the same on-screen size. wtf? )

I'm going to guess that Sumatra really won't be any much better and maybe I'll have to go back to FoxIt.
Either way, it looks like Adobe Reader will have to remain installed for when these alternatives don't quite get things right.

Fun fact:

[giuseppemag]

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

Over reach much?

[FlyingGuy]

This is just silly. While I can appreciate it from a point of curiosity and it is probably a fun project, this is really overloading the browser.

I would submit that things like this are actively breaking the browser paradigm. Every PDF viewer allows you to save a local copy of the PDF after they have read it from the temp directory or the download directory. To implement this thing correctly is would require that JS have direct access to the file system, which as I understand it, aint fucking supposed to happen, since that would create untold numbers of security problems in a system already plagued by security problems.

While there may be arguments that this would be ok, they would all be moronic.

The entire notion of the browser needs to be forked out to an application shell with hard as nails security and a presentation shell and never the twain shall meet.

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?

Nice way to open even more holes in the browser

[Anonymous Coward]

Direct2D and DirectWrite? Sorry but browser graphical acceleration must end.
WebGL should be implemented with no hardware acceleration, using graphic card emulation.

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.

Re:"older Firefoxen"??

[Anonymous Coward]

Despite your relatively low uid, you must be new to hacker slang.

from the Jargon File:

On a similarly Anglo-Saxon note, almost anything ending in ‘x’ may form plurals in ‘-xen’ (see VAXen and boxen in the main text). Even words ending in phonetic /k/ alone are sometimes treated this way; e.g., ‘soxen’ for a bunch of socks. Other funny plurals are the Hebrew-style ‘frobbotzim’ for the plural of ‘frobbozz’ (see frobnitz) and ‘Unices’ and ‘Twenices’ (rather than ‘Unixes’ and ‘Twenexes’; see Unix, TWENEX in main text). But note that ‘Twenexen’ was never used, and ‘Unixen’ was seldom sighted in the wild until the year 2000, thirty years after it might logically have come into use; it has been suggested that this is because ‘-ix’ and ‘-ex’ are Latin singular endings that attract a Latinate plural.

Now get off my lawn.