Google Builds a Native PDF Reader Into Chrome

An anonymous reader writes "Google's latest Chrome 6 Developer Update comes with a few subtle GUI changes, but there is also a major update under the hood. As its ties with Adobe quite apparently grow stronger, there is not just an integrated Flash player, but also a native PDF reader in the latest version of Chrome 6. Google says the native reader will allow users to interact with PDF files just like they do with regular HTML pages. The reader is included in Chrome versions (Chromium) 6.0.437.1 and higher, and you can use the feature after you have enabled it manually in the plug-ins menu. That is, of course, if you can keep Chrome 6 alive — Windows users have reported frequent crashes, and Google has temporarily suspended the update progress to find out what is going on." The Register has some more details on the PDF plugin and a link to Google's blog post about it.

Comments

PDF files will render as seamlessly as HTML?

[Meshach]

The article contains this statement:

PDF files will render as seamlessly as HTML

Does this mean that the PDF pages are translated into HTML pages then displayed? I always thought that one of the main strengths of PDF was that the author has 100% control over how it is presented. Or am I misunderstanding that feature?

Re:PDF files will render as seamlessly as HTML?

[Saeed al-Sahaf]

Or am I misunderstanding that feature?

Saying "PDF files will render as seamlessly as HTML" is not the same as "PDF files will render as HTML".

So, yes, I think you misunderstand.

Re:PDF files will render as seamlessly as HTML?

[iammani]

Actually google already has an excellent online PDF viewer, it seems to display PDFs as an image, but still manages selection of words, searching and copying. Here is a sample IRS PDF I wouldnt be surprised, if the same code was converted into a chrome plugin.

Re:PDF files will render as seamlessly as HTML?

[ScrewMaster]

Yeah, because a web page should look exactly the same on my smartphone as it does on my 1080p display....

I don't think the OP understands the purpose of a markup language, a browser, or the idea the pages should render gracefully on different devices. And that's okay so long as he's not a Web developer.

Re:PDF files will render as seamlessly as HTML?

[AK Marc]

I always thought that one of the main strengths of PDF was that the author has 100% control over how it is presented. Or am I misunderstanding that feature?

I think you are. PDFs aren't read-only. PDFs aren't secure (well, unless you have some DRM package installed, and even then it's debatable). PDFs will, in the absence of anything else, present like the author wanted. But they are easily edited, modified, redacted, and such. I know people that think "If I send it as a PDF, they won't be able to just copy the text off it, and they can't just change a couple things in it and send it on to someone else like it was mine." Both are incorrect. So yes, you are misunderstanding that feature. It is so that you know they can open it, not that you know they can't modify it. Those are unrelated issues, and it just happens that most people don't bother to get programs that let them modify PDFs and they aren't necessarily easily modified, so they aren't modified regularly in practice.

Re:PDF files will render as seamlessly as HTML?

[John Hasler]

> Then there is fonts. Heck there are web browsers that run on text terminals.
> Fonts are likely to be substituted depening on the platform and the
> particular install which will also affect the sizing of stuff.

Font sizes are also sometimes much larger than the 2pt that Web designers adore because some of us have less than perfect eyesight.

Re:PDF files will render as seamlessly as HTML?

[grumbel]

Actually the separation of presentation and content is pretty good on most of the bigger sites, i.e. you can switch to "View/Page Style/Basic Page Style" in Firefox and things will look just "fine", they have all their <ul>'s and <h2>'s marked up properly.

The much bigger problem is that the presentation information itself isn't very flexible, instead it consists of ugly hacks and expectation of pixel-perfect exact rendering on every browser. If you change little details like the font-size almost all webpages will completly fail. Some will fail mildly (on Slashdot the Reply button will fall apart) while others will fail catastrophically (overlapping and thus unreadable text). CSS is simply extremely crappy when it comes to creating robust layout, as soon as some small parameter changes, it might result in an unusable webpage, which is why the user is left with the choice between no style at all and pixel perfect rendering as intended by the author, while most of the time you really would want something in between.

Re:PDF files will render as seamlessly as HTML?

[BatsShadow]

You're misunderstanding his post. His point is that the document as the author created it should look the same to all viewers no matter what their device. The author has full, very specific, control over what the document looks like to the user. Compare this to the web where pages render differently on every device. He's not talking about security or whether or not users can edit the document.

Chrome, you're losing me!

[Anonymous Coward]

I started using Chrome because it was an improvement over the other browsers. It was faster, it used less memory, and it was more crash-resistant. But I have not been impressed with the latest versions.

Everyone knows about them removing http:// from the URL bar already. Their reasoning was, to put it politely, complete horseshit. That was a change they never should have made.

Embedding Flash natively is good for YouTube, no doubt, but bad for everyone who doesn't want to support or use something that is so shitty and proprietary.

One of the last things I ever wanted was native PDF support in my browser. Just like with Flash, I go out of my way to avoid PDFs.

As much as I dislike proprietary software, these recent Chrome developments are driving me to Opera. Opera is faster than Chrome, manages memory better, and never crashes. While their code isn't open source, at least they embrace open and truly free standards. Until the Chrome developers get their acts together, I'm done with it.

Re:Chrome, you're losing me!

[asvravi]

Whether you like it or not, use it or not, have a choice or not, the fact is both Flash and Adobe Reader will be there anyway on 99% of the PCs. Google is to be appreciated for taking them under its fold so to speak - instead of leaving them as separate addons that never get into the final browser build testing and regression testing. Integrating these and testing and deploying it as a whole package is certainly better for stability as well as security.

Re:Chrome, you're losing me!

[an unsound mind]

There's more than one person amongst the geek community. People can have differing opinions even when identifying under a common label. Shocking, I know.

Re:Chrome, you're losing me!

[Zarel]

From a security point of view, I'd feel better if Google wrote their own PDF implementation. Far be it for me to read TFA, but I get the impression that this code comes from Adobe, whose software generally makes me nervous.

I've read it for you. The code doesn't come from Adobe, Google wrote it themselves. It also uses Google's new sandboxed plugin API, so it would be less of a security concern even if it did.

(I'm surprised you got two replies who also didn't RTFA.)

Re:Chrome, you're losing me!

[bcrowell]

The built-in PDF feature isn't available on the linux version yet.

Some questions that I had that weren't answered by TFA:

1. Is the PDF renderer fully open source and available under the same license as everything else, so that it can be included in nonproprietary builds of Chromium?
2. TFA says: "The plug-in doesn't do everything that the Adobe Reader does. It can't handle, for instance, certain embedded media[...]" This is probably a good thing, IMO. The $40,000 question is whether it supports javascript embedded in PDFs, which is the huge security nightmare in Adobe Reader. If it does support it, I hope it's turned off by default. Since I run linux, I can't test this. Can any slashdotters try it and find out?
3. Same question as #2 for embedded flash. I assume they haven't implemented it, hope they never do.
4. What is the patent situation with the implemented and nonimplemented "embedded media," and how does this affect fully nonproprietary builds of Chromium?

Yay?

[Anonymous Coward]

PDF is actually a useful standard when it comes to reproducing printed or printable documents. The worst thing about PDF is Adobe's Reader implementation. Hopefully, this is a clean implementation, not based on Adobe's lousy, slow, insecure Reader code. I know they say its sandboxed, but still.

Anyone using Safari or Firefox (extension here) on the Mac has been able to do this for some time; PDFs are a lot better without the Adobe plugin.

Re:PDF plugin, OK. PDF built-in? Not so sure...

[Anonymous Coward]

I'm not fully qualified to comment on this since I will never be a Chrome user until someone forks off a "stainless steel" release where a group of people have poured over the source code to ensure there is no Google data collecting going on and then compiles it themselves for distribution.

No, I think what you want is the "tinfoil hat" release.

But seriously, it's called Chromium. It's the fully open source project that feeds into Chrome, and it's free of all Google branding and such. For what it's worth though, there's nothing in Chrome that does anything remotely close to what you're afraid of. Feel free to run it for a couple of weeks through a debugging proxy to watch what it does (I have).

Re:Old technology

[iPhr0stByt3]

But Chrome is not converting anything. It's more like a plug-in that's native. This is the same way Chrome reads HTML5 natively... it doesn't first convert it to HTML4. It won't look any different than the Adobe's plug-in or FoxIt's plug-in, but you don't have to install it separately. And most awesomely, you won't have to update it separately. Of course this makes Chrome natively a little more vulnerable too... but oodles more secure than Adobe's plug-in.

Re:PDF is fat

[abulafia]

PDFs tend to bloat for at least two reasons - one is the inclusion of tons of rasters and other embedded objects, and that's a problem between chair and keyboard - the resultant documents are just was was asked for. The other is that PDF is (a superset of) a subset of Postscript. Some combinations of software and the drivers that generate PDFs, can do insanely redundant things that cause massive documents. One neat workflow I saw several years ago was placing raster images into Illustrator objects, then through a DTP program to be rendered to PDF. That particular software stack/combination of transformations managed add something like 400x bloat compared to the same document produced in a different way.

Generating non-insane Postscript used to be a solved problem, but it appears to come back every so often.

Also, changes in the PDF happened some time back that had big size advantages. Documents generated by old PDF renderers are going to tend to be larger than those generated by newer ones. (I don't really recall the details, but some of it was how embedded objects are stored.)

Re:Why?

[rudy_wayne]

Adobe either doesn't hire qualified programmers or somehow manages to thwart any from getting work done properly. I'm not sure what exactly the problem is, whether there's too much interference from people without foundation or perhaps they just don't provide the resources to do it correctly in the first place.

Adobe's big applications (Photoshop, Premier, etc) are quite good. The problem with Adobe PDF is not a lack of resources, skill or competence on the part of Adobe programmers. The problem is that a PDF reader/creator should be a small simple program, but some pointy haired boss somewhere constantly demands the addition of more and more "features" that are inappropriate, make the program ridiculously bloated and frequently lead to numerous sercurity flaws.

Google Policy on Automatic Updates

[CuteSteveJobs]

> if you can keep Chrome 6 alive — Windows users have reported frequent crashes, and Google has temporarily suspended the update progress to find out what is going on.

I've experienced Chrome crashes too - more frequently than IE or Firefox. And that's a big problem with Chrome: You can't turn off Automatic updates(*). You will find several hundred meg vanishing from your download quota. I guess the Google developers with their top-of-the-line hardware forget that us regular folks care about things like bandwidth, disk space (it leaves the downloaded files sitting on your hard drive - multiple versions) and quotas (because I don't want to go over my peak quota because some punk program won't take directions). It also jumps up and starts downloading and installing even if you're in the middle of something.

I'd rather schedule my own updates to fit my own schedule - I don't want some program stuffing up when I'm in the middle of something. Chrome has some nice features - it's fast and it doesn't waste the screen space or have the memory bloat that Firefox or IE do, but Chrome crashes a lot and in the end I figured Firefox was best because it at least gives you some control over your PC. Chrome doesn't.

* = Google do provide a way for Enterprise users to modify the groups policy because (as described in their faq) 'enterprises should be able to schedule their own updates'. But Joe Public doesn't get that luxury, and there's no checkbox to turn it up like every other software is decent enough to provide. BTW don't try the REGEDITS; they don't work. Google know about all this because there are many posts complaining about it (search for 'disable chrome automatic updates'), but in the usual corporate arrogance won't even acknowledge the problem: pesky customers! Google think they know what's best.

http://www.google.com/search?q=disable+chrome+automatic+updates

Re:Google Policy on Automatic Updates

[bertok]

Where are you that you need to keep an eye on your bandwidth?

Where the hell are you that you can't even imaging having to worry about bandwith? Can I move there?

Over here in Australia, internet connections with 1GB quotas per month are not unusual, and most mobile 3G accounts are even more restricted.

Re:PDF is fat

[bonch]

PDF viewing is very fast on OS X, and Safari has natively displayed PDFs for a long time. I blame Adobe's reader.

6 already?

[Junior J. Junior III]

Geez, it seems like I was just upgraded to 5 last week.

Re:You did not RTFA either

[Zarel]

because TFA doesn't explain that google wrote it themselves. Heck, even the google blog announcement doesn't explain that google wrote it themselves. Guess what, it turns out google did not write it themselves, they're using libpdf.so which is libpdf

I was referring to the Google blog post, which is linked from the Slashdot summary and thus counts as "TFA".

It says "Currently, we do not support 100% of the advanced PDF features found in Adobe Reader, such as certain types of embedded media" and "We would also like to work with the Adobe Reader team to bring the full PDF feature set to Chrome using the same next generation browser plug-in API", which I took to mean that:

1. it clearly isn't being written by Adobe, and
2. even if Google didn't write it, they are maintaining and improving it, so they "wrote it" in the same sense that Apple "wrote" WebKit.

As for the "libpdf.so", part, I assume you're looking at the part of the code that says

#if defined(OS_WIN)
            cur = cur.Append(FILE_PATH_LITERAL("pdf.dll"));
#elif defined(OS_MACOSX)
            cur = cur.Append(FILE_PATH_LITERAL("PDF.plugin"));
#else // Linux and Chrome OS
            cur = cur.Append(FILE_PATH_LITERAL("libpdf.so"));
#endif

Which means that they're using a file called libpdf.so on Linux. As another one of your replies points out, this is doubtful to be the 9-year-old unmaintained incomplete C library you link to, and judging from the Windows and Mac filenames, this is nearly definitely a library written (or at least maintained) by Google.

using a browser to display documents?

[Punto]

using a browser to display documents with complex layouts, fonts, images, etc? What a novel idea, I don't know how nobody thought of this sooner. Seriously, the main reason why I hate PDF is that I need a separate program to open them, when they're just a glorified webpage.

I wonder why they don't just build this as a native client plugin, and use it on-demand when a pdf shows up, instead of making a big deal about how it's "built in".

Re:Chrome is not an application, it's a widget.

[drinkypoo]

Why use a confusing picture (Wrench and Piece of paper?) when perfectly clear text can be used.

The wrench has been a universal configuration icon as long as we've had icons. In fact, using a wrench to denote the storage of tools predates computers considerably. The truly crafty would drill holes in a crappy wrench, add standoffs, and use it as the handle for a tool drawer. Windows 7 includes a wrench icon for configuration on most notifications. Similarly, a picture of a document has been the symbol for document manipulation as long as we've had icons as well; and further, it has long been present on toolbars.

Or, short form, if you are confused by a wrench and a piece of paper, you are a pathetic tool user. Get off my lawn, if you can manage to walk in a straight line.

Similarly, should I have all my mp3's in one folder, or should I have subfolders by artists and albums, or some other criterion for example?

It's not similar. And BTW, if your filesystem doesn't suck, and your player has decent metadata support, it doesn't matter how you store your mp3s as long as you use a naming convention that supports them all being in the same place.

Anyways, that's why I like the traditional "file edit view history bookmarks tools help" interface. Faster and more organized IMHO

But you're wrong. It's slower and less organized. Menus are piles of functions loosely grouped. Chrome's interface is designed to show you the controls you commonly need. Do you really need to go to the edit menu for copy/cut/paste? Everyone I know knows the keyboard shortcuts, even my artist/chef lady love has managed to get those down, and when she forgets them, she uses the context menu, which is the second place you should go. The menu is a distant third (largely because it is distant) and you don't need to go there except to change encoding or report a bug, two things done very infrequently. I use the wrench menu slightly more often because I like to mess with extensions, but everything commonly used in there has a keyboard shortcut or an interface button... except the bookmarks button, for which you need an extension.