Google Builds a Native PDF Reader Into Chrome 285
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.
PDF plugin, OK. PDF built-in? Not so sure... (Score:1, Interesting)
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.
But when I hear someone teaming up with Adobe and inserting Adobe's PDF reader directly into a browser, I sense that nothing good can come of this. Adobe has exceeded the purpose of PDF by adding scripting language code into it. It was supposed to be a portable document format... says so right in the name. Now it's grown well beyond that and it's not a good thing... it's a horribly exploitable thing and the user has a lot less control and, unfortunately, a lot more trust of PDF than other document formats.
If it was a Google implementation of PDF that removed potentially harmful content? I'd be apt to believe in that, but this is something else and it's guaranteed to be bloated as hell. Has anyone happened to notice how HUGE Adobe Acrobat reader is?
Re:PDF is fat (Score:3, Interesting)
Re:PDF is fat (Score:5, Interesting)
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:Chrome is not an application, it's a widget. (Score:3, Interesting)
Let me known when they figure out how to add a menu bar. Until then, I'll be sticking with Firefox.
LK
This. I moved from Firefox to Chrome for speed and from Chrome to Ephiphany for a menu bar. I've lost a lot of features in the moves but now I have a fast, stable broswer with a menu bar.
Re:Google Policy on Automatic Updates (Score:4, Interesting)
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:Chrome, you're losing me! (Score:3, Interesting)
From http://dotnetperls.com/chrome-memory [dotnetperls.com]:
Their methodology is flawed. The operating system will share identical unmodified memory pages between processes once in memory. So if they simply summed @ the total memory usage for each process, they could be counting the same piece of memory multiple times.
In Firefox, the single-process model makes it easy to measure the memory use of the process, but brings with it all it's flaws, (much easier to take out the whole session with a bad plugin)
Measuring memory usage of a multi-process application requires figuring out many pages are uniquely mapped amongst all processes, then summing that figure
Re:Chrome, you're losing me! (Score:3, Interesting)
First, this isn't Adobe Reader, thank Zod. It's Google's own implementation.
Second, I have (entirely speculative) doubts that the bundling of Flash is happening on its own merits. I suspect a quid pro quo was agreed, whereby Google bundles Flash and offers moral support against Steve Jobs, and in return Adobe extends Flash to support the new WebM video format. This extends its reach to (most) users of IE and Safari, neither of which will be adding native support.
You did not RTFA either (Score:2, Interesting)
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 [chromium.org] which is libpdf [sourceforge.net]
Re:PDF files will render as seamlessly as HTML? (Score:3, Interesting)
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.
Except that in practise they never do because you're mixing fixed size (images, banners, logos etc.) and dynamic size (text mostly) content and making sure that it always reflows well just doesn't happen. Of course you can blame the developers but it's a little like saying no buffer overflow is the language's fault, if all developers were perfect it wouldn't happen. Slashdot is one of extremely few sites that do it and it only works because slashdot is extremely simple, for example I just checked the five biggest online newspapers in Norway, 5/5 use fixed width. Anecdotally I would say that holds true for most complex websites.
Very often if you want it to work *well*, it probably can't be done automatically anyway. For example on these news sites, if you want to make a good mobile site you must make a narrower newspaper with less items side by side. You can somewhat do that with CSS trickery, but it won't look pretty because they mix on using 1/1, 1/2, 1/3 and 1/4th of the width and you would like to use a smaller version of some and to make sure each line fills up and so on. If sites did a few fixed versions and made sure they looked good you'd get 80% of the benefit with 20% of the headache.
Sometimes it just spirals way out of control. For example, i once had to deal with a calendar and users using IEs function to zoom text, it completely broke everything. Try making the days flow right in a dynamic way, but of course seven to a line like you expect and they need to align properly vertically despite numbers having different widths. Oh and it's in a sidebar that's fixed width, recode everything else too. Yeah right, in the end we took a screenshot of each day from 1-31 and made it out of images instead, that way you couldn't zoom it. Problem solved and nobody complained about the way it was solved. Fixed with is KISS, dynamic reflow is very hard and often for very little gain.
Re:Chrome, you're losing me! (Score:4, Interesting)
The built-in PDF feature isn't available on the linux version yet.
Some questions that I had that weren't answered by TFA:
Re:Google Policy on Automatic Updates (Score:3, Interesting)
I agree with GP, in what places on earth, apart from what I assume is a farm in the middle of the desert in Australia, is quotas an issue ? :)
Cuba. My quota used to be 170 Mb/month, and I had one of the highest quotas in the university (I was the sysadmin, and I was authorized to increase my own quota, and ask for permission later, if I needed). In practice, though, I never reached that ammount... 1mbit/sec shared by 10000 users didn't make it easy, but there were professors in the 50-70 Mb/month range that had a hard time by the end of the month.
The very first thing we had to teach users was to disable automatic updates (instead we would download new versions once and publish then internally). We really couldn't afford one program taking all the available bandwith for several hours while everyone's instances were being updated.
Sadly, that situation won't change until the Cuba-Venezuela cable is finished, if it ever is.