PDF goodness in Chrome
chrome.blogspot.com
chrome.blogspot.com
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.
Preferences -> Under the Hood -> Content Settings... -> Plug-ins -> Disable individual plug-ins...
you can turn it off and have PDFs revert to downloading for viewing in Preview.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.
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!
Why didn't the Chrome team incorporate the original Adobe Reader instead of Foxit?
[1] http://docs.google.com/viewer?url=http://labs.google.com/pap...
Don'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
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).
It might just be a font thing.
PDF's are everywhere, but browser support--especially in Chrome--has been crap.