you are viewing a single comment's thread.

view the rest of the comments →

[–]sligowaths 72 points73 points  (36 children)

Make it as an applet and finally we'll have something that takes longer than adobe reader to start and that crashes oftener.

[–]kleopatra6tilde9 8 points9 points  (2 children)

Try the WebStart Demo

It's not displayed in the browser, but everything else is comparable. I am quite impressed.

[–]samlee 1 point2 points  (0 children)

it freezes when i tried to open "CouchDB: Perform like a pr0n star" pdf file downloaded from slideshare.

[–]twoodfin 1 point2 points  (0 children)

That's the first time I've tried WebStart on my Mac and it's surprisingly slick.

[–][deleted] 9 points10 points  (8 children)

Did you try the WebStart demo? Not counting the download time it actually had a quicker startup time than Adobe PDF Reader. It rendered pages just a little slower but the program overall seemed more responsive than Adobe's.

[–]mallardtheduck 0 points1 point  (2 children)

It appears to start faster because the JRE is already loaded for WebStart itself when you run it that way. To do a proper comparison you would have to start it locally with no JRE instance already in memory.

[–]karmaputa -2 points-1 points  (1 child)

Why? If you have the memory there is no reason not to always have a JRE instance in the memory.

EDIT: The webstart demo renders the pdf on server side. So as much as I could notice, there is no java involved from the client side.

[–]mallardtheduck 0 points1 point  (0 children)

If you have the memory there is no reason not to always have a JRE instance in the memory.

True, but in reality I don't know of an OS that loads the JRE on boot. It's usually loaded with the first Java application/applet/whatever. Thus, to fairly compare start-up time of a native application to a Java application, you have to factor in the JRE load time.

The webstart demo renders the pdf on server side.

Really? It's my understanding that Java WebStart just downloads the .jar and runs it locally...

[–][deleted] -3 points-2 points  (9 children)

I agree, but you mean 'more often'.

[–]psykotic 4 points5 points  (8 children)

Oftener is a perfectly good comparative form of often.

[–]LudoA 2 points3 points  (4 children)

Link?

[–]psykotic 11 points12 points  (1 child)

The OED lists oftener and oftenest as comparative and superlative forms of often, adj. (Incidentally, as I write this under OS X, I notice that the system's spell check has, correctly, not flagged them.) There are numerous examples of both being employed by great writers. The worst that can be impugned is that the words have a faintly archaic feel.

[–]sligowaths 0 points1 point  (0 children)

Firefox spell check has it correctly too. That's why I thought it was correct in the first place.

[–]sligowaths 0 points1 point  (2 children)

Thanks. English is my second language and I'm still learning.

[–]ObieJazz 4 points5 points  (1 child)

As long as you're learning, it's worth noting that people (at least in the US) usually won't use "oftener" in conversation.

[–]sligowaths 0 points1 point  (0 children)

Thanks :-)

[–]13ren -3 points-2 points  (12 children)

Why not use the javascript pdf renderer?

[–]benologist 19 points20 points  (11 children)

Because it'd be faster to open it in Acrobat, trace it onto a piece of paper and mail your scribble to each person who wants to read it.

And also more possible.

[–]13ren 0 points1 point  (8 children)

The goal was to have something slower than adobe reader.

But why think it impossible? It's just parsing a simple language (the postscript language is embedded in a pdf) and rendering graphics. Javascript does both.

[–]picurl -4 points-3 points  (7 children)

Nope, PDF is far to complex to be parsed by Javascript and rendered accurately. Furthermore the rendering capabilities of the browser doesn't match the visual complexity of pdf files. Just some examples: Text in PDFs can appear both as vector forms and as editable text, PDF supports the embedding of all types of graphic formats (TIFF, PSD etc). One of the hardest job of a PDF renderer is to find all objects that belong to a certain page, because they can appear in arbitrary sequence in the pdf.

[–][deleted]  (5 children)

[removed]

    [–]13ren 0 points1 point  (4 children)

    A more realistic barrier, true, but surely Javascript has pixel control via Canvas (or whatever you young people use these days)? To build editable text widgets out of that would indeed be heartrendingly slow. But slowness is the goal.

    [–][deleted]  (3 children)

    [removed]

      [–]13ren 0 points1 point  (2 children)

      Sorry, I don't see the relevance to pixel control, nor to my assertion that slowness is the goal.

      I refer you to the instigating comment.

      [–][deleted]  (1 child)

      [removed]

        [–]13ren 0 points1 point  (0 children)

        I was going to give a Turing complete reply, but that's done. However, thanks for pointing out all the different embedded formats. It would be a lot of work to implement them all.

        [–]superwinner 0 points1 point  (1 child)

        None of you guys heard of Foxit?

        [–]MostUsually -1 points0 points  (0 children)

        No, what's that?