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:Not impressive...

[Anonymous Coward]

Goatse

Why all the complaining?

[Bradmont]

Even reading the summary it is clear that this is a very, very early development work. This is their *first* milestone, of course it's going to be severely lacking in almost every way. Of course it's not cross-browser and doesn't allow selectable text... but eventually it will be. I, for one, think this is a great idea, and can't wait to see it done!

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.

Re:incomplete sentence?!

[Spad]

I *think* it's supposed to be:

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.

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?

[heathen_01]

Great idea, the bit code could even execute inside a vm for cross platform compatibility and also be constrained by a sandbox.

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?

[richtaur]

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

In order to evolve, platforms need their boundaries pushed. I'm sure this project is partially intended to reveal to browser makers (including Mozilla themselves) exactly where and how their platform could improve.

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?

[kripkenstein]

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.

Regarding speed, two things: First, this will spend most of its time in calls to the browser's Canvas API, which all browsers implement in C++. So it isn't clear that it should be significantly slower than a native implementation. Second, even if this were in 100% JavaScript, that is just around 5X slower than C++ these days. Rendering PDFs might be plenty fast enough at that speed, since you typically render once then show it for a long time. In other words, this isn't something like a game engine that needs to push 60fps.

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

There are several advantages to implementing this using Web technologies. The first is, as you mentioned, it's a good way to find browser bugs, and it also helps find areas to improve the Canvas API. Another important reason is that this implementation will be much more secure than any other existing PDF implementation, because so much work has gone into proper sandboxing of JavaScript. And we know how many vulnerabilities keep popping up in existing PDF readers like Adobe's. It will be much more secure to use this new PDF implementation than the existing ones.

Re:goal to make things suck?

[yarnosh]

The real question is, if you know you have to display your PDFs in a web browser, why not just convert them to something more web friendly on the server side and then display that to the client? It isn't like you'd be using pdf.js as your PDF viewer for any PDF. It has to be embedded in a website for specific PDFs on that site.

Re:goal to make things suck?

[yarnosh]

So... like Java applets?

Re:goal to make things suck?

[roca]

Have you tried it? It's fast.

One interesting fact that wasn't called out in the blog post is that since Gecko's is GPU-accelerated on Windows 7, on that platform pdf.js is GPU-accelerated, unlike every other PDF viewer I know of.

Browser developers are doing tons of work to make graphics and JS incredibly fast. pdf.js leverages that.

Re:goal to make things suck?

[phantomfive]

The point is that once you can draw a PDF on the screen, you can draw anything. It means you can implement photoshop in Javascript. More importantly, it means you can draw something on the screen, and get it to render exactly the way you want it to, on any system. Right now this isn't possible in a browser, and it sucks.

It is the PDF language that matters, which is basically a successor to Postscript, not the bloated document reader.

Re:goal to make things suck?

[DMiax]

my browser opens pdf files in the same tab by default. if you talk about integrating the pdf into a webpage you should think about the %lt;object> tag. This attempt seems misguided and I hope no website ever serves it to me.

Re:goal to make things suck?

[kangsterizer]

It's actually rather fast here, as fast as the native reader.
Somehow, its not as smooth in Chrome as it is in Firefox however.

Re:goal to make things suck?

[RocketRabbit]

So are you asserting that a browser window with a PDF document is somehow worse than a PDF viewer's window? Or that a tab is better than a window?

Re:goal to make things suck?

[Vellmont]

I actually didn't know you could already embed a PDF in a page. I'd guess you can't create your own controls to move to a different page, or manipulate the PDF in other ways, and are reliant upon the helper application.

The point being, viewing a PDF with programmatic controls would allow for a much richer environment than relying on helper applications.

Re:goal to make things suck?

[roguebfl]

No it because Adobe Acrobat reader has taken too long to rid of legacy security risks, so the point of the project is designed to removed the need for it in the first place.

Yes a Native reader is great for a PDF document already your system, this is for PDFs on the web that you don't even know if you want to to save to your system or not (anymore than any web document is temporarily put in your cache)

Re:goal to make things suck?

[Vellmont]

I'm saying none of that. I'm saying that sometimes it would be very useful to display a PDF inline in the same page, and not have it displayed in another window, or tab. Another poster pointed out this is already possible. I'm not familiar with how well this works, and the limitations of this method. I will say that being able to treat a PDF like any other object and have it be manipulated programatically would be a huge advantage for some people.

Re:goal to make things suck?

[DrXym]

No. Java is higher level, garbage collected, has its own system libraries which run indepedently of the browser, and is a very large environment in its own right.

I'm suggesting that there should be provision for LLVM bitcode to be compiled and executed natively in the browser. It's only interaction with the outside world is via exposed DOM apis which are already security hardened. A canvas would be its "display", it sockets would map to websockets, it's file io to web storage and so on. The display could be a console or graphical via WebGL. It's memory would be addressable and fixed so it could not leak more memory than it had physical access to. The C runtime would resemble other C runtimes so that many libs and apps could be easily ported. Since most higher level languages are implemented in C, they would be portable too to some level. The biggest issue is likely to be threading and how to address calls out to the DOM.

We've already seen with emscripten that LLVM can be turned to Javascript and use the DOM for a lot of stuff, so what I'm suggesting is only taking it one stage further.

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.

Re:goal to make things suck?

[elgaard]

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

My browser can show PDF in tabs.
But I almost always want PDF-s to open in a new window, full-screen.
Why would I want to read a 200 page report inside a browser?

The same goes for video, I usually want to view it full-screen not embedded in some page in a browser.

Re:goal to make things suck?

[HappyPsycho]

Especially if it gets them to upgrade

Re:goal to make things suck?

[HappyPsycho]

PDF's strong point is consistency in layout across any platform, even ePub and book formats have issues in this area when layout is important.

Magazines, Application forms (e.g. passport, drivers permit, id cards, etc), invoices are a few examples where PDF is still heavily used.

Its much easier for a web master to just include this on their site and things "just work" than to ensure that all of your clients need to download and install a PDF viewer. This becomes even more appropriate when you take the mobile side of things into account, having to fire up a separate reader can become quite annoying.

Re:goal to make things suck?

[Unequivocal]

It would be nice if text-based PDF's interacted with my browser the same way text-based HTML does. So find, save as and other functions would be browser native rather than the kooky half-breed we have today (with pdf reader stuffed into a browser tab for some docs and mysteriously for other pdf docs a new pop up window with native pdf reader).

Re:goal to make things suck?

[yarnosh]

Generally if layout is that important, that means you're printing it. In which case, you probably want to download and print the document from a real PDF viewer. PDF isn't suitable for mobile devices anyway. But then, being on a Mac and using an iPhone, maybe I just take good PDF support for granted? PDF.js sounds like a neat exercise, but I'll keep using Preview. I don't really want your half-assed, slow PDF viewer embedded in my browser, thanks.

Re:goal to make things suck?

[YttriumOxide]

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.

Indeed. I came from a long line of AmigaOS based systems, after which I finally "gave up" and got an XP based laptop after being forced through Win2k at work. That drove me mad for awhile and after significant playing with Desktop Linux (just never feels "right" to me... very happy with it on my servers, but not my dekstop), now I've got mostly Macs in the house.

The system you're referring to here is indeed very simple and elegant. It reminds me a lot of what AmigaOS did with the "datatype" system - Apple's Preview feels like the natural successor to Amiga's MultiView for me - a basic "general viewer" for all of the native core types that the architecture understands.

There are of course many things better about the OS X architecture than Amiga's datatype system - most of which come from it being significantly more modern. The one thing I do still miss from the Amiga's datatypes though is that it was so ridiculously easy to write your own. If I needed to make a custom file format for something, I'd do it almost exclusively as datatypes and then be able to work in this format from pretty much any Amiga application that used datatypes (which was the vast majority of them). For non-programmers, they could just download a datatype, copy it to the appropriate system location and "voila" it just worked. I've yet to find an easy way to write my own filetypes for OS X that will then "natively" be usable in Preview and so on.

Re:goal to make things suck?

[sjames]

Oddly enough, PDF (a descendant of PostScript) has always been more program than data. Like PostScript, a pdf document is a program in a Forth like language that draws the document on a canvas. Adobe's mistake is in letting it out of the sandbox with bolted on extras.

A number of others have managed to implement PDF sandboxes (often without the bolt-ons) without all the holes.

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?

[Yvan256]

Small note to webmasters everywhere (if you think about what the parent said): what I hate is websites that force PDF files to be downloads instead of letting my browser handle them. On Mac OS X, viewing a PDF is basically the same as viewing a JPEG. No Adobe reader required, it just works.

Re:Can it be closed?

[EndoplasmicRidiculus]

That capability is Safari's, nothing to do with OS X. Google Chrome can also display PDF's inline.

Re:Can it be closed?

[headbulb]

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

Re:Can it be closed?

[MurukeshM]

Adobe's PDF sucks. I use either:
a) Google Quick View (my favourite),
b) Chrome's built-in PDF viewer (which is fast, and doesn't crash often, and doesn't hang everything while the PDF is being downloaded.), or
c) Foxit's plugin (very rarely),
depending on the browser and OS being used. But I tried it out, and though the rendering was horrible (Chromium daily on Natty), it didn't seem to hang or ask anything on being closed. The slide-out sidebar was neat, but the open file button didn't do anything.

Re:Can it be closed?

[ortholattice]

what I hate is websites that force PDF files to be downloads instead of letting my browser handle them.

The problem is that the web site incorrectly specifies the file mime type as e.g. "Content-Type=text/html" instead of "Content-Type=application/pdf". While in theory the ".pdf" extension or content inspection could be used to guess it, Firefox (for example) does not use mime type guessing since it is a security issue: What should Firefox do with this file?.

Re:Can it be closed?

[Yvan256]

OS X itself handles PDF just fine (Quick Look, Preview, Safari, print directly to PDF from any application that can print, etc).

Re:Can it be closed?

[tlhIngan]

OS X itself handles PDF just fine (Quick Look, Preview, Safari, print directly to PDF from any application that can print, etc).

That's because OS X's underlying display API is... display PDF! Similar to ye olde Solaris Display PostScript. As a side effect, display and generation of PDFs is trivial - you're outputting to a file rather than to the rasterizer.

It's also the reason why PDFs are trivially displayed in iOS as well - again, being based on OS X means it also inherits display PDF.

Re:Can it be closed?

[Malc]

I was hoping somebody around here might explain the point of opening PDFs embedded in the browser. Instead, your post just confirms my own prejudices. The PDF plugins that I've seen trade off screen space for another toolbar, restrict the functionality over standalone PDF viewer, and break the browser's UI. Chrome's handling of PDF was the single reason I ditched it after a few weeks last year when I tried to switch to it from Firefox (even set to open the PDF viewer was broken as it didn't seem to pass it off to the Acrobat reader properly).

"older Firefoxen"??

[Anonymous Coward]

So, "Firefoxen" is now the plural of Firefox?

Re:"older Firefoxen"??

[Anonymous Coward]

Emacs --> emacsen; ergo, firefox --> firefoxen. Now, let's go back to comparing Officen and OSen.

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:"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.

Re:"older Firefoxen"??

[hedwards]

Actually proper English dictates that with Emacs and Firefox you'd need a partitive, making it versions of Emacs or versions of Firefox.

Re:"older Firefoxen"??

[ProzacPatient]

Being a grammar nazi just tell yourself it's the German translation of "Firefoxes." I'm sure that will make you feel better.

Re:"older Firefoxen"??

[rubycodez]

That actually would be Feuerfoxen.

Re:"older Firefoxen"??

[rubycodez]

or FeuerFüchse

Re:"older Firefoxen"??

[ProzacPatient]

Yeah, actually thanks but I was being sarcastic though.

Re:"older Firefoxen"??

[Tim C]

That's as may be, but *I* am not new to hacker slang, and frankly, it sounds stupid.

Yes, the plural of ox is oxen. No, the plural of box is not boxen, nor is foxen the plural of fox.

Now you get off *my* lawn.

Re:Not impressive...

[deniable]

Oh wow, retro-trolling. Soon we'll be back to page-widening, Steven King is dead and bell bottoms.

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.

Re:It's all images

[Yvan256]

If it renders it all as images, then why go to the trouble of making this client-side?

Render as images on the server once and your problems are over for all platforms and browsers. Unless, of course, you do something stupid like using the BMP image format instead of PNG.

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

[zhiwenchong]

Are you sure you want to do that? I can understand typesetting math in the browser, but typesetting entire TeX documents?
There's already an AMS-endorsed way of typesetting TeX math (Javascript-based) called MathJax (http://www.mathjax.org/), and it works pretty well (well enough for sites like http://mathoverflow.net./

Re:The one true markup

[colinrichardday]

But TeX/LaTeX works by having a fixed page size. While one can make the vertical height large enough to accommodate the page, how do you adjust the width if a user resizes the browser?

Re:The one true markup

[FrangoAssado]

Are you asking if there's really a C-to-JavaScript translator? If so, then yes:

https://github.com/kripken/emscripten/wiki

Re:Not impressive...

[ciderbrew]

(congrats, 'twas a while ago I was goatsed the last time)

I hope you mean saw that picture!

Re:Not impressive

[mwvdlee]

https://github.com/andreasgal/pdf.js (It's BSD licensed, minus the credits clause).
Who's the asshole now?

Re:It's all images

[Anonymous Coward]

Why not use a vector format which can properly scale the text and even include the text in a format readable to search engines?

Like, for example, PDF?

Re:incomplete sentence?!

[Anonymous Coward]

They cut the sentences into separate clauses to emphasise each of them ...

tinySVG support preferred.

[sgt scrub]

pdf is old vector graphics news. If they want to help a parky out they can get TinySVG support built in to Firefox so I can finish rebuilding all of my XUL UI's in SVG. ...that don't work now unless the user knows how to re-enable support then ends up getting owned instead of a warning like getting a self signed cert... Cough. Sorry. Oh while I'm dreaming, getURL, putURL, and parseXML functions so I don't have to "if typeof (parseXML=='undefined')" override them every time would be nice too :) Oh and those wondering about the relationship here, pdf to svg is easier to convert and display on the fly. Well. For me. So programmers can probably do it in their sleep. Oh. Oh. And a pony.

Re:What's the point?

[paimin]

Bzzzzt! iOS handles viewing and saving PDF's fine. Thank you for playing "I Bashed Apple on Slashdot". Try again.

Re:It's all images

[tepples]

Render as images on the server once

"The document could not be displayed because you are not connected to the Internet."

Re:What's the point?

[tepples]

I already have a perfectly fine Pdf viewer, called Okular.

From Okular's web site: "For Windows have a look at the KDE on Windows Initiative webpage for information on how to install KDE on Windows." The download page on KDE Windows Initiative links to detailed installation instructions. I'm not in a position to try it myself because the PC on which I'm typing this has integrated graphics, which isn't enough to run KDE according to a forum post linked from a Google search for kde system requirements.

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.

Carts before horses

[macraig]

I find it quite hilarious that people speak seriously about coding artificial intelligence as if it will happen in the this decade, when at the same time we can't even achieve a consistent rendering of the same elements in different browsers.

Re:Carts before horses

[Blobule]

These problems are generally disjoint. Identical cross browser rendering depends on everyone playing the standards game or everyone playing the let's add fixes for every browser game. The AI problem depends on solving the problem of genuine artificial intelligence without the need to pay attention to cross platform compatibility. That said, I doubt we'll see real AI this decade either :)

Re:Carts before horses

[Kz]

You're missing the goal: we need strong AI so that all web documents can be sentient. That way, they'll do a conscious effort to be usable on any kind of browser. See? it's not because AI is cool, it's our only hope!

Re:Carts before horses

[TangoMargarine]

When the AI arrives, it will only run on Windows.

Re:Carts before horses

[macraig]

In Soviet Russia, Windows runs away from AI!

Fun fact:

[giuseppemag]

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

Re:Fun fact:

[GNious]

*impressed'

I only have OS x 10.6.8, and I cannot render most PDFs I get correctly.

Stuff is usually missing, either a few bullets in a document, or whole content (fun boardinpass - only barcode and rudimentary graphics available).
In some cases, extra lines are added.

Might be bad PDFs, but they seem to render OK on other people's Windows machines.

Re:Fun fact:

[giuseppemag]

And no malware has ever been transmitted through the browser, so another problem brilliantly solved!

Now if only we could remove the OS and only have a browser that does exactly what the OS did but under a different name, the world would be a far better place...

Re:Fun fact:

[yarnosh]

Apple's Preview.app is the best PDF viewer I've ever used. I don't know what you've been trying to render.

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:Over reach much?

[jlebar]

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

Too late.

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.

What a novel idea!

Re:Over reach much?

[StripedCow]

Next step: implementing gecko or webkit in javascript, so that developers have the same experience everywhere.

In fact, now that I'm thinking of it, that would not be such a bad idea.

Re:Over reach much?

[arose]

Or the save button could be a link to the PDF.

Re:What's the point?

[PeterBrett]

I'm not in a position to try it myself because the PC on which I'm typing this has integrated graphics, which isn't enough to run KDE according to some idiot who doesn't know what he's talking about.

Fixed that for you. KDE 4 works perfectly with integrated graphics, you just have to turn desktop effects off. It's perfectly usable without desktop effects enabled, all applications detect it and degrade gracefully, and all the controls etc. work pretty much the same. I have a laptop with integrated graphics that doesn't support desktop effects, and I don't notice the difference apart from once a week or so when I suddenly wonder why my terminal emulator doesn't have a transparent background.

This graceful degradation is a pleasant contrast to GNOME 3, I might add.

Re:What's the point?

[PeterBrett]

Oh, and I also use Okular on Windows. It works quite nicely.

Re:What's the point?

[Anonymous Coward]

The end game is that by shifting focus from desktop applications to cloud applications makes the desktop operating system much less important.
Envisage a day when you dont need to run just so you can run that one specific app.

this might sound over the top - but i am sure that given time we will be able to play the new "Crysis" (whatever that might be) in the browser on any operating system. (of course there will still likely be some beefy hardware requirements and a juicy broadband). Although im fairly confident that day will come - and probably not as far of as we think! Developers can target the one platform to rule them all.

Re:What's the point?

[makomk]

Is this a troll, or did you just spectacularly miss the point? That forum post is fairly obviously about the system requirements for the KDE equivalent of Aero Glass or whatever it's called these days...

Re:It's all images

[ObsessiveMathsFreak]

You can't do those things with most PDF files anyway.

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:Nice way to open even more holes in the browser

[Skuto]

Neither are related to WebGL specifically. They're used for much more mundane things such as Canvas rendering.

Re:Nice way to open even more holes in the browser

[BZ]

> Sorry but browser graphical acceleration must end.

You can have two of the following three:

1) Scrolling that doesn't feel like molasses.
2) Box blur and shadow effects of various sorts.
3) Sofware rendering backends.

You're presumably voting for #1 and #3, but web designers are voting with the figers for #2, so a browser's options at that point are limited to either not supporting those and reaping the web-developer hate consequences (c.f IE6) or dropping either #1 or #3. Which one do you think they're more likely to drop?

VM / Sandbox

[Mathinker]

> Either way, it looks like Adobe Reader will have to remain installed for when these alternatives don't quite get things right.

You might consider installing a VM like VirtualBox or some kind of sandboxing solution so that you can convert / print / export and subsequently erase any "side effects".

Memory and surplus CPU power is getting cheaper and cheaper, I don't understand why more people don't talk about going this route.

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:Wow

[moonbender]

Back when I still used Windows, Acrobat Reader was an absurdly large app and by far the slowest PDF reader I knew over all platforms. It always struck me as absurd that Apple and Linux users had built-in, capable, lightweight PDF viewers while most Windows users used that bloated POS. Maybe acroread is better these days, but I kind of doubt it.

Re:Wow

[Osgeld]

ha thats a ghost argument

"see my infinity energy machine works perfectly fine, its just the laws of physics have not caught up yet"

does not sound like any less bullshit

It's not doing the rendering

[Animats]

The Javascript code isn't doing the rendering of text. It uses dynamically loaded fonts and lets the platform's own font renderer render the glyphs. The Javascript code isn't pushing pixels.

There's less need for PDF than there used to be, now that you can download fonts in the browser. It might be worthwhile to take this PDF viewer and turn it into a server-side PDF to HTML translator.

Re:It's not doing the rendering

[hey]

Thank you for saying that. It seems to be that displaying an HTML file isn't much different that displaying a PDF file. At high level the program reads the description (eg this font size, put the text here, etc) and hands it off to some renderer.

Re:It's not doing the rendering

[jimshatt]

PDF is useful when you want to save the document on disk, on a rare occasion. I like the way Gmail handles this, by presenting a view link and a download link. With PDF.js other web applications can do this too, without the need for a server-side converter.

Re:It's not doing the rendering

[tyrione]

The Javascript code isn't doing the rendering of text. It uses dynamically loaded fonts and lets the platform's own font renderer render the glyphs. The Javascript code isn't pushing pixels.

There's less need for PDF than there used to be, now that you can download fonts in the browser. It might be worthwhile to take this PDF viewer and turn it into a server-side PDF to HTML translator.

OS X is Display PDF and 10.7 is OpenGL 3.2 system-wide. PDF is extremely lightweight on OS X.

Evince on Windows

[Blaskowicz]

Did you try gnome's evince? it has a little known windows version, which is easy and very decent.

Being free software makes it free of toolbar, ads and clutter. plus using the same software no matter the OS is nice.

Re:Evince on Windows

[arglebargle_xiv]

Did you try gnome's evince? it has a little known windows version, which is easy and very decent.

I looked at this a while back, it was over 30MB compressed so my guess is it's downloading a huge amount of emulation-layer code to make Windows look like Linux. Unfortunately this doesn't make it much of a lightweight viewer.

(Evince is a nice viewer, but it is rather tied to Gnome. That's not a complaint, but it does lead to some problems when moving it to Windows).

But why?

[amn108]

But WHY? Why spend precios cycles that eat battery life and heat up your PC innards doing the same thing through twenty layers of twisted human logic, that a piece of native runtime plugin code can do as well? 'Plugin' is just a word, it doesn't need to be insecure, alien, buggy or . And even if they are that, the problem lies at another level.

If anything, Pdf.js will be suitable where and when energy and resource conservation isn't a factor.

As for me, I prefer to avoid all the extra layers of abstractions and have the ball fall into the same basket.

Please enlighten me, a software developer of many years, what is this gold that is Pdf.js? I mean, apart from proof-of-concept being gold in itself.

Re:But why?

[Vellmont]

Please enlighten me, a software developer of many years, what is this gold that is Pdf.js? I mean, apart from proof-of-concept being gold in itself.

Gold is just a bit of an overstatement. More like a valuable, but not precious metal like copper.

The value is that you can display a PDF inline with the website, rather than bringing up a clunky external application like adobe reader. "But you could do that with a plugin!" you say? Correct, but what you can't do with a plugin is actually get most people to install the thing. Since most people won't install it, the feature becomes useless. If you implement it in javascript though, those problems go away.

Re:But why?

[BZ]

> that a piece of native runtime plugin code can do
> as well

Because in some environments you can't drop in native runtime plugin code.

Or put another way, where's that 64-bit Flash for Linux? Or heck, for that new architecture that people will come up with tomorrow?

Whereas this way porting a web browser (a must for a new consumer-facing architecture anyway) will get you a PDF renderer for free.

> 'Plugin' is just a word, it doesn't need to be
> insecure, alien, buggy

A PDF-renderer plug-in can be secure and non-buggy if you spend enough resources on it. No one has done that yet. This project aims to get "secure and non-buggy" with less developer time invested.

> If anything, Pdf.js will be suitable where and when
> energy and resource conservation isn't a factor.

Or where reducing the security exposure is important.

> As for me, I prefer to avoid all the extra layers of
> abstractions

Within reason, yes? Or do you hand-code everything in assembly (or directly implement on FPGAs, even)?

The only question is _where_ the tradeoff lies.

> what is this gold that is Pdf.js

Think "a way to render PDFs in a browser without adding any new security bugs and without spending a few man-decades developing it".

Re:But why?

[Atzanteol]

This is a great point. With the current scarcity of precious computer cycles left in the world why would we waste them on this? The latest government report on general availability of cycles estimates that we will be running out in the next 50 years. Just think of that - a world with no computer cycles remaining! In fact we'll feel the crunch far before that as the scarcity drives up computer cycle prices. Every cycle needs to be preserved and only used for productive purposes!

This post made using as few CPU cycles as possible.

Re:Wow

[hairyfeet]

Actually Sumatra is pretty nice. it is fast, low resource, haven't done any side by side but so far looking at a ton of PDF that I have they look the same as they did in Foxit so I assume they are rendering correctly.

So if you want to give Sumatra a spin the easiest way is to use Ninite which turns 'clicky clicky next next next" into click and run. They also have tons of nice software from CCleaner to Glary Utilities and all of it TOOLBAR FREE without having to worry about checkboxes hidden on page 5.

as for TFA good luck, with the big complicated security mess that is PDFs? They are gonna need it. Personally I don't think having everyone with the same default PDF engine would be all that smart as it gives a common denominator for the bad guys to target. But then again I still think H.264 sucks compared to flash performance on older machines so what do I know.

Re:Wow

[DMiax]

the problem though is that they will never be able to test it on more platforms than those that have native pdf rendering. So it is unlikely that it will ever be advantageous over those. If we are going this way let's just download compile and run C code from the browser automatically. If anything it may be easier to write cross platform C than cross platform Javascript+HTML!

Re:Not impressive...

[dirtyhippie]

Umm, how is parent a troll for posting a link to the actual thing the top parent spoke of? He's not.

Firefoxen?

[tehcyder]

Whoever wrote that should just go and shoot themselves in the face a couple of times.

Re:Wow

[Tim C]

Except that you can expect the missing browser functionality to be added, or in the case of open source browsers potentially add it yourself.

Changing the laws of physics is a rather different matter.

Re:Wow

[funfail]

Reader 10 is still a large download but it loads much faster than, say, Reader 8 or 9.

I believe it is mainly because they don't preload plugins anymore.

Re:Wow

[Bazzargh]

the problem though is that they will never be able to test it on more platforms than those that have native pdf rendering.

Wrong. The test suite compares the canvas rendering against reference images (potentially generated on a different device).

Re:It's all images

[Bazzargh]

The big downside is that it's all images and you can't do all those fancy things you can do with text. Like select, copy & search.

I'm working on it. To get text out of pdf.js as is, you just implement a TextGraphics object (like their existing CanvasGraphics one) and just implement the text and coordinate transform commands. There's lots of ways of getting that into a copy/pasteable form afterwards, but its early days and I'm just coding up the OCR-ish algorithms needed to infer reading order from non-tagged pdf (the most common case).

I'm not associated with the project, but this is on their todo list too, and someone else might get it done before me. But it will be done.

Re:Wow

[arglebargle_xiv]

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.

Have you tried STDU Viewer? I switched to it after Foxit started trying to emulate Acrobat, it's small, lightweight, and reasonably good at rendering stuff, although a bit slow on page transitions sometimes. Another thing that impressed me was that I sent in a feature request, got a reply within 24 hours, and it was added in the next update.

And neither FoxIt nor PDF-Xchange render vector content with anti-aliasing correctly

Where can I get a sample PDF with this? I've just tried it with STDU Viewer and it seems to render at least diagonal lines with antialiasing properly, but if there's some test PDF that really shows it up I'd be interested in trying it.

Re:incomplete sentence?!

[arglebargle_xiv]

They cut the sentences into separate clauses to emphasise each of them ...

They cut. The sentences. Into separate clauses. To emphasise. Each of them.

FTFY.

Re:Adobe already did this!

[Celarent Darii]

Wow this post is incorrect on so many levels.

Java != Javascript. They are radically different languages, and if you had worked with either of them you would know that converting from one to the other is by no means trivial.

There exist quite a few implementations of a pdf reader in Java, sme of them opensource. Icepdf comes to mind but there are many others, even whole libraries of code for this purpose.

Javascript really has nothing in common with Java except the name. You can thank the market department at Netscape for that.

Re:incomplete sentence?!

[TangoMargarine]

...Thus making them non-sentences. Win.

Re:Wow

[jgagnon]

Changing the laws of physics is a rather different matter.

Black holes do it all the time! :p

Another JS PDF Viewer

[xyrka]

There's also another open source PDF project called Trapeze. It currently works in firefox, safari and chrome. Demo at: http://trapeze.xyrka.com/ Project at: http://code.google.com/p/trapeze-reader/ I even posted it to slashdot awhile back, but it never made it to the front page... http://slashdot.org/firehose.pl?op=view&id=17924850