'PDF goodness' is a purely theoretical concept, IMHE. I'll not use any of my time testing that belief ever again, but would love to be able to abandon it... fingers crossed.
The web serves files. Some of them are HTML, some of them are not. I don't have a problem with web browsers displaying anything that has a standard defining it.
Of possible interest to people wondering about security of PDFs is that the current Honeynet Project Forensic Challenge requires analysis of a malicious PDF.
Not a direct link with Google, although it looks like the project itself is fairly active with Google Summer of Code.
The more accurate "PDF decreased badness" doesn't roll off the tongue quite as well.
But I must take issue with the way you make a distinction between viewing documents and surfind the internet. A lot of web content, unfortunately, happens to be in PDF format. Why shouldn't your browser support quick-and-easy viewing of PDF files?
You're asking a really good question, but if you'll may I think you're asking the wrong one.
To answer your question, why shouldn't your browser support quick and easy viewing of PDF files, I think the answer is that my browser's job is to render HTML downloaded over a given protocol (such as HTTP or HTTPS) and appropriately supported non-plugin extras as best as possible.
For example, I have a virtual world. This virtual world is designed for a niche, lets say vehicle mechanics. You can look at any vehicle and strip it down or away to see each layer like an onion skin in my world. Why should your browser do that instead of giving it over to a plugin by the format company's author?
If your browser does that the people that write the browser have to support it to a certain extent - if they implement the popen() function in the spec, well they're importing the standard into the browser but if popen("/bin/ls") works then so should popen("/bin/ls;cat%20/etc/passwd").
My point is that the people that make browsers make really great browsers, the people that make PDF readers make great PDF readers. To pull the browser guys off to make a PDF reader is the same as pulling a PDF reader guy to make a browser, it's not their core business.
I'd rather trust a company for whom PDF reading is core business (like sumatra) than those that feel PDF reading is only part of their revenue stream (like adobe).
PDFs are such a huge part of the internet, especially in academic and scientific circles. This (soon to be) stable feature inside the browser is amazing for finally providing a seamless experience when browsing PDFs online alongside webpages. There's no performance hit, no giant plugins to install, no Adobe Update Manager yelling at you every 15 minutes to update, restart your computer, and put the shortcut back on your desktop. The instant you click on the PDF it's available. A lot of people are reporting that they didn't even realize that they were looking at PDFs after the update. They just thought it was another webpage. That's how well integrated it is.
Great job Chrome Devs, you're really setting the browser ahead of the pack.
I appreciate the good news from Google, but I've often wondered why PDFs are so important in 'academic and scientific circles'. It seems that some sort of HTML solution would ultimately work better. It's certainly a very flexible format, easy to annotate, and easy to search. I'm often frustrated by the the difficulty of searching a large collection of PDFs or providing clean annotations when I'm reading papers. I still looking for tools that are good at both of these things.
Why don't we use HTML or something similar for making papers available?
I've wondered the same thing myself, and I haven't come up with an answer I like. I think the reasons are mostly historical. Conference and journal proceedings are still literally printed, but - at least in my part of CS - most people read them on the computer. I'll print out papers that I think are really important, but I could do that with HTML, too.
I think it will take time or better technology to overcome the bias that we have when we see a good looking pdf document. It says "professional" in a way webpages don't, although I recognize this is completely irrational.
Papers are, as the name implies, intended to print on dead trees. At least in the academia world you'd like to be published. PDF is the (only?) solution that allows dot-perfect control on paper.
No web technology currently addresses this issue in a satisfying way, not to mention lack of complex math/chemistry/etc formulas. Even the use of specialized symbols on the web is pain.
HTML is not even close to provide the level of support needed for math in scientific papers. Using HTML is like going back 30 years, when we had things like troff, and later TeX.
My worst experience on Chrome or any browser isn't Flash or a suite of extensions I am using. Most of the pain comes from Acrobat integration that locks up a core at the worst time with all Chrome tabs seizing to function and a Chrome tab process to crash soon after. Any alternative to Acrobat is welcome, especially one by Google that can integrate seamlessly, and will allow me to finally left-click on a link to a PDF instead of downloading and opening the document separately.
I've always been impressed by Safari's integrated PDF reader. It's still more polished than what Chrome has, though I look forward to Chrome closing the gap before too long.
Is it just me, or is there anyone else on OS X thinks the rendering of the default Preview.app is so much better than Chrome?
One of the few reasons I constantly bounce between Safari and Chrome is the ability to render PDF beautifully. I haven't yet seen a better PDF rendering engine than the OS X built-in one.
I really don't understand what the big deal is with PDF support. If I click on a PDF I'd rather it download to my computer and gets opened with the appropriate application, rather than using developer time in a feature that feels out of place within Chrome.
This feature has been available in the dev channel of Chrome for ages, and until now it's still unstable. PDF's tend big documents, and it's generally the case that Chrome locks up and ends up crashing when opening a PDF that's more than a few pages. This defeats the purpose in my opinion. The moment I notice I'm loading a PDF in Chrome I go ballistic trying to close the tab to avoid the crash.
I'd rather have developers improving the bookmark manager than trying to make a browser a PDF reader also. And a bad one at it. This makes me want to go back to the Chromium nightly builds. Those where awesome and bullshit free.
This is where one of the few cases Chrome is aiming at cross-platform support at the cost of reusing native functionalities.
Every OS X and most Linux desktop distros are capable of rendering PDF natively. Personally I think OS X default PDF viewer renders much better than Chrome. They should just reuse it.
Similar thing for H.264 playback. AFAIK Chrome use ffmpeg to decode H.264 and WebM content. It's fine if there is no native codec to do that (H.264 on Linux, WebM on all OS). But on Windows 7 and OS X where hardware-accelerated H.264 playback comes by default, they should reuse that.
I have a fear that if they continue to do so (invent their own not-so-good stuff instead of reusing existing and better tech), one day Chrome will become the cross-platform shit that can run on every OS but not good on any one.
But almost all browsers have a PDF viewer plugin, and in general they're almost always terrible in some way or another. The problem is that PDF's are almost always very long documents, and a lot have embedded images, which results on the plugin crashing, the browser crashing, huge memory leaks, or at the very least decreased performance.
To be fair though, maybe I'm not the target market for this feature, but I find it way easier to just download the file and have it open in Preview, than to have to work with Chrome's implementation.
It's quite a decent and neat feature if you have to read a lot of PDF's (i.e. academic paper hunting): you can quickly scan through the PDF opened in your browser and decide if you want to actually keep it. Otherwise the PDF will just be downloaded to your Download folder and then you have to read through them and clean up those unwanted.
That being said, I don't like Chrome's implementation though. Usually switch to Safari for "PDF mode".
This. I moved back to Safari because with Chrome it's so painful to do paper hunting. It's much easier and fast to skim over and then decide which ones to save and read.
And additionally, when the paper opens in-browser, the location and browse history that got you to that paper is preserved. So when you're in the web browser and see the pdf of the paper by I.M. Smart and A. U. Thor, you can tell whether you got it from Smart's site, Thor's site, or somewhere else.
I wonder how this will affect Google's online PDF viewer [1]. On one hand Google can clearly provide a faster experience by rolling their own client-side viewer, but on the other an online viewer can be used across browsers and devices, and more easily integrate with Google Docs.
The feature has been in the dev channel for weeks. I am glad they decided to implement pdf support in the browser, and I love the speed at which it works. I also love the lack of chrome and the ability to right click on the pdf and save it.
However, the Foxit software they are using is not very good IMO. I had it installed previously on my machine, and it crashed a lot with files over 20 pages. Now Chrome crashes almost every time I open a large PDF file.
So, I uninstalled Foxit Reader and reverted to Acrobat. It is slower to open, but doesn't crash nearly as much as Foxit.
Why didn't the Chrome team incorporate the original Adobe Reader instead of Foxit?
38 comments
[ 4.3 ms ] story [ 79.6 ms ] threadDon't get me wrong, I like Chrome (in fact I'm using it now) but it's a browser. I don't want a document viewer, I just want to surf the Internet.
As smart as the Google guys are, PDF is a mess of a format. Why should we think that Google are better than anyone else at implementing one safely?
Not a direct link with Google, although it looks like the project itself is fairly active with Google Summer of Code.
Edit: link for interested parties
http://project.honeynet.org/node/583
But I must take issue with the way you make a distinction between viewing documents and surfind the internet. A lot of web content, unfortunately, happens to be in PDF format. Why shouldn't your browser support quick-and-easy viewing of PDF files?
To answer your question, why shouldn't your browser support quick and easy viewing of PDF files, I think the answer is that my browser's job is to render HTML downloaded over a given protocol (such as HTTP or HTTPS) and appropriately supported non-plugin extras as best as possible.
For example, I have a virtual world. This virtual world is designed for a niche, lets say vehicle mechanics. You can look at any vehicle and strip it down or away to see each layer like an onion skin in my world. Why should your browser do that instead of giving it over to a plugin by the format company's author?
If your browser does that the people that write the browser have to support it to a certain extent - if they implement the popen() function in the spec, well they're importing the standard into the browser but if popen("/bin/ls") works then so should popen("/bin/ls;cat%20/etc/passwd").
My point is that the people that make browsers make really great browsers, the people that make PDF readers make great PDF readers. To pull the browser guys off to make a PDF reader is the same as pulling a PDF reader guy to make a browser, it's not their core business.
I'd rather trust a company for whom PDF reading is core business (like sumatra) than those that feel PDF reading is only part of their revenue stream (like adobe).
Great job Chrome Devs, you're really setting the browser ahead of the pack.
Why don't we use HTML or something similar for making papers available?
In any case, thanks Google.
I think it will take time or better technology to overcome the bias that we have when we see a good looking pdf document. It says "professional" in a way webpages don't, although I recognize this is completely irrational.
No web technology currently addresses this issue in a satisfying way, not to mention lack of complex math/chemistry/etc formulas. Even the use of specialized symbols on the web is pain.
Having this will make my world just a little bit more convenient!
http://news.ycombinator.com/item?id=1871521
http://news.ycombinator.com/item?id=1440463
PDF's are everywhere, but browser support--especially in Chrome--has been crap.
One of the few reasons I constantly bounce between Safari and Chrome is the ability to render PDF beautifully. I haven't yet seen a better PDF rendering engine than the OS X built-in one.
I guess most likely it's not possible...
This feature has been available in the dev channel of Chrome for ages, and until now it's still unstable. PDF's tend big documents, and it's generally the case that Chrome locks up and ends up crashing when opening a PDF that's more than a few pages. This defeats the purpose in my opinion. The moment I notice I'm loading a PDF in Chrome I go ballistic trying to close the tab to avoid the crash.
I'd rather have developers improving the bookmark manager than trying to make a browser a PDF reader also. And a bad one at it. This makes me want to go back to the Chromium nightly builds. Those where awesome and bullshit free.
Not everyone has a pdf viewer software installed.
Every OS X and most Linux desktop distros are capable of rendering PDF natively. Personally I think OS X default PDF viewer renders much better than Chrome. They should just reuse it.
Similar thing for H.264 playback. AFAIK Chrome use ffmpeg to decode H.264 and WebM content. It's fine if there is no native codec to do that (H.264 on Linux, WebM on all OS). But on Windows 7 and OS X where hardware-accelerated H.264 playback comes by default, they should reuse that.
I have a fear that if they continue to do so (invent their own not-so-good stuff instead of reusing existing and better tech), one day Chrome will become the cross-platform shit that can run on every OS but not good on any one.
Chromium use ffmpeg, Chrome use a proprietary library avcodec-52.dll
To be fair though, maybe I'm not the target market for this feature, but I find it way easier to just download the file and have it open in Preview, than to have to work with Chrome's implementation.
That being said, I don't like Chrome's implementation though. Usually switch to Safari for "PDF mode".
No, not if you opt to have it opened directly in a PDF viewer.
Whether that's any faster than having the browser render it, I don't know. Except for larger files I doubt the difference is significant.
But in almost all cases I prefer to download the PDF and decide what to do with it later.
[1] http://docs.google.com/viewer?url=http://labs.google.com/pap...
It might just be a font thing.
Why didn't the Chrome team incorporate the original Adobe Reader instead of Foxit?