×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Pdf.js Reaches First Milestone

timothy posted more than 2 years ago | from the daddy-what-were-operating-systems? dept.

Firefox 164

theweatherelectric writes "The pdf.js project aims to implement a PDF viewer using standards-compliant Web technologies. The project has reached its first milestone: it renders the sample PDF (a paper on Mozilla's Tracemonkey JavaScript engine) perfectly. However, that perfection currently comes with some caveats: 'pdf.js produces different results on pretty much every element in the browser×OS matrix. We said above that pdf.js renders the Tracemonkey paper "perfectly" if you're running a Firefox nightly. On a Windows 7 machine where Firefox can use Direct2D and DirectWrite. If you ignore what appears to be a bug in DirectWrite's font hinting. The paper is rendered less well on other platforms and in older Firefoxen, and even worse in other browsers. But such is life on the bleeding edge of the web platform.'"

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

164 comments

Wow (-1, Troll)

Anonymous Coward | more than 2 years ago | (#36651958)

Browser-specific and it doesn't even work properly on machines running the target browser if it's the wrong version or the wrong OS.

You've really grasped the point of web standards and JavaScript, guys.

Re:Wow (3, Interesting)

Spad (470073) | more than 2 years ago | (#36652048)

If you read the article (I know, I know)...

pdf.js has now reached the point where a significant portion of its issues are actually browser-rendering-engine bugs, or missing features. Finding these gaps and filling some of them has been one of the biggest returns on our investment in pdf.js so far.

The problem isn't what they've written so much as the browsers not being able to support the latest and greatest HTML5/JS functionality.

Re:Wow (1)

Osgeld (1900440) | more than 2 years ago | (#36654108)

ha thats a ghost argument

"see my infinity energy machine works perfectly fine, its just the laws of physics have not caught up yet"

does not sound like any less bullshit

Re:Wow (4, Insightful)

Lunix Nutcase (1092239) | more than 2 years ago | (#36652136)

They've actually failed to grasp the point of PDF. You might as well go back to HTML if your PDF reader can't render the same everywhere considering that was the whole point of PDF to begin with.

Re:Wow (2)

QuasiSteve (2042606) | more than 2 years ago | (#36652382)

I'm guessing you're modded Funny because - sadly - this hasn't been true of PDF in a long time now.

Even between desktop PDF readers there's now too much of a difference to even remotely be able to 'rely' on it. Even bitmaps are getting less and less reliable with applications choosing to either respect or ignore gamma tags, let alone color profile information.

As it is, I used to use FoxIt, but that started to get bloaty and including oddball toolbars. So I switched to PDF-Xchange. I'm about to switch again (Sumatra, maybe?) because PDF-Xchange takes far too long to render pages with lots of graphics. And neither FoxIt nor PDF-Xchange render vector content with anti-aliasing correctly.
http://i.imgur.com/f8udg.png [imgur.com]
( original image source: sinfest.net . Note that left image was at 172% zoom, right image was at 150% zoom, to get the same on-screen size. wtf? )

I'm going to guess that Sumatra really won't be any much better and maybe I'll have to go back to FoxIt.
Either way, it looks like Adobe Reader will have to remain installed for when these alternatives don't quite get things right.

VM / Sandbox (1)

Mathinker (909784) | more than 2 years ago | (#36653442)

> Either way, it looks like Adobe Reader will have to remain installed for when these alternatives don't quite get things right.

You might consider installing a VM like VirtualBox or some kind of sandboxing solution so that you can convert / print / export and subsequently erase any "side effects".

Memory and surplus CPU power is getting cheaper and cheaper, I don't understand why more people don't talk about going this route.

Re:Wow (0)

Anonymous Coward | more than 2 years ago | (#36653930)

Either way, it looks like Adobe Reader will have to remain installed for when these alternatives don't quite get things right.

Then why not just use Adobe Reader if you are going to have it installed?

Re:Wow (1)

moonbender (547943) | more than 2 years ago | (#36654082)

Back when I still used Windows, Acrobat Reader was an absurdly large app and by far the slowest PDF reader I knew over all platforms. It always struck me as absurd that Apple and Linux users had built-in, capable, lightweight PDF viewers while most Windows users used that bloated POS. Maybe acroread is better these days, but I kind of doubt it.

Re:Wow (0)

Anonymous Coward | more than 2 years ago | (#36652896)

That's how it is in theory; in practice it's used as a media-capable .doc format. 99% of the time you don't care about presentation.

Re:Wow (4, Informative)

PybusJ (30549) | more than 2 years ago | (#36653520)

Or perhaps you've failed to grasp the point of a v0.2 pre-release on github? In fact TFA specifically states that pixel perfect rendering _is_ their goal.

The blog post describes the current progress; it now has good rendering on one platform, progress from last week.

Not impressive... (-1, Troll)

foxenfan (2339266) | more than 2 years ago | (#36651980)

But a javascript VM [aeonity.com] that can run Linux in your browser sure is.
But author is an asshole for not releasing the source (the .js file is compressed, and under non-free Licence).

Re:Not impressive... (1, Informative)

Anonymous Coward | more than 2 years ago | (#36651996)

Goatse

Re:Not impressive... (0)

rbrausse (1319883) | more than 2 years ago | (#36652004)

under non-free Licence

looks very open to me... (congrats, 'twas a while ago I was goatsed the last time)

It's all images (0)

Anonymous Coward | more than 2 years ago | (#36651994)

The big downside is that it's all images and you can't do all those fancy things you can do with text. Like select, copy & search.

Re:It's all images (1)

Yvan256 (722131) | more than 2 years ago | (#36652144)

If it renders it all as images, then why go to the trouble of making this client-side?

Render as images on the server once and your problems are over for all platforms and browsers. Unless, of course, you do something stupid like using the BMP image format instead of PNG.

Re:It's all images (1)

Anonymous Coward | more than 2 years ago | (#36652262)

Why not use a vector format which can properly scale the text and even include the text in a format readable to search engines?

Like, for example, PDF?

Re:It's all images (1)

tepples (727027) | more than 2 years ago | (#36652326)

Render as images on the server once

"The document could not be displayed because you are not connected to the Internet."

incomplete sentence?! (0)

Anonymous Coward | more than 2 years ago | (#36652020)

On a Windows 7 machine where Firefox can use Direct2D and DirectWrite.

Editors! WTF?

Re:incomplete sentence?! (1)

Spad (470073) | more than 2 years ago | (#36652058)

I *think* it's supposed to be:

We said above that pdf.js renders the Tracemonkey paper "perfectly" if you're running a Firefox nightly on a Windows 7 machine where Firefox can use Direct2D and DirectWrite, if you ignore what appears to be a bug in DirectWrite's font hinting.

Re:incomplete sentence?! (1)

Anonymous Coward | more than 2 years ago | (#36652276)

They cut the sentences into separate clauses to emphasise each of them ...

Why all the complaining? (1)

Bradmont (513167) | more than 2 years ago | (#36652038)

Even reading the summary it is clear that this is a very, very early development work. This is their *first* milestone, of course it's going to be severely lacking in almost every way. Of course it's not cross-browser and doesn't allow selectable text... but eventually it will be. I, for one, think this is a great idea, and can't wait to see it done!

Not impressive... (-1, Troll)

foxenfan1 (2339304) | more than 2 years ago | (#36652044)

But a javascript VM [thoughts.com] that can run Linux in your browser sure is. But author is an asshole for not releasing the source (the .js file is compressed, and under non-free Licence).

Not impressive... (-1, Troll)

foxenfan2 (2339318) | more than 2 years ago | (#36652074)

But a javascript VM [aeonity.com] that can run Linux in your browser sure is.
But author is an asshole for not releasing the source (the .js file is compressed, and under non-free Licence).

Re:Not impressive... (1)

deniable (76198) | more than 2 years ago | (#36652134)

Oh wow, retro-trolling. Soon we'll be back to page-widening, Steven King is dead and bell bottoms.

Not impressive (-1, Troll)

foxenfan3 (2339332) | more than 2 years ago | (#36652082)

But a javascript VM [thoughts.com] that can run Linux in your browser sure is.
But author is an asshole for not releasing the source (the .js file is compressed, and under non-free Licence).

Re:Not impressive (0)

Anonymous Coward | more than 2 years ago | (#36652164)

Goatsex

goal to make things suck? (3, Insightful)

Anonymous Coward | more than 2 years ago | (#36652094)

I can understand the use of this to find and fix browser bugs.

But it seems amazingly inferior to a platform native PDF reader, on any platform imaginable. It will be slower the native x86/ARM code by far, and won't integrate well with the desktop environment.

What's with this trend recently to build everything on fundamentally sucky technologies?

Re:goal to make things suck? (0)

Anonymous Coward | more than 2 years ago | (#36652146)

Because it's "standards compliant."

And because Javascript is the new cool kid on the block.

Yeah, I don't get it either.

Re:goal to make things suck? (0)

Anonymous Coward | more than 2 years ago | (#36653694)

Some would say that they are using javascript because it is inherently cross-platform by design, but I would respond by pointing out that the variety of different methods used to render objects in a browser window tend to make it difficult, requiring mixins and various hacks in order to force everything to a perfect interface. In all honesty, testing for render bugs in a browser seems a much more appropriate use of a developer's time, as opposed to reinventing the wheel (as somebody else pointed out, a native browser plugin is much faster and always will be).

Re:goal to make things suck? (2)

DrXym (126579) | more than 2 years ago | (#36652552)

What's with this trend recently to build everything on fundamentally sucky technologies?

I think it's becoming increasingly obvious that browsers need something that allows native client functionality without the burden of shoe horning everything through Javascript's loosely typed, garbage collectioned, non addressable world. LLVM is gaining a lot of steam so perhaps it should be that with each app seeing a limited API that maps out onto the DOM. Perhaps that can even be created from JS, e.g. an vmEval(url, canvas) function that loads bitcode from some url, turns it into an invokable object which is associated with a drawing region.

Re:goal to make things suck? (1)

heathen_01 (1191043) | more than 2 years ago | (#36653586)

Great idea, the bit code could even execute inside a vm for cross platform compatibility and also be constrained by a sandbox.

Re:goal to make things suck? (0)

Anonymous Coward | more than 2 years ago | (#36653082)

For Linux and OSX I would say you are probably right.
For Windows however, where the available "platform native PDF reader" choices seem to be attempting to compete with each other in terms of how shit they are, it could be a welcome option.

Re:goal to make things suck? (2)

jlebar (1904578) | more than 2 years ago | (#36653424)

It will be slower the native x86/ARM code by far, and won't integrate well with the desktop environment.

Does your PDF reader integrate well with the browser environment?

One of the major benefits of rendering PDFs in the browser, aside from the fact that users don't have to download, trust, and run a separate PDF viewer, is that you reduce the security vulnerability surface area. PDFs (well, Adobe Reader) is a major vector for attacks, but that goes away when you sandbox it in the browser.

I think you might also be surprised how fast one can make something like this in JS. Most of the expensive paths, like drawing to the screen, are exported to C++ code.

Re:goal to make things suck? (2)

hedwards (940851) | more than 2 years ago | (#36653906)

If it's a vulnerability thing, then what you really need to do is go over to Adobe and bitch smack the moron there that decided that it was a good idea to include scripting and linking abilities into a document format. And if you choose the Seattle branch you're just a short ways from MS so you can bitch slap the hell out of them for doing the same sort of bullshit with .DOC.

Documents are for reading, if you want people to be able to fill in a form, then they should have to use a separate program. It's just way too easy to exploit that "feature" when very few people actually want to edit their PDFs anyways. I can't personally recall the last time that I needed that functionality.

Re:goal to make things suck? (1)

richtaur (1234738) | more than 2 years ago | (#36654182)

What's with this trend recently to build everything on fundamentally sucky technologies?

In order to evolve, platforms need their boundaries pushed. I'm sure this project is partially intended to reveal to browser makers (including Mozilla themselves) exactly where and how their platform could improve.

Re:goal to make things suck? (3, Interesting)

Vellmont (569020) | more than 2 years ago | (#36654442)


But it seems amazingly inferior to a platform native PDF reader, on any platform imaginable. It will be slower the native x86/ARM code by far, and won't integrate well with the desktop environment.

What's with this trend recently to build everything on fundamentally sucky technologies?

You're absolutely right. A platform native PDF reader is technically superior. But opening up a new window for each PDF you display really sucks as a user experience. To eliminate this sucky UI experience, browsers support PDF natively (I'm not sure why this hasn't happened), and not rely on Adobe reader, or some other helper application. Even if all the major browsers supported that TODAY, it would be literally years before a broad enough spectrum of people upgraded to use inline PDFs in a design.

What implementing a PDF reader in javascript accomplishes is across the board inline PDFs today. No upgrades required. I think that's worth some sucky technology and inefficient code.

Re:goal to make things suck? (1)

kripkenstein (913150) | more than 2 years ago | (#36654560)

But it seems amazingly inferior to a platform native PDF reader, on any platform imaginable. It will be slower the native x86/ARM code by far, and won't integrate well with the desktop environment.

Regarding speed, two things: First, this will spend most of its time in calls to the browser's Canvas API, which all browsers implement in C++. So it isn't clear that it should be significantly slower than a native implementation. Second, even if this were in 100% JavaScript, that is just around 5X slower than C++ these days. Rendering PDFs might be plenty fast enough at that speed, since you typically render once then show it for a long time. In other words, this isn't something like a game engine that needs to push 60fps.

What's with this trend recently to build everything on fundamentally sucky technologies?

There are several advantages to implementing this using Web technologies. The first is, as you mentioned, it's a good way to find browser bugs, and it also helps find areas to improve the Canvas API. Another important reason is that this implementation will be much more secure than any other existing PDF implementation, because so much work has gone into proper sandboxing of JavaScript. And we know how many vulnerabilities keep popping up in existing PDF readers like Adobe's. It will be much more secure to use this new PDF implementation than the existing ones.

Can it be closed? (2)

hackertourist (2202674) | more than 2 years ago | (#36652104)

I currently have PDFs set to be downloaded and opened in an external application, because PDF rendering in a browser tab (using Adobe's PDF plugin) fucks up important shortcuts: Cmd-W no longer closes the tab but throws up an annoying dialog. That alone would be reason enough to switch.

Re:Can it be closed? (1)

Yvan256 (722131) | more than 2 years ago | (#36652168)

Small note to webmasters everywhere (if you think about what the parent said): what I hate is websites that force PDF files to be downloads instead of letting my browser handle them. On Mac OS X, viewing a PDF is basically the same as viewing a JPEG. No Adobe reader required, it just works.

Re:Can it be closed? (1)

EndoplasmicRidiculus (1181061) | more than 2 years ago | (#36652204)

That capability is Safari's, nothing to do with OS X. Google Chrome can also display PDF's inline.

Re:Can it be closed? (0)

Anonymous Coward | more than 2 years ago | (#36652328)

He's obviously talking about Preview which has nothing to do with Safari.

Re:Can it be closed? (1)

Yvan256 (722131) | more than 2 years ago | (#36652398)

OS X itself handles PDF just fine (Quick Look, Preview, Safari, print directly to PDF from any application that can print, etc).

Re:Can it be closed? (1)

tlhIngan (30335) | more than 2 years ago | (#36653630)

OS X itself handles PDF just fine (Quick Look, Preview, Safari, print directly to PDF from any application that can print, etc).

That's because OS X's underlying display API is... display PDF! Similar to ye olde Solaris Display PostScript. As a side effect, display and generation of PDFs is trivial - you're outputting to a file rather than to the rasterizer.

It's also the reason why PDFs are trivially displayed in iOS as well - again, being based on OS X means it also inherits display PDF.

Re:Can it be closed? (0)

Anonymous Coward | more than 2 years ago | (#36653832)

PDF is part of the OS X glaphics platform, AFAIK every "document" in OS X is bacically a PDF

Re:Can it be closed? (1)

ortholattice (175065) | more than 2 years ago | (#36652374)

what I hate is websites that force PDF files to be downloads instead of letting my browser handle them.

The problem is that the web site incorrectly specifies the file mime type as e.g. "Content-Type=text/html" instead of "Content-Type=application/pdf". While in theory the ".pdf" extension or content inspection could be used to guess it, Firefox (for example) does not use mime type guessing since it is a security issue: What should Firefox do with this file? [mozillazine.org] .

Re:Can it be closed? (1)

MurukeshM (1901690) | more than 2 years ago | (#36652330)

Adobe's PDF sucks. I use either:
a) Google Quick View (my favourite),
b) Chrome's built-in PDF viewer (which is fast, and doesn't crash often, and doesn't hang everything while the PDF is being downloaded.), or
c) Foxit's plugin (very rarely),
depending on the browser and OS being used. But I tried it out, and though the rendering was horrible (Chromium daily on Natty), it didn't seem to hang or ask anything on being closed. The slide-out sidebar was neat, but the open file button didn't do anything.

Re:Can it be closed? (0)

Anonymous Coward | more than 2 years ago | (#36654488)

Check out Foxit.

"older Firefoxen"?? (1)

Anonymous Coward | more than 2 years ago | (#36652108)

So, "Firefoxen" is now the plural of Firefox?

Re:"older Firefoxen"?? (1)

Anonymous Coward | more than 2 years ago | (#36652582)

Emacs --> emacsen; ergo, firefox --> firefoxen. Now, let's go back to comparing Officen and OSen.

Re:"older Firefoxen"?? (3, Insightful)

Maclir (33773) | more than 2 years ago | (#36653314)

No. The plural of "fox" is "foxes".

If someone can't use the English language correctly, how seriously do you expect me to take anything they write?

Re:"older Firefoxen"?? (0)

Anonymous Coward | more than 2 years ago | (#36653794)

That was exactly my point, I thought "OSen" made it clear enough.

Re:"older Firefoxen"?? (0)

Anonymous Coward | more than 2 years ago | (#36653912)

[item]en has been around for quite a while [catb.org] , and has gained a certain amount of penetration [urbandictionary.com] . Just because you haven't heard of a term doesn't mean it's use (or inclusion in the English language) is incorrect.

Re:"older Firefoxen"?? (2, Insightful)

Anonymous Coward | more than 2 years ago | (#36653928)

Despite your relatively low uid, you must be new to hacker slang.

from the Jargon File [catb.org] :

On a similarly Anglo-Saxon note, almost anything ending in ‘x’ may form plurals in ‘-xen’ (see VAXen and boxen in the main text). Even words ending in phonetic /k/ alone are sometimes treated this way; e.g., ‘soxen’ for a bunch of socks. Other funny plurals are the Hebrew-style ‘frobbotzim’ for the plural of ‘frobbozz’ (see frobnitz) and ‘Unices’ and ‘Twenices’ (rather than ‘Unixes’ and ‘Twenexes’; see Unix, TWENEX in main text). But note that ‘Twenexen’ was never used, and ‘Unixen’ was seldom sighted in the wild until the year 2000, thirty years after it might logically have come into use; it has been suggested that this is because ‘-ix’ and ‘-ex’ are Latin singular endings that attract a Latinate plural.

Now get off my lawn.

Re:"older Firefoxen"?? (0)

Anonymous Coward | more than 2 years ago | (#36654562)

Because knowledge of a language is not related to other types of knowledge. Correcting them is fine, but disregarding their opinion entirely just because of a few grammar mistakes is snobbish.

Re:"older Firefoxen"?? (1)

hedwards (940851) | more than 2 years ago | (#36653944)

Actually proper English dictates that with Emacs and Firefox you'd need a partitive, making it versions of Emacs or versions of Firefox.

Re:"older Firefoxen"?? (1)

ProzacPatient (915544) | more than 2 years ago | (#36654648)

Being a grammar nazi just tell yourself it's the German translation of "Firefoxes." I'm sure that will make you feel better.

Not impressive (-1, Troll)

foxenfan4 (2339346) | more than 2 years ago | (#36652128)

But a javascript VM [aeonity.com] that can run Linux in your browser sure is.
But author is an asshole for not releasing the source (the .js file is compressed, and under non-free Licence).

Re:Not impressive (0)

Anonymous Coward | more than 2 years ago | (#36652154)

I just love bloating up my javascript libraries with tl;dr licenses.

"Firefoxen" (0)

Anonymous Coward | more than 2 years ago | (#36652132)

Really now?

Not impressive (-1, Troll)

foxenfan5 (2339364) | more than 2 years ago | (#36652152)

But a javascript VM [tinyurl.com] that can run Linux in your browser sure is. But author is an asshole for not releasing the source (the .js file is compressed, and under non-free Licence).

Re:Not impressive (0)

Anonymous Coward | more than 2 years ago | (#36652182)

This reeks of goatse...

Re:Not impressive (0)

Anonymous Coward | more than 2 years ago | (#36652186)

Parent is goatse. Dammit, and I've avoided it for a decade.

Re:Not impressive (1)

mwvdlee (775178) | more than 2 years ago | (#36652226)

https://github.com/andreasgal/pdf.js [github.com] (It's BSD licensed, minus the credits clause).
Who's the asshole now?

The one true markup (3, Interesting)

Ed Avis (5917) | more than 2 years ago | (#36652208)

This is really cool. Now we just need to have web2js instead of web2c, and we can typeset documents with TeX in the browser.

Re:The one true markup (2)

TheRaven64 (641858) | more than 2 years ago | (#36652366)

I've written a clang plugin that translates C to JavaScript, so it should be possible to chain that with web2c to produce JavaScript...

Re:The one true markup (0)

Anonymous Coward | more than 2 years ago | (#36652556)

Is this comment for real?

N.

Re:The one true markup (1)

zhiwenchong (155773) | more than 2 years ago | (#36652704)

Are you sure you want to do that? I can understand typesetting math in the browser, but typesetting entire TeX documents?
There's already an AMS-endorsed way of typesetting TeX math (Javascript-based) called MathJax (http://www.mathjax.org/), and it works pretty well (well enough for sites like http://mathoverflow.net./ [mathoverflow.net.]

What's the point? (0)

devent (1627873) | more than 2 years ago | (#36652250)

I'm the one who finds this "We do all things now in the browser" highly suspect. I already have a perfectly fine Pdf viewer, called Okular. Why not just give me a link to the Pdf file, so that I can download it, use my favorite Pdf-Viewer and print it out if I like?

I would really appreciate their affords, but I just known this is not done for my convenience, but for cooperate interests. The only reason this is developed, so that they can put some Ads inside the Pdf file, prevent me from downloading it or printing it. Like Slideshare, but without Flash.

Maybe the second reason is, so I can view Pdf files in iPad or similar device, such don't have a Pdf viewer. But that is cooperate interests again, because they can much easier prevent me from installing software I like, and force me to use their software.

Re:What's the point? (1, Informative)

paimin (656338) | more than 2 years ago | (#36652320)

Bzzzzt! iOS handles viewing and saving PDF's fine. Thank you for playing "I Bashed Apple on Slashdot". Try again.

Re:What's the point? (1)

tepples (727027) | more than 2 years ago | (#36652364)

I already have a perfectly fine Pdf viewer, called Okular.

From Okular's web site [kde.org] : "For Windows have a look at the KDE on Windows Initiative webpage for information on how to install KDE on Windows." The download page on KDE Windows Initiative [kde.org] links to detailed installation instructions [kde.org] . I'm not in a position to try it myself because the PC on which I'm typing this has integrated graphics, which isn't enough to run KDE according to a forum post [google.com] linked from a Google search for kde system requirements.

Re:What's the point? (1)

PeterBrett (780946) | more than 2 years ago | (#36652622)

I'm not in a position to try it myself because the PC on which I'm typing this has integrated graphics, which isn't enough to run KDE according to some idiot who doesn't know what he's talking about.

Fixed that for you. KDE 4 works perfectly with integrated graphics, you just have to turn desktop effects off. It's perfectly usable without desktop effects enabled, all applications detect it and degrade gracefully, and all the controls etc. work pretty much the same. I have a laptop with integrated graphics that doesn't support desktop effects, and I don't notice the difference apart from once a week or so when I suddenly wonder why my terminal emulator doesn't have a transparent background.

This graceful degradation is a pleasant contrast to GNOME 3, I might add.

Re:What's the point? (1)

makomk (752139) | more than 2 years ago | (#36652758)

Is this a troll, or did you just spectacularly miss the point? That forum post is fairly obviously about the system requirements for the KDE equivalent of Aero Glass or whatever it's called these days...

Re:What's the point? (1)

Anonymous Coward | more than 2 years ago | (#36652706)

The end game is that by shifting focus from desktop applications to cloud applications makes the desktop operating system much less important.
Envisage a day when you dont need to run just so you can run that one specific app.

this might sound over the top - but i am sure that given time we will be able to play the new "Crysis" (whatever that might be) in the browser on any operating system. (of course there will still likely be some beefy hardware requirements and a juicy broadband). Although im fairly confident that day will come - and probably not as far of as we think! Developers can target the one platform to rule them all.

tinySVG support preferred. (1)

sgt scrub (869860) | more than 2 years ago | (#36652278)

pdf is old vector graphics news. If they want to help a parky [google.com] out they can get TinySVG support built in to Firefox so I can finish rebuilding all of my XUL UI's in SVG. ...that don't work now unless the user knows how to re-enable support then ends up getting owned instead of a warning like getting a self signed cert... Cough. Sorry. Oh while I'm dreaming, getURL, putURL, and parseXML functions so I don't have to "if typeof (parseXML=='undefined')" override them every time would be nice too :) Oh and those wondering about the relationship here, pdf to svg is easier to convert and display on the fly. Well. For me. So programmers can probably do it in their sleep. Oh. Oh. And a pony.

vector PDF screenshots (0)

Anonymous Coward | more than 2 years ago | (#36652280)

On the other side of things, it is possible to do vector PDF screenshots of GTK+ apps, including browsers:

https://www.joachim-breitner.de/blog/archives/508-gtk-vector-screenshot-works-with-epiphany.html

Carts before horses (1)

macraig (621737) | more than 2 years ago | (#36652390)

I find it quite hilarious that people speak seriously about coding artificial intelligence as if it will happen in the this decade, when at the same time we can't even achieve a consistent rendering of the same elements in different browsers.

Re:Carts before horses (1)

Blobule (913778) | more than 2 years ago | (#36652480)

These problems are generally disjoint. Identical cross browser rendering depends on everyone playing the standards game or everyone playing the let's add fixes for every browser game. The AI problem depends on solving the problem of genuine artificial intelligence without the need to pay attention to cross platform compatibility. That said, I doubt we'll see real AI this decade either :)

Re:Carts before horses (1)

Kz (4332) | more than 2 years ago | (#36653838)

You're missing the goal: we need strong AI so that all web documents can be sentient. That way, they'll do a conscious effort to be usable on any kind of browser. See? it's not because AI is cool, it's our only hope!

Fun fact: (4, Informative)

giuseppemag (1100721) | more than 2 years ago | (#36652396)

I can render a PDF perfectly on all OSes I own (Windows, OS X, iOS, Windows Phone 7) already!

Re:Fun fact: (0)

Anonymous Coward | more than 2 years ago | (#36653658)

Funner fact: those platforms also render malware perfectly. <channelling John Hodgeman>You're welcome.</channelling John Hodgeman>

NOT standards compliant!!! (0)

Anonymous Coward | more than 2 years ago | (#36652458)

Javascript is NOT STANDARDS COMPLIANT. All you js bozos who keep claiming it is are morons. Until the ecma standard is committed to by ALL browser vendors it never will be! That means you M$ dumb$41ts.

Over reach much? (2)

FlyingGuy (989135) | more than 2 years ago | (#36652504)

This is just silly. While I can appreciate it from a point of curiosity and it is probably a fun project, this is really overloading the browser.

I would submit that things like this are actively breaking the browser paradigm. Every PDF viewer allows you to save a local copy of the PDF after they have read it from the temp directory or the download directory. To implement this thing correctly is would require that JS have direct access to the file system, which as I understand it, aint fucking supposed to happen, since that would create untold numbers of security problems in a system already plagued by security problems.

While there may be arguments that this would be ok, they would all be moronic.

The entire notion of the browser needs to be forked out to an application shell with hard as nails security and a presentation shell and never the twain shall meet.

Re:Over reach much? (1)

jlebar (1904578) | more than 2 years ago | (#36653460)

To implement this thing correctly is would require that JS have direct access to the file system, which as I understand it, aint fucking supposed to happen

Too late. [w3.org]

The entire notion of the browser needs to be forked out to an application shell with hard as nails security and a presentation shell and never the twain shall meet.

What a novel [chromium.org] idea [webkit.org] !

Re:Over reach much? (0)

Anonymous Coward | more than 2 years ago | (#36653970)

Just because "every PDF viewer" does it, doesn't mean it's a good idea, much less a necessary feature. It's just plain nonsense to have this inside the JS/PDF renderer, since the browser itself can already save the PDF. Just press Ctrl+S.

Re:Over reach much? (1)

StripedCow (776465) | more than 2 years ago | (#36653990)

Next step: implementing gecko or webkit in javascript, so that developers have the same experience everywhere.

In fact, now that I'm thinking of it, that would not be such a bad idea.

Re:Over reach much? (0)

Anonymous Coward | more than 2 years ago | (#36654370)

Well, we already have QEMU [bellard.org] in javascript so why not run a full VM + OS to read your PDF?

So not only do you need to make sure your browser runs on all OSes (or OSen if you must), you need to make sure all OSes can run in your browser!

OpenDocument (0)

Anonymous Coward | more than 2 years ago | (#36652764)

A similar project exists for OpenDocument format. It is called WebODF [webodf.org] . It handles texts, spreadsheets and presentations. It's not perfect yet though.

Nice way to open even more holes in the browser (2, Funny)

Anonymous Coward | more than 2 years ago | (#36653342)

Direct2D and DirectWrite? Sorry but browser graphical acceleration must end.
WebGL should be implemented with no hardware acceleration, using graphic card emulation.

Re:Nice way to open even more holes in the browser (1)

Skuto (171945) | more than 2 years ago | (#36654330)

Neither are related to WebGL specifically. They're used for much more mundane things such as Canvas rendering.

It's not doing the rendering (1)

Animats (122034) | more than 2 years ago | (#36654372)

The Javascript code isn't doing the rendering of text. It uses dynamically loaded fonts and lets the platform's own font renderer render the glyphs. The Javascript code isn't pushing pixels.

There's less need for PDF than there used to be, now that you can download fonts in the browser. It might be worthwhile to take this PDF viewer and turn it into a server-side PDF to HTML translator.

HTML / Javascript - sigh (0)

Anonymous Coward | more than 2 years ago | (#36654870)

I bet they could do it in a week with XAML...

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...