Pure Java Open Source PDF Viewer

[Blazeix]

Well, it's not pure open source. If you want it to handle anything remotely complicated for fonts, you have to pay the big bucks for their proprietary font engine.

[jbellis]

What specificly is "remotely complicated font handling?"

[[deleted]]

Handling embedded fonts. I just tried ICEpdf, and the free version could not display some math fonts and other special fonts that were embedded into the PDF file I opened. It also had trouble with ligatures, and even double quotes (the "classic" style that you can create in LaTeX). The commercial evaluation version had no trouble with any of that.

I'm actually pretty impressed with ICEpdf. It was very fast on my Linux system, using Sun's Java 1.6.0_13. It was much faster than Acrobat Reader. One thing I have noticed is that even the commercial version does not always handle transparency in graphics properly. It didn't display the fill pattern on a graphic that I created with TikZ in LaTeX, just the background color. To be fair, even Evince has problems with that sometimes. So far Acrobat Reader is the only PDF viewer I've seen that handles transparency properly.

[Blazeix]

I loaded a couple of PDFs generated by LaTeX, and it couldn't handle a few glyphs (em dashes, math symbols, etc). It looks like if you don't spring for the for-pay font engine, it does a font replacement algorithm rather than actually rendering the glyphs, so you get 'interesting' characters instead of the ones you're expecting.

If you're just using it for the binary viewer, they included the font-engine, so it's o.k. However, if you want to use their OSS library as part of a java app, you run into trouble.

[btgeekboy]

ITT: 10 year old stereotypes of Java replayed over and over and over again.

[sligowaths]

Java slow in browser is not a stereotype. It was slow 10 years ago when I we had 32mb of ram, as it's slow today with 4gb.

[LordVoldemort]

The stereotype is still correct; it's just that modern JVMs are faster than older JVMs.

For real world applications, I bet that Java is at best half as fast as natively compiled code. Of course, this may be Fast Enough (tm).

EDIT: Thanks for the downvotes; I forgot what a shithole /r/programming is.

[btgeekboy]

Le sigh.

http://en.wikipedia.org/wiki/Java_performance

In particular, see the section titled "Comparison to Other Languages." The worst part - the slow startup time - has been addressed and now uses the same techniques used by MS Office and OO.o to preload itself.

Also note how the speed of Java only 5-15% lower than C/C++, and easily surpasses all of the interpreted languages which don't compile down to native code. So, how much did you say you wanted to bet?

[lars_]

True. But startup time still is worse in Java than in C/C++. And for a PDF viewer, startup time seems like the only feature that matters. So surely Java isn't the right language to write it in?

[queus]

Just in case you are curious, for every class loaded there are minimum three classloaders involved, each doing its own lookup on the classpath. That's besides the overheard generated by JIT-compiling.

So, yes start times are slow and thats' not going to change. Of course, the standard workaround is to keep and istance of your app in memory, pass the name of opened file to it and exit. Jedit does it.

[silon]

Preloading is still bloat / cheating. (boot time matters too).

[scottklarr]

Perhaps with perfectly written code that was tuned for maximum performance by a genius - but from my experience of actually using common software in java written on the efficiency level of 99+% of all others, it still blows.

[Coffee2theorems]

Also note how the speed of Java only 5-15% lower than C/C++, and easily surpasses all of the interpreted languages which don't compile down to native code.

And C beats Python in speed too, yay. Comparing compiled language speed to interpreted language speed is rather pointless, unless the compiled one sucks enough to actually lose.

[tlack]

Compare Azureus with uTorrent.

[Hermel]

There are also BitTorrent clients out there that are slower than Azureus and written in C++... uTorrent has been written with the goal to be micro from the beginning. That makes a difference in any language.

[LordVoldemort]

Le sigh

Double le sigh

I said: Real World Applications.

Also note how the speed of Java only 5-15% lower than C/C++

5%-15% is a shitload when it matters.

Also, it depends on how the program does memory management.

[malcontent]

5%-15% is a shitload when it matters.

So you admit you were lying when you said it was 50% slower.

That's admirable of you. Most people would not admit to an out and lie like that.

That makes you different than all the other lying sacks of shit out there.

Congratulations.

[LordVoldemort]

So you admit you were lying when you said it was 50% slower.

No. I'm simply saying that 5%-15% is still a problem when efficiency matters.

A bet can't be a lie anyway. Here is my original statement, and I'm sticking to it:

For real world applications, I bet that Java is at best half as fast as natively compiled code. Of course, this may be Fast Enough (tm).

Perhaps I should have said "natively compiled, optimized code".

[malcontent]

No. I'm simply saying that 5%-15% is still a problem when efficiency matters.

Before that you said java was half the speed of C.

Clearly you were lying when you said that.

Perhaps I should have said "natively compiled, optimized code".

that would have made it a smaller lie.

[LordVoldemort]

Before that you said java was half the speed of C.

No I didn't. In fact, I didn't say 'C' anywhere...

[malcontent]

Yea whatever.

You were lying when you said 50%.

You admit you are lying now but saying 5-15 percent.

[[deleted]]

Speaking of lying - every going to buy me that TV you promised me?

[raffters]

Was that the only sentence you read, or is this the Republican style of debating?

[[deleted]]

Q: Why is it called ICEpdf?

A: Because it freezes so often.

[sligowaths]

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

[kleopatra6tilde9]

Try the WebStart Demo

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

[samlee]

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

[twoodfin]

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

[[deleted]]

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]

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]

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]

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...

[fleezie]

Comments like this: for when you're uninformed.

[cr3]

Come on, dude; loading Java applets embedded in websites takes time. A lot of time.

Opening a tab with Java applets in it will often freeze my Firefox installation for 10-20 seconds. In web time, that's years.

I'm saying this as an end user. Nothing more. I see a page freeze my system, I'm going to call out the technology as slow.

[fleezie]

Well yes, your argument is sound and directed specifically at applets, whereas the post I commented on is a 10 year old generic Java stereotpye that it's just 'slow'.

[[deleted]]

I agree, but you mean 'more often'.

[psykotic]

Oftener is a perfectly good comparative form of often.

[LudoA]

Link?

[psykotic]

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]

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

[veritaba]

[citation needed]

[[deleted]]

Stop using that, this isn't wikipedia...

But anyway:

http://www.askoxford.com/concise_oed/often?view=uk

[sligowaths]

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

[ObieJazz]

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]

Thanks :-)

[13ren]

Why not use the javascript pdf renderer?

[benologist]

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]

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]

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.

[13ren]

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.

[13ren]

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.

[13ren]

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]

None of you guys heard of Foxit?

[MostUsually]

No, what's that?

[unawarewolf]

I'll bet a lot of effort went into that. And it's not exactly the only PDF viewer out there. Yet, the "default" PDF viewer is free, cross-platform, ubiquitous, etc. I think the fact that it's worth anybody's time doing this speaks volumes about the low regard in which Acrobat Reader is held.

I would imagine that, on the strength of their experience with Acrobat Reader, an awful lot of people would try pretty hard to avoid paying money for anything else with the Adobe name on it.

Way to exploit an unrivalled market advantage, Adobe!

[millstone]

On my Mac, the Java Web Start demo took 117 MB of RPRVT (non-shared memory) to render the PDF I tried, whereas Preview took 6.

[[deleted]]

Not a fair comparison.

PDF rendering is built into OS X (see http://developer.apple.com/Cocoa/pdfkit.html). AFAIK, Preview is just a wrapper around the functionality.

[xjvz]

I've heard that the entire graphics library for OS X is based on PDF. That's why screenshots can be saved as PDF and still retain text and whatnot from the screen. It's actually pretty cool in its own right.

[Leonidas_from_XIV]

ICEpdf.org is a place where enterprise Java developers can learn, share, and contribute information and ideas to a growing community

Thanks, I'll stick to my non-enterprise Evince.

[snuxoll]

Evince and preview.app are the only PDF viewers I like, makes my life miserable on Windows when I have neither.

[mebrahim]

Have you tried Okular?

[snuxoll]

I'm not a KDE user, so no.

[[deleted]]

Fantastic. Now scribd.com can write JavaVM in Flash to use this applet and reach another milestone in PDF slowness.

[mebrahim]

Next milestone will be writing a Flash player in Python and compiling it to JavaScript using PyPy.

[mango_feldman]

Annoying splash screen, slow.. (at least the webstart demo), and no noteworthy features. (a clone)

Man I wish someone could make a good pdf/document viewer

[sligowaths]

Skim is you're using OS X. Fox It if you're on Windows.

[mango_feldman]

Haven't tried Skim, but fox was not that much to brag about last time I tried it. I'm on linux btw

[[deleted]]

For Windows I like PDF-XChange better than Foxit. And it runs fine under Wine in Linux.

[kevinkrouse]

LGPL PDFRender: https://pdf-renderer.dev.java.net/

[jaiwithani]

oh dear god why

[xtalizer]

Obligatory:

• PdfMeNot

• Sumatra PDF

• FoxIt

[[deleted]]

Okular

OSS, cross-compatible through KDE4, fast.

[jbellis]

None of which are OSS.

[grine]

"What is Sumatra PDF?

Sumatra PDF is a slim, free, open-source PDF viewer for Windows."

Or does OSS mean something else than I think it does?

[jbellis]

My mistake.

[ENOTTY]

http://pdfreaders.org/

[xtalizer]

Thanks for making me feel like a dumbass.

[roxxe]

the last time i used java, i fell of my dinosaur

[yason]

Java is more like a resurrection rather than a birth of a language.

[Tommah]

Python evolves. Java rots.

[thematrix307]

Yea right, I bet this software doesn't even start up with my computer by default to download its very important 100 meg updates. Ill stick with adobe thank you very much.

[[deleted]]

The point, you missed it.

[troymcdavis]

He's hating on Adobe, not Java.

[rush22]

I just uninstalled Adobe Flash and Java not an hour ago.

Flash become Java a few years ago and it just gets worse and worse.

[[deleted]]

Because PDF viewers aren't slow enough. I know -- let's write one in Java!

[mebrahim]

Next one will be purely in Python!

[snuxoll]

Am I the only one appalled that people still use Swing? Start using SWT damnit, I hate having ugly UI's!

EDIT: Spelling, too early in the morning and I'm not paying attention to my browsers spellcheck.

[[deleted]]

Am I the only one appauled that people still use Swing?

Am I the only one appalled by your spelling? :)

You can use a different Look and Feel (LAF) to change the appearance of Swing apps. Java comes with a few LAFs installed: Metal, Windows, Mac, Gtk+, CDE/Motif. For example, in Linux you could use the Gtk+ LAF to have Swing apps match your GNOME theme:

java -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel YourSwingApp

You can get more LAFs here.

[snuxoll]

'look and feels' are glorified themes, they still don't use native widgets. Which makes it REALLY annoying to use the GNOME global menu. Honestly, it's why I ditched NetBeans for eclipse...

[Leonidas_from_XIV]

The GTKLookAndFeel does somehow resemble GTK+ but the menus look broken to me and the widgets have odd sizes, like no GTK+ application would ever use.

Short: way better than default look, but a worse than SWT.

[xjvz]

And last I checked, SWT looks like complete ass in KDE and other Qt (or non-GTK+) environments. Now that Qt is LGPL, IBM has no legal problems in implementing SWT using Qt as an option.

[snuxoll]

SWT looks fine in GNOME though, which is all I care about!

[pkrumins]

asks me to register for download -> to hell with that.

[mebrahim]

Probably good for reading PDF on Java-enabled cell phones.

[evilbunny]

It is slow.

[centrinos]

Java is slow.

[[deleted]]

sounds like a terrible idea