191–200 of 200 posts
Earlier quoted context omitted.
I believe the security feature is the ability to disable Javascript code that is included within the pdf file. A pdf reader implemented in Javascript is perfectly capable of doing that.
Not only that, but being able to render via js would (and thus avoid calling out to any plugin code) would be able to take advantage of sandboxing too I imagine.
Dumb question: What's to stop Chrome from eventually adopting PDF.js? 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.
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.
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
Earlier quoted context omitted.
If you're in the US, you may not notice it, but Bing is plain awful for international users. Google has spent a considerable amount of resources improving their engine to serve results based on your location and Google's Search Engine is clearly the best by a long shot. This is also why I'm not using DuckDuckGo.
Agreed. If Bing could match google's accuracy in scholar paper/reference searching I'd not mind to use it.
Earlier quoted context omitted.
Chrome's built-in PDF plugin is actually from a Chinese company called Foxit. http://googlesystem.blogspot.com/2010/08/google-chromes-pdf-... Now start China bitching.
I've been using Foxit reader for years without knowing that it was Chinese. Its a great product - fast as hell - beats the pants off Adobe.
Earlier quoted context omitted.
Your last statement is way overstating the original remark about NaCL. Google has definitely been pushing PNaCL as the solution for running large, complex apps that are usually native (like 3d games, and things that require lots of computation) on the web. And there's no way PNaCL is going to be viable in the next decade, it takes way too long for everyone to agree & implement. Gmail, docs, etc are complex, but don't…
One of the major reasons PNaCL is "non-viable" are the comments like this one, calling it non-viable, and insisting on a JS-everywhere future. 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.
Earlier quoted context omitted.
One of the major reasons PNaCL is "non-viable" are the comments like this one, calling it non-viable, and insisting on a JS-everywhere future. 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.
http://news.ycombinator.com/item?id=4632410
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
Fine -- if using javascript to encode a bytecode is what it takes for Mozilla to actually take the need for a common bytecode seriously (and admit that DOM/JS/HTML/CSS is perhaps not adequate), then I won't look a gift horse in the mouth. I just wish they'd figured out the need for post-JS webapps a little sooner.
Earlier quoted context omitted.
Chrome's built-in PDF plugin is actually from a Chinese company called Foxit. http://googlesystem.blogspot.com/2010/08/google-chromes-pdf-... Now start China bitching.
I've been using Foxit reader for years without knowing that it was Chinese. Its a great product - fast as hell - beats the pants off Adobe.
If you want to try PDF.js from your current browser, here's a demo: http://mozilla.github.com/pdf.js/web/viewer.html 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.
Looks much better than I imagined. Also painfully slow.
I think i will have stick to adobe reader for now
Earlier quoted context omitted.
The PDF viewer in Chrome is available to Chromium users (just copying the libpdf.so or libpdf.DLL file into the appropriate directory works); it's just not open source.
I think for most people, when they say "available," they mean "without copyright infringement."