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.
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!
(I was paying attention, as I wrote some of the code to do multicolumn text selection in poppler)
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.
When you pop the PDF out, it then gets passed to the full Preview.app.
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.
I'm uninstalling Acrobat reader for a week to see how it goes now. Chrome never gave me that.
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."
"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."
Chrome liberated us from Adobe Reader because its what we actually use.
My setup is FF 19.0 and Chrome 24 on Win7 with 8Gb Ram and 3.1GHz processor.
I wish Google would abandon their viewer (which is closed source btw) and rather start using and contributing to pdf.js.
(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.)
Honestly I couldn't care either way. Even the acrobat plugin seems to be much better behaved these days, so...
On Linux - both FF19 and Chrome Stable are very close. FF rendering is a bit jerkier than Chrome but not by much.
Why are you dumping on Google? Their browser has been able to handle PDFs for years (including forms!).
Plus, there are probably some advantages to having Google 'on side'.
I think this is sufficient to show that they're at least thinking about it.
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.
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.
Now start China bitching.
Acrobat is the new Foxit nowadays!
E.g. look at the size of this page:
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.
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è.
I wish Google would rather abandon their current viewer and start contributing/using pdf.js.
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.
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.
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.
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
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?
Given how well PDF.js runs using Mozilla's JS engine, I have to wonder how well it would perform with V8.
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?
Is Google plural?
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.
I think i will have stick to adobe reader for now
Now, stay tunned for ASM.js because that too will rock (once it is ready).
I wonder how google got around that problem.
It's covered in Annex F of the PDF spec: https://wwwimages2.adobe.com/content/dam/Adobe/en/devnet/pdf...
(The main difference I see with Firefox 19 on win7 is that it loads pages significantly faster.)
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.
It sounds like PDF.js has made some incorrect assumptions about default text colors. :\
I tested it on Windows and it 'works for me'.
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.
pdf.js is already a part of the Octane benchmark and works well in chrome:
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.
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.
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.
"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 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'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.
It could be a regression of both the browser, and the unit test, which isn't such a good news.
(Admittedly none of those solve the underlying problem of history being preserved.)
Generally though, it's a good solution that doesn't require dealing with Adobe updates all the time.
Edit: I was being lazy, it definitely is. Very nice that it's plugin-free and a pure HTML5 solution.
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.
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!
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.
If you want to use awesome features like pdf.js earlier... get on Aurora. It has been surprisingly stable channel for pre-beta code.
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.
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
I love firefox but cant keep using a browser thats always playing catch-up
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).
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.)
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?
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:
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.