Firefox introduces PDF viewer | Hacker News Reader

Firefox introduces PDF viewer

blog.mozilla.org

421 pointsriledhel194 comments

It's worth pointing out this is done in pure Javascript, and works by compiling PDF functions to equivalent Javascript functions which are then visible to Firefox's JIT. Despite being only around a year old, it still manages to render the majority of PDFs thrown at it (it's been my primary paper reader for the past 6 months or so).

As for missing features like some complex gradients, I can't say I've missed them, except on occasion when dealing with shiny PR materials. Earlier versions occasionally emitted blank pages, but these could always be skipped thanks to a side effect of the PDF format.

PDF.js has an amazing future for such a young project, and it is the foremost demonstration of exactly how complex programming tasks can be expressed using native web technologies. Turns out 35kLOC of Javascript almost completely subsumes the functionality of a behemoth native application (Adobe Reader) that on some machines would require half a minute just to 'boot'.

While Mozilla are pumping out stellar designs like this, Google are pushing crap like Native Client and their proprietary, binary-only Foxit Reader solution instead, complete with the hundreds of thousands of LOC of insecure C this entails. Rock on, Mozilla!

Please take your time machine and go release PDF.js in early 2010. With good performance on the hardware and Javascript VMs of early 2010. Then I'll grant you the criticism of Chrome's PDF viewer. Otherwise, trolling... fact is, Chrome is the browser that liberated the world from Acrobat Reader. PDF.js is awesome and it may be the way to go, but as of today Chrome's viewer is still much better -- please try http://www.irs.gov/pub/irs-pdf/fw4.pdf in both browsers and tell me which one is sluggish and renders so-so, and which renders/scrolls instantly and perfectly and also allows you to actually fill the form.

They both display about the same (nothing a casual glance could reveal). Firefox took ~ 1 second, while Chrome was slightly faster <1 second. It's hard to count. But it's about the same give or take a few hundred miliseconds.

My setup is FF 19.0 and Chrome 24 on Win7 with 8Gb Ram and 3.1GHz processor.

On average, I might need to fill out a PDF once or twice a year. Otherwise rendering for either one is perfectly fine for me.

This was just a random example. I'm sure if you take a statistically-significant variety of PDFs and benchmark rendering quality, speed and features in all PDF viewers out there, PDF.js won't be any closer to the top; Chrome's viewer will certainly not be the very best but not one of the worst either.

On the mac, Firefox Nightly loads the PDF in a second while Google Chrome Dev loads in about three seconds. I can enter text in the pdf in Chrome while Firefox gives an annoying little "The pdf might not be rendered perfectly" error bar at the top.

Let's try Safari: Loads in under a second maybe even faster, super quick scrolling, ability to enter text and the option to download the pdf on the bottom. This is the way browsers should handle pdf. We are just not there yet. I don't want to use Safari though. Firefox is the browser for me.

I almost always download the pdf anyways and view it through Preview.app, especially if I want to actually input text in the pdf. I love Preview. It's like the best PDF reader out there. Preview is what liberated me from Acrobat. Well, switching to the Mac did that for me, really.

I don't have firefox and a pdf view won't change that. Your description of Safari matches that of Chromium on Arch Linux.

Does Chromium have a built in PDF reader? I thought google adds that in for Chrome along with Flash?

It is not included, but can be installed. (libpdf)

https://wiki.archlinux.org/index.php/Chromium#Open_PDF_files...

I don't think that's right: I use Chromium on Arch Linux and it does not seem to have a PDF viewer. It always offers to download PDFs and open them with a separate program, often warning me first that PDFs from unknown sources can be dangerous.

To be sure, Safari is invoking a system level PDF reader to handle inline PDFs. That's what gets you that silky performance and nice rendering.

When you pop the PDF out, it then gets passed to the full Preview.app.

>> To be sure, Safari is invoking a system level PDF reader to handle inline PDFs. That's what gets you that silky performance and nice rendering.

Which, IMO, is the way it should be, and not just for PDFs. I'm impressed by the fact that Mozilla implemented a capable PDF reader in JavaScript, but I won't be using it. Firefox and Chrome are both trying too hard to duplicate everything my OS already provides: their own video codecs, audio codecs, image codecs, the Flash plugin (Chrome), now a PDF viewer, and so on. I'd rather just have my browser render HTML/CSS, run JavaScript, and that's about it. It doesn't have to implement anything else itself, all modern OS's should have everything required to display all the embedded content.

That only works if you don't care about fragmenting what features you support on multiple OSes, and trust those codes to do the right thing in all of your use cases for it.

For some of the browsers it's clearly better for them to bundle the kitchen sink, since at least it's their kitchen sink and guarantees the kitchen sink will always be there.

The main problem I see with that is security. PDF is a huge attack surface, reducing that to the already existing and well tested javascript surface is a huge win. Ideally (in my mind) every browser will come to use Mozilla's pdf implementation.

Ideally, I would trust my OS vendor and be safe using their superior PDF renderer. I think my ideal world is likelier to come to pass than yours, sad to say.

PDF performance is great on the Mac because Apple's 2d drawing system is actually based on the PDF spec. You can even "print" to a pdf from just about any Mac application that supports printing.

http://en.wikipedia.org/wiki/Quartz_2D

just a note, but you can do that in linux and afaik windows as well

on Windows, you can print to XPS out of the box, but not PDF.

From what I can gather Chrome's PDF viewer pretty much is Acrobat Reader. (It's also not available to users of the open-source version Chromium - in fact, as far as I can tell there's no decent way to read PDFs in Chromium at all.)

The pdf.js repository contains a Chrome/Chromium plugin, which works for me. YMMV.

The PDF viewer in Chrome is available to Chromium users (just copying the libpdf.so or libpdf.DLL file into the appropriate directory works); it's just not open source.

I think for most people, when they say "available," they mean "without copyright infringement."

As long as you don't distribute chromium with this file, then it will be fine. (You do it yourself).

I'm not sure what the rules are: Google gives me permission to install Chrome, and then, presumably I have permission to delete everything but the PDF viewer plugin, right? Maybe the Chrome EULA disallows this, but, to be honest, I didn't read it.

Ahhh. I couldn't find any information on how to do this the last time I looked.

It's FoxIt, not Acrobat.

Was early 2011 that different a place? Anecdotally, I've run PDF.js on a PowerPC desktop from 2005 with a late 2011 version of Firefox, and it was a bit pokier than I'd like, but it was usable for me.

(BTW: Apologies, it looks like I somehow fat-fingered a downvote on your post. Unfortunately there's no way to undo that on Hacker News. No slight intended.)

Mac users would say it was Safari. :)

Or OmniWeb before that. PDF in the browser? Congrats, you're only twelve years behind.

>Chrome's viewer is still much better

On Linux - both FF19 and Chrome Stable are very close. FF rendering is a bit jerkier than Chrome but not by much.

Since I'm blind Firefox wins every time over Google Chrome. I tried out the link you had in your comment and I can at least read some of the text in Firefox with my screen reading software. I assume this is because Firefox turns it into some form of HTML that is then accessible through the normal function of assistive technology. Google Chrome uses some kind of plugin that doesn’t provide any accessibility support so I get a blank page without any text. Even if the performance isn’t as good I’d much rather deal with things that are rendered to HTML and JavaScript.

This is a good point, but a separate issue (and kudos to PDF.js if accessibility was a purposeful design point of their implementation, not just a happy coincidence... they could certainly have chosen other avenues, such as generating a WebGL scene that would be opaque to screen readers). And Chrome's viewer should indeed be accessible, I'll raise this question internally.

For that to have been a happy coincidence is basically impossible with PDF. You're told a run of positioned glyphs to render, but then you have to figure out what text those really represent by looking at the font tables (even the simplest documents tend to contain ligatures)...and that's before you assemble the runs into sentences, paragraphs, columns etc, generally without help from the PDF, although it can optionally contain this info. The first version of PDF.js rendered positioned images of text runs, text extraction came later and was definitely deliberate.

(I was paying attention, as I wrote some of the code to do multicolumn text selection in poppler)

Bollocks. Chrome's PDF implementation absolutely sucks. I have numerous PDF documents which it can't handle at all. I've just opened them in Firefox 19 and they are absolutely spot on.

I'm uninstalling Acrobat reader for a week to see how it goes now. Chrome never gave me that.

Can you link them please? We already have links to PDF's rendering better in Chrome. I'd like to see where pdf.js does a better job.

Unfortunately not as they contain sensitive information (financial contracts).

> Please take your time machine and go [to] early 2010... Chrome's PDF viewer... fact is, Chrome is the browser that liberated the world from Acrobat Reader.

Fact check:

August 31, 2006: "Current versions of Safari are able to access PDF documents in a number of different ways. It can display the documents inline (in the Web browser window) without the use of a plug-in, it can use the Adobe Preview plug-in to display documents inline with added controls, or it can pass PDF viewing duties off to another application like Adobe Reader or Apple's own Preview.app."

http://reviews.cnet.com/8301-13727_7-10327228-263.html

"Google Chrome ... was released as a beta version for Microsoft Windows on September 2, 2008, and as a stable public release on December 11, 2008."

http://en.wikipedia.org/wiki/Google_Chrome

Safari, outside of mobile, just isn't used like Chrome is.

Chrome liberated us from Adobe Reader because its what we actually use.

Uhm... on my machine, the firefox version actually loads this just as quickly and with notably smoother scrolling? I guess it's the other way around on your machine. It doesn't allow form filling though.

Honestly I couldn't care either way. Even the acrobat plugin seems to be much better behaved these days, so...

Chrome's PDF viewer lacks the basic features one expects from a PDF viewer. It doesn't make sense to abandon the concept of pages or not support ToC. Those things are essential in PDFs. pdf.js handles all of those things. And there were browsers being able to display PDF before Chrome. KDE's Konqueror could simply load KPDF and Safari had Preview.app embedded.

I wish Google would abandon their viewer (which is closed source btw) and rather start using and contributing to pdf.js.

Your comment would've been so much better without its last paragraph.

It's lovely how one comment like that also manages to turn the whole thread into a them vs. us flamewar :-(

I don't understand the open source hate. Whether the code is open source or not makes a lot of difference. Not hating on google, but mozilla has this one right.

I thought one of the safety features of some pdf readers was the ability to disable javascript. How does that work here if this is entirely implemented in javascript? Disregard if I'm not understanding this correctly.

I believe the security feature is the ability to disable Javascript code that is included within the pdf file. A pdf reader implemented in Javascript is perfectly capable of doing that.

Not only that, but being able to render via js would (and thus avoid calling out to any plugin code) would be able to take advantage of sandboxing too I imagine.

How do you evaluate the PDF's JavaScript in an interpreter that is distinct from the renderer's?

Different layers of abstraction. JavaScript embedded in a PDF probably turns up as a string after being parsed. It doesn't necessarily get eval'ed. It's turtles all the way down, until you say no.

Let's hope there is the option to say no otherwise this couldn't be considered a general purpose viewer by some.

> While Mozilla are pumping out stellar designs like this, Google are pushing crap like Native Client and their proprietary, binary-only Foxit Reader solution instead, complete with the hundreds of thousands of LOC of insecure C this entails. Rock on, Mozilla!

Why are you dumping on Google? Their browser has been able to handle PDFs for years (including forms!).

Chrome's PDF plugin is closed source, and written in C. It is very useful, but not free as in FOSS.

And... ?

Something being closed source matters to some people. You might not be one of them, but other people might have different perspectives that cause them to value an open source option above a closed source equivalent.

Yes but the masses don't care if it's open or closed source.

No, but we should. For the masses that don't.

That the masses don't care about open source is reason to work really hard to educate them; not reason to not care either.

... from there comes most infections on windows PCs running chrome.

Source?

Actually, that would be Java.

Source? I don't believe this since so many levels of confirmation is required. I think the biggest source is the simple links to "KimKSexTape.jpg.exe".

Source: http://www.kaspersky.com/about/news/virus/2012/Oracle_Java_s... (Chrome uses its own PDF system, not Adobe Reader, so it's not even close to the threat level of Java).

Java has had multiple drive-by exploits discovered in just the past few months, which by definition don't require confirmation.

I was inaccurate, however. Java is almost certainly the cause of most exploits, but I daresay that user inexperience (to put it kindly) is probably the source of most infections. Touchè.

This is ridiculous. The foxit plugin is fully sandboxed and I have not seen any exploits via any of the netsec lists I subscribe to.

With a couple Google queries, you can find out that the Chrome PDF viewer has had multiple vulnerabilities that allow code to be executed in the sandboxed environment, and that there have also been Chrome vulnerabilities that allow sandboxed code to escape the sandbox.

Sandboxing is certainly a good thing, but it's not perfect. Sandboxed code still increases the attack surface. The rationale behind pdf.js is that, because it's almost entirely unprivileged JavaScript, it's unlikely that there's a way to exploit a browser in the presence of pdf.js that wouldn't work in the absence of pdf.js.

The browsers themselves have also been subject to such vulnerabilities. I dare say the attack surface of a full browser implementation is much larger than just the sandboxing, and sandboxing ideally sits behind all I trusted operations in the browser, providing a single common last line of defense.

It's not just a matter of open/closed source. Bundling in yet another C binary is only going to widen the surface area for security vulnerabilities for millions of people, and there's really not a great reason to do so anymore. PDF.js proves that it's possible to write high-performance javascript to do this stuff, without introducing any security risks and it's completely cross-platform. Computers are only going to get faster, and js compilers are only going to get better too.

But Chrome's works better and has been around (and useful for millions) for years. Perhaps they'll move to a JS solution in the future, but if I had to choose between the two right now I'd take the faster more complete one.

>But Chrome's works Citation needed, pdf.js has performed better for me personally than Chrome's viewer.

pdf.js supports PDF indexes (or whatever that's called), but AFAICT Chrome's doesn't.

JS-everywhere ideologues are always trying to buy a hamburger today and pay for it tomorrow. Someday machines will be faster. Someday the implementation will on par with the alternatives.

How it works today is what matters to users. Tomorrow the native stack will just make use of more hardware features, it will still be faster, and we'll still be having the same conversation that we'be been having with JS ideologues for 10 years now. "Someday ..."

This is what the XML ideologues used to say too. The problem wasn't XML, it was the libraries, or the lack of dedicated XML processing hardware. Then someone realized that if you got rid of the core complexity -- XML -- you could stop layering on piles of additional complexity while trying to work around the root of the problem.

Someday...

That has nothing to do with anything. If you're just having a dick measuring contest, Google has contributed a ton to the open source community. Google also provides nearly 100% of funding for Mozilla.

Open source is not about smelly dicks, it's about transparency, reusability, philsophy, politics. It's a lot of things (and they matter, because right now, society and technology are changing fast).

I am not against your main point but I am sure that Microsoft will provide at least 110% of funding if Google pulled their "funding".

If Microsoft were willing to provide pay as much or more, why aren't they doing it already to make Bing the default search engine?

Perhaps they had made an offer. We never would know.

We don't even know the details of the Mozilla-Google deal. For all the openness that Google and Mozilla appear to proffer, the agreement between them is a secret.

Mozilla has been saying for years that they will use the best engine, and take that engine's money if it's available. If Bing were clearly better than Google, they'd switch and be taking Microsoft's money.

They have said that during the time they are being offered the most money by the best search engine. That's easy. But Google keeps paying more which means Mozilla is after the highest bidder.

That is not how Mozilla's decision making works. There's considerably more to it than such simple economics.

As a non-profit, we are here to create a public good. It's actually goods, plural, and services too. Firefox and other Mozilla products and services exist to promote the Mozilla mission, not to enrich the Mozilla organization.

Yes. Sustainability is certainly a factor in some of our decision making. Mozilla would be foolish to ignore significant opportunities to increase its mission impact. But revenue for sustainability is not the sole or even the dominant factor in any major product decision at Mozilla.

My guess would be that if the offer is similar, Mozilla would be inclined to stick with Google. I'm sure you know how irritating it is to realise you missed a checkbox and now your homepage and default search are set to Bing - it's probably a user experience Mozilla was happy to avoid.

Plus, there are probably some advantages to having Google 'on side'.

If you're in the US, you may not notice it, but Bing is plain awful for international users. Google has spent a considerable amount of resources improving their engine to serve results based on your location and Google's Search Engine is clearly the best by a long shot. This is also why I'm not using DuckDuckGo.

Agreed. If Bing could match google's accuracy in scholar paper/reference searching I'd not mind to use it.

Bing on the other hand is much better than Google if you are searching for technical info on Microsoft products.

This product already exists, in at least proof of concept form: http://www.firefoxwithbing.com/

I think this is sufficient to show that they're at least thinking about it.

"Sorry, this download is not supported by your system." Meh.

For the average end user, it may not particularly matter that Mozilla's PDF implementation is open source and Google's isn't. However, for people like me who want to implement PDF-related functionality in their web/desktop application, it matters a great deal.

Chrome's built-in PDF plugin is actually from a Chinese company called Foxit.

http://googlesystem.blogspot.com/2010/08/google-chromes-pdf-...

Now start China bitching.

I've been using Foxit reader for years without knowing that it was Chinese. Its a great product - fast as hell - beats the pants off Adobe.

I'd started using Foxit for the same reason. But the speed advantage is no longer an issue. Adobe had closed the gap and Acrobat reader now loads just as fast as Foxit. Besides, Acrobat's rendering is far superior to Foxit's (not to mention Foxit fails to load some PDF document or displays garbage)

Acrobat is the new Foxit nowadays!

My problem with Adobe is that whenever I install any of their products I get the feeling I've just made my system more vulnerable to malware and the like. They've got an atrocious record when it comes to security bugs.

E.g. look at the size of this page: https://www.adobe.com/support/security/

I've not found anything that is even close to on par with Acrobat for fill-in PDF forms either.... Other viewers can sort-of handle it, but the results don't look right most of the time.

I like MuPDF. It doesn't really have an "interface" though. Just page-up, page-down, and +/- to zoom. But if all you're doing is reading pdfs...

The Chrome PDF Viewer is not really useful. There is no table of contents. You can't jump to specific pages. And so on. It is also closed source.

I wish Google would rather abandon their current viewer and start contributing/using pdf.js.

Google's PDF viewer refuses to save PDFs opened via the websites of some scientific journals. I'm not willing to play the proxy game every time I want to read journal papers so I save them locally. I stopped using Google's PDF viewer because of this misfeature.

Can you provide a citation or an example link for me to test? My understanding is that Chrome has the foxit plugin in a fully sandboxed environment. The PDF format nor the foxit system has any kind of DRM and shouldn't support this behavior.

There isn't any DRM, the plugin is just listening to a "suggestion" that it not let me save (no error, it just doesn't do anything when I click the save icon). Everything on ScienceDirect has this property. I just tested with this paper from my RSS feed (Chromium 24.0.1312.70).

http://www.sciencedirect.com/science/article/pii/S0045782513...

I'm using Chrome not Chromium, and there's no save icon. Are you sure you aren't viewing this in a proprietary viewer? Typically you should be able to right click and get a save as option.

I just confirmed that the same occurs with Chrome 24.0.1312.52 (Official Build 175374). I'm quite sure that I am viewing it in a proprietary viewer. Specifically, the Chrome PDF Viewer. Surely you've seen these buttons before?

http://i.imgur.com/80dO12V.png

In both Chrome and Chromium, clicking save here does nothing and "Save As" is greyed out in the right-click context menu. "Print" works in Chrome (though it takes time to produce a preview before I can print to PDF), but locks up Chromium.

This anti-user bullshit is usually less prevalent in non-proprietary software.

So long as you use their proprietary, binary-only version of it. The open-source Chromium cannot display PDFs, and as far as I can tell there's no way to make it capable of doing so.

Gmail, Google Calendar, and Google Docs are huge JavaScript web apps that run in all modern browsers and have enormous user bases. They form a huge part of Google's business. Additionally, Google develops, maintains, and promotes popular JavaScript developer tools like Closure Compiler, AngularJS, and the Chrome dev tools.

Are you implying that everyone should just shut down all R&D in web technologies that compete with or don't use JavaScript?

Your last statement is way overstating the original remark about NaCL. Google has definitely been pushing PNaCL as the solution for running large, complex apps that are usually native (like 3d games, and things that require lots of computation) on the web. And there's no way PNaCL is going to be viable in the next decade, it takes way too long for everyone to agree & implement.

Gmail, docs, etc are complex, but don't require tons of computation. They just require good web technologies. Google's work in this area is awesome, but that doesn't mean we can't call out PNaCL as a bad technology to push.

One of the major reasons PNaCL is "non-viable" are the comments like this one, calling it non-viable, and insisting on a JS-everywhere future.

If Mozilla et al spent half as much time trying to work with Google as they spend badmouthing everything that isn't JS, we'd have some solutions by now. These are political problems, not technical ones.

http://news.ycombinator.com/item?id=4632410

Yes, I think that demonstrates my point, given that the author is Brendan Eich, CTO of Mozilla.

Mozilla has had years to contribute something meaningful to the conversation, and instead they've consistently badmouthed Google's efforts while watching the meteoric rise of native mobile development.

So now they've finally brought asm.js to the table; a Mozilla-flavored common bytecode, which is what we've been wanting for years, and exactly what Eich and Mozilla said was wrong for the web: http://en.wikipedia.org/wiki/Google_Native_Client#Reception

Fine -- if using javascript to encode a bytecode is what it takes for Mozilla to actually take the need for a common bytecode seriously (and admit that DOM/JS/HTML/CSS is perhaps not adequate), then I won't look a gift horse in the mouth. I just wish they'd figured out the need for post-JS webapps a little sooner.

i think his gripe was more with proprietary solutions and not really !javascript, as you imply.

what you did would be the same as if i replied to you:

Are you implying that everyone should just shut down all R&D in web technologies and just choose between NaCl or ActiveX?

It's really pretty good (and i've been using it for a while on firefox nightly), but unfortunately it uses lot's of memory, scolling past 4-5 pages on math heavy papers usually kills my old 1gb ram pc.

Given how well PDF.js runs using Mozilla's JS engine, I have to wonder how well it would perform with V8.

You can try it out for yourself here by loading this URL with Chrome: http://mozilla.github.com/pdf.js/web/viewer.html

That's outstanding, even if the graphical figures still need work.

Yes but native client is conceptually an excellent and secure way to run native code.

To be fair, Reader does a lot more than simply display PDFs. Not of course that that makes PDF.js any less impressive.

If this based on pdf.js, because after being initially thrilled by it, we found it to be unusably buggy on all major browsers.

While pdf.js is a cool project, the last paragraph sounds too biased. Despite being open source / in native javascript, Firefox is still late to the party in terms of viewing pdf in a browser. Coming up with a better solution TWO YEARS later than the competitor doesn't seem that impressive.

"Google are pushing crap"

Is Google plural?

it's not ready for prime just yet. Tried it with my AI-slides, and slide 12 does not render at all. http://www.idi.ntnu.no/emner/tdt4171/slides/Lecture6.pdf

You spent the first three paragraphs excusing its failings, and then the last one taking lot shots at Chrome/Google.

Since when has it been more important to meet some developer ideal (JS everywhere) than to provide the best possible product and experience to your customers?

If you want to try PDF.js from your current browser, here's a demo:

http://mozilla.github.com/pdf.js/web/viewer.html

I wonder what's keeping this so ugly in Chrome. Also, does anyone know if printing is intended to work? It doesn't appear to have the pagination right, again at least on Chrome.

Almost bearable in MobileSafari on my iPhone. Almost... well, I guess the limiting factors are mostly under Apple's control, not pdf.js's.

Self-reply: judging by its performance in desktop Safari versus other browsers, this is really the fault of Apple's (closed source, so I can't really properly diagnose) rendering code - the other browsers performed much better.

Looks much better than I imagined. Also painfully slow.

I've got an i5 that runs it smooth like butter.

Most of the PDFs i read are electronics datasheets and they don't look half as good and it also seems to be missing the bookmarks as well. Scrolling through pages also seemed to take a long time.

I think i will have stick to adobe reader for now

This is really impressive. I tried in both my FF 18 and Chromium, it seems to work fine in both, although I prefer the font rendering in Firefox. This truly is an amazing use of JS.

PDF.js rocks!

Now, stay tunned for ASM.js because that too will rock (once it is ready).

link: http://asmjs.org/

Love it, but unlike Chrome's embedded PDF reader, it can't "stream" PDFs (a dealbreaker for people viewing media-heavy PDFs on slower connections)

That's interesting, because PDFs are an inherently un-streamable format. It requires seeking within the file to work (hence why command line PDF tools can't take STDIN for the PDF file - or they fake it by copying to a temp file first).

I wonder how google got around that problem.

You could try to progressively render the file, pausing when a required forward reference isn't within the data you have downloaded so far.

That seems to be what they do, in my experience.

engineers gonna engineer

Well, I imagine that they download the file in the background, and if the viewer seeks to a non-downloaded part of the file, then it just blocks with "Loading" until that part is downloaded.

"Linearized" PDFs have extra info up front to allow streaming and random access (via range requests).

Actually, PDF files can be optimized for streaming: http://acroeng.adobe.com/wp/?page_id=27

It's covered in Annex F of the PDF spec: https://wwwimages2.adobe.com/content/dam/Adobe/en/devnet/pdf...

If I remember correctly the PDF Spec says the files should be read backwards. The object table is at the end of the file.

We're working on that https://github.com/mozilla/pdf.js/pull/2719

It fails with the 4th google hit for "sample pdf":

http://www.inkwelleditorial.com/pdfSample.pdf

(The main difference I see with Firefox 19 on win7 is that it loads pages significantly faster.)

Seems to render fine for me in FF20 on W7: http://i.imgur.com/G5PPEbN.jpg

Thanks for mentioning this problem. I filed a bug for this issue: https://bugzil.la/843220

Is this still an issue with the development version? https://github.com/mozilla/pdf.js#extension

I tested it on Windows and it 'works for me'.

I had dedicated PDF plugin installed [1]. They had no reason to switch to Firefox-native PDF rendering as the default for PDFs before getting some maturity to it. The very first PDF I encountered [2] won't render fine in it though it does very well in the dedicated PDF application [1].

[1] http://www.certifiedmastertech.com/1410/mechanicssecretspdf1... [2] http://www.tracker-software.com/product/pdf-xchange-viewer

What rendering problem do you see with the "mechanics' secrets" PDF? AFAICT, it looks fine with Firefox 22 on OSX. What OS and Firefox version are you using?

Latest version of Firefox (32 bit) on Windows 7 x64 (fully updated).

The PDF shows up as blank other than the image on the very first page.

I figured. I use the following color settings in Firefox.

- Use system colors (checked) - Allow pages to choose their own colors, instead of my selections above (unchecked)

The problem goes away if the last item is checked.

Firefox by itself, nearly all websites, as well as my native PDF application, all work right with these and such settings. Firefox's new PDF functionality does not.

In any case, I reiterate my point. It was not a good decision to add this functionality to Firefox and right away switch the defaults.

Thanks for investigating the steps to reproduce the bug. I filed a bug report: https://bugzil.la/843473

It sounds like PDF.js has made some incorrect assumptions about default text colors. :\

Dumb question: What's to stop Chrome from eventually adopting PDF.js?

Personally, I see that as the future. Its open source, its "good enough", and Google doesn't have to license the pdf viewer anymore.

Also it's a big coup against Adobe, when everyone with firefox and chrome can pretty much uninstall your Adobe Reader software. I haven't even mentioned shrinking the market on 3rd party PDF viewers.

Nothing!

pdf.js is already a part of the Octane benchmark and works well in chrome:

http://mozilla.github.com/pdf.js/web/viewer.html

Mozilla is about moving the web forward, not just beating the other guy, so I don't imagine there'd be any gripe with Google picking up pdf.js in chrome.

There is already a Chromium plugin for pdf.js available. I hope Google starts using pdf.js so far it's better than the Chrome pdf viewer except for the startup time.

A lot of people are under the misconception that Firefox and Chrome are rivals, but the opposite is the case. They both have the motto of "furthering the web", however you want to interpret it.

As for Reader, Adobe probably don't really care if others come along. Acrobat is the main product, and the fact that other PDF readers exist just gives people more reason to buy it. PDF is also an incredibly large specification, full of crazy features, and I think Reader might be the only one that implements all of this functionality.

Nothing stops Chrome, or even IE, from adopting PDF.js. Not even the license (Apache). Personally, I'd like to see it happen.

That depends on whether they think it mathes the native implementation in compatibility, performance, and price.

My hope is that they wouldn't replace the current implementation simply because the JS implementation is free, and the JS implementation is never going to be as fast as an effecient native implementation, and its always going to be more difficult to write.

Before this patch, this is usually how I would open PDFs in Firefox:

"Okay, so I clicked on the link. Wait - where's the Download box? No, wait -- I told Firefox to download this MIME type automatically, right? Okay, but where is Evince? I thought it would load after I downloaded it. Okay, let me cd to Downloads, it's probably there. Okay, now I have to open Evince -- no, wait, I can just open Thunar to open it because the .pdf MIME is associated with Evince. Okay, so now I have to launch Thunar... Okay, now where is my Downloads folder again?"

Granted, it would be easier if I weren't such a blockhead, but it's still a royal pain in the ass.

It's nice to have such an option, but it feels significantly less snappy than Kparts plugin in KDE which wraps Okular into Firefox.

True, as with plain Adobe Reader. I spend a large part of my day reading .PDFs, both in and out of my browser, and Firefox became a much less effective "power tool" when they took the liberty of disabling the Reader plugin. I couldn't care less how long it takes to load a .PDF -- snappy rendering and navigation is everything, and you don't get that from JavaScript.

It took a surprising (to me) amount of hacking to re-enable native .PDF rendering. As far as I'm concerned, pdf.js is one of those increasingly-common cases where Mozilla has unilaterally decided that it knows Just What I Need, and followed up by attempting to impose it without offering me a choice.

I don't know what you did, but i can easily change that by changing the default action for PDF files in preferences -> Applications.

I've been using PDF.js myself for i think a year now (Used to install it directly from their Github page), and it's a great reader if you aren't an heavy PDF user. I barely have to open a PDF, and when i do it's usually just text and images, not any fancy stuff. And i guess most computer users are just like me. If you open PDFs all day, and are a power user, i guess that nothing can replace a good standalone reader.

It's still kinda slow, but it has done some incredible progresses in the year i've been using it. And i'm sure it will just get better and better.

I didn't have any issues at all enabling my foxit reader plugin for firefox. I actually had to specifically enable pdfjs in about:config to get it to run.

It didn't take me much hacking to enable native PDF plugin back. Searching in about:config for "pdf" quickly revealed pdfjs.disabled setting, which I set to true - and that's it.

Ditto. I'm perfectly happy with plain Reader (well, at least with versions 9 or 10). I've tried a lot of alternative pdf readers and none has replicated both the nice rendering of the vanilla reader as well as the scrolling behaviour (hand tool and middle click scrolling).

What I don't understand is why Google doesn't have an open source PDF viewer? I mean, Chromium renders OpenGL, decodes movies, contains fastest JavaScript VM and it cannot view PDFs? Given what they did to JavaScript speed, can you imagine what viewer they would be capable of producing of? At least they should join Mozilla on improving pdf.js, IMO...

Chrome already has its own PDF viewer, presumably implemented in C or C++ or whatever, so they probably don't care about making it available for Chromium. Perhaps they bought the rights to the source code they based it on, and are unable to open source it.

Google pays to ship FoxIt's closed-source PDF engine with Chrome.

...and it displays your visited sites in a grand panorama on the canvas in a new tab, despite having asked for always private browsing.

It could be a regression of both the browser, and the unit test, which isn't such a good news.

If this is the case for you please file a bug - a lot of private browsing changes have been occurring under the hood in preparation for proper per-window private browsing in FF21, so it's very possible a regression snuck in :(

The visited sites view is possible to disable (either under settings, or, at the very least, about:config + search newtabpage (or something along those lines, I can neither remember or test it)), and there is a small symbol in the top right corner that hides the site display.

(Admittedly none of those solve the underlying problem of history being preserved.)

I've been using it for about a month. It's my default PDF viewer, on my desktop - though sometimes it has choked on a file, and search has been an issue on large files.

Generally though, it's a good solution that doesn't require dealing with Adobe updates all the time.

Is this based on pdf.js? I couldn't seem to find out quickly. If so, very cool!

Edit: I was being lazy, it definitely is. Very nice that it's plugin-free and a pure HTML5 solution.

I've been using it for while (it shipped before but wasn't enabled by default; which I did). It works great most of the time, and is hassle-free. It's also likely safer to use.

Now, if only Gmail would let me preview attachments in it. They do it for Chrome's plugin. I tried messing with the URL arguments, but it seems the Gmail server won't even give you the inline (ie not a download) version of the PDF if your browser doesn't pretent to be Chrome.

I would love to have a PDF viewer app for OS X based on PDF.js. Better still if it could be sandboxed and have other enhanced security.

Just tried out Firefox 19, and the PDF reader is good. Responsive enough, with just the barest hint of render lag. Minor nit: Firefox isn't currently registered as handling PDF, but will still open it happily.

EDIT: I have Firefox as my OS X Mountain Lion's PDF viewer app now. Works quite well!

Any particular reason? OS X natively supports PDFs (and is both much faster and more complete than pdf.js).

Preview has had a history of security holes. PDF.js would at least be immune to buffer overflow exploits.

I've been using this for a while in Firefox beta, and it's generally really good.

I have two small problems with it, which perhaps won't be too hard to fix:

1. PDFs of old academic papers that are just strung-together CCITT (fax) compressed monochrome scans. Preview.app, Adobe Reader and Chrome resample those to give a readable quasi-anti-aliased effect. PDF.js makes the text jaggy and spindly and hard to read.

2. No back/forward navigation.

I've been enjoying Pdf.js for months, as I use Aurora as my main browser. Aurora[1] is the the first step before Firefox Beta.

If you want to use awesome features like pdf.js earlier... get on Aurora. It has been surprisingly stable channel for pre-beta code.

[1] http://www.mozilla.org/en-US/firefox/aurora/

Impressive piece of Javascript, but it's quite heavy on my CPU. I will continue using Evince for the time being.

We have a major in house application that displays PDF files as a core part of its functionality.

The Firefox PDF reader is very slow compared to Chrome's.

Also, the second and subsequent PDF files you click on do not commence the display at the top of the page, the appear to commence display somewhere down the page, I'm guessing maybe at the position that the previous PDF scrolled to. So immediately you need to pull the scrollbar back to the top before you can start reading the PDF.

So for now, just on speed alone we'll pass on the Firefox PDF reader.

This is really amazing, but I wish these two browsers would be pushing for a FOSS version of PDF instead.

I do not think openXPS is entirely FOSS but it is a good place to start looking for an alternative.

Here is an xps file on the web to see how your browser handles it: http://www.rosebudschooldist.com/images/Feb%20Cal%202013.xps

Thanks for doing this, but it is not working well for me! It takes way longer to load than a normal PDF viewer, is slow, and basically I gave up and closed it when pages were still black, or white, with a rotating loading indicator, minutes after a regular PDF viewer already showed it. This in Linux.

Thanks!

just tried it on a large PDF. Chrome takes about 1 second to load while FF takes 10, and the visual result in FF is nearly unreadable (while in Chrome it looks just like it does in Acrobat). i'd love to have nice open-source native PDF support, but this surely doesn't cut it for release.

If this is the future of computing, then I quit. I don't want to play anymore.

Interesting. I was wondering why I had to re-enable FoxIt viewer after the latest Firefox update. Maybe it works well for some PDFs, but the first two I happened to open were formatted pretty badly.

What, this is not what a web browser is supposed to do.

How about web browsers showing you graphics? Animated graphics? Videos? 3D graphics?

Not locally.

how is pdf.js gonna be updated in firefox... i was using the dev version add-on of pdf.js and seems to work better than the one shipped in FF19

Don't miss the announcement that Firefox for Android now supports ARMv6! Many ~$100 Android phones now have the option of a better browser!

As a pure Javascript solution, it can run on a wide variety of platforms, as far as the browsers are running.

Works well, looks sleek, and only randomly locked up once (To be fair, I had tons of tabs open).

Good job!

Is there anyway to change the background/foreground color ?

what happened to doing one thing and doing that well? what is next, office documents?

It does only one thing. Firefox doesn't depend on PDF.js and vice-versa, they're just bundled together.

Serious question: what took so long?!

Perhaps they gave up waiting for your implementation.

The experience on Android phones is solid but this core feature is really late to the game.

I love firefox but cant keep using a browser thats always playing catch-up

I really like Chrome and use it when developing just for webkit inspector but I can't switch to it for regular browsing as I still feel like Chrome can't match the browsing experience of FF. For example:

Tab Management

In firefox I can much more easily have dozens of tags without them all becoming squished. Instead I get scroll bars and a drop down menu.

With tab mix plus, tabs which I haven't read yet are highlighted.

I also have a close tabs to the left option in the context menu (which I really love).

Adverts

Adblock in firefox seems to be much more stable than the chrome alternative and just does a better job generally of blocking adverts. (This one might be solved by the likes of privoxy but then I lose the tight integration with the browser.)

Password Management

I'm a regular user of last pass but in chrome it can't integrate with the http auth dialog which means I'm forced to open up my vault and copy and paste my credential manually which is a huge hassle.

I really like Chrome and I'd love to use it all the time but these things (and a few others) prevent me from doing so. Does anyone know if there are any chrome extensions which address these issues?

Re: your LastPass Chrome problem, you need to install the extension with a binary component (there are two on LastPass's site)

Why is this news except the fact that Chrome has had this for years? Was Adobe paying Mozilla in the same way that Google paid them for the search bar preference?

I think the point is (from my other comment) this doesn't use a plugin, so is more secure (no Adobe security problems). It's based on pdf.js if you want to find out more.

Chrome's support is based on a licensed copy of FoxIt reader that they bundle in their binary. This also means that Chromium doesn't support it. The Firefox one is all open-source, as well as being based on pdf.js.

Adobe was not paying Mozilla for anything like that. Chrome simply includes a paid closed-source product (FoxIt, iirc). This was and is not an option for Mozilla for multiple reasons.

It took Mozilla a while to get here, which is unfortunate, but the result is an open-source PDF reader that doesn't add yet another binary rendering engine to the browser (think security, hack-ability). Creating it made Gecko and the web platform better, because it pushed us. There is more work to do, but it's a great start and a welcome change to how these features are implemented.

A bit more info in a blog post that I wrote:

https://boomswaggerboom.wordpress.com/2013/02/19/exciting-st...

Interestingly, there are also a prototype Flash in JavaScript called Shumway: https://github.com/mozilla/shumway

And an IIUC a DOM renderer in JS https://github.com/andreasgal/dom.js/

I don't know if PDF.js will ever reach full PDF compatibility (with all it's weird forms and other stuff), but I do hope so. With a liberal licence I can totally see people embedding pdf.js to render their pdfs on site.

Reply on news.ycombinator.com