The Road to KDE 4: Okular and Ligature Document Viewers

Focusing again on applications this week, specifically I'll look at two of the promising document viewers for KDE 4, Okular and Ligature.
They are two of the rising stars of KDE 4, but they both have their
roots as KDE 3 applications that have grown up. Read on for more...

In the past, KDE has had a wide variety of programs designed for viewing all sorts of file formats, and using the KParts technology of KDE, these viewers were able to be embedded into other KDE applications such as Konqueror as and when they were needed. Supported formats included TIFF, PDF, PostScript, fax, DjVu files, and many more. okular and Ligature have grown up from some of these earlier designs to become much more than simple document viewers.

Historically, KDE has shipped with a program called KGhostView, which used the GhostScript backend to render PDF and PostScript files for display. KDE has even used it as the Print Preview utility. What follows is a shot of KGhostView in action for KDE 3.5.6. Please note that some of the font rendering glitches may be due to the font selection of my distribution, and are not necessarily a reflection on KGhostView's ability to render this file.

In the KDE 3 series, a new contender emerged for viewing PDF files that was much faster than KGhostView. This new program, KPDF, has since eclipsed KGhostView in many important areas, like functionality, speed, and so on. KPDF is shipped with many modern distributions as the default PDF viewer for KDE. Below is the same file as viewed with KPDF.

From personal experience, KPDF has been the subject of some of the 'oh wow!' type experiences I've had while using KDE. I've clicked on web links to PDF files that specify 'frame' as their target, and had KPDF embed quickly and seamlessly, so much so that for a moment I forgot that the frame wasn't HTML anymore.

It also has quite a few advanced features that KGhostView never really pulled off, such as text searching, copy and paste from PDF, and more. It is also many times faster at rendering, especially when loading PDF files containing a lot of vector imagery. I use a lot of maps in my work, which often ship as PDF files - using KGhostView to view these files was incredibly slow, as you could literally watch the vectors being drawn on the map. KPDF would load the same map visible instantaneously, letting me do my work instead of waiting for the computer.

KPDF recently made the decision to broaden its support and start to view files of types other than simply PDF, partially thanks to coders sponsored by Google's Summer of Code program. The main reason they decided to do this inside KPDF instead of starting new, individual applications is that KPDF already had many advanced features implemented that didn't necessarily need to be duplicated for these other file formats. To more accurately reflect its broadened scope as a viewer for many file formats, it has been rebranded as 'okular'.

Users of KDE 4 are in for a treat with both okular and Ligature, as they are both shaping up to support a wide variety of (occasionally overlapping) media formats. But since they can both be embedded into KDE applications using standard interfaces, a user should be equally happy using either one of these viewers. I'll talk about okular first, since I have more information sources for it. Huge improvements are noticeable in okular over the already very functional KPDF. So far, it looks to be one of the best applications of KDE 4.

Pino Toscano (pinotree on is the lead developer of okular. Currently it is being developed in KDE SVN and its sources are available in
for anyone who is interested in trying it out. It is already quite stable in the KDE 4 environment - actually it is one of the most stable KDE 4 applications I've had the pleasure of testing so far. It is also known to be building as part of the KDE/Mac packages. Benjamin Reed submits the following screenshot showing okular in action on the Mac:

He also adds: "Holy crap, okular is fast on OS X. No more Acrobat for me! :)"

I didn't test all of these formats myself, but according to its Supported Formats list at the okular website, it already has full or partial support for the following 11 document types: PDF, PS, TIFF, CHM, DjVu, DVI, XPS, OOo, FictionBook, ComicBook and standard graphics files. Work continues on making sure that support for all of these formats is flawless, and more formats may be added down the road. The okular that is released alongside KDE 4.0 may or may not have all of these formats enabled, depending on their stability at that time, as well as choices that your distribution may make.

Below is a shot of okular viewing the ComicBook format, often used to distribute comics online. Indeed, okular may end up becoming one of the most popular ComicBook viewer applications, especially considering how many platforms it will run on courtesy of KDE 4.

Pino has shown his willingness to work with the usability folks to help improve the ease of use of okular, and it is now part of the Season of Usability project. It will likely see a fairly-thorough overhaul of many interface elements before KDE 4.0 is released which can only make this application even better.

The other contender for your document viewing needs in KDE 4 is Ligature, recently renamed from KViewShell. It lives in the kdegraphics module, so it is currently the default viewer for the files that it supports. It could however be overridden such that okular is used by anyone who prefers using okular for a given format. The only reason I can find for Ligature to be in the kdegraphics module rather than okular is historical - KViewShell (which Ligature is based on) was part of kdegraphics in the past. However, this doesn't mean KDE is shunning okular either: for example, Amarok is one of KDE's best applications, though it doesn't reside in the official kdemultimedia package.

Ligature currently sports support for PDF, PostScript, EPS, fax, Tiff, DjVu, and TeX files based on the plugins available in SVN. I'm under the impression that 'fax' is for a sequential image type format using TIFF files. Its predecessor, KViewShell did not have support for several of these formats in the main kdegraphics branch, but a separate branch exists for these formats for KDE 3.5.x.

I tried to get a screenshots showing Ligature displaying PDF files, but it wouldn't load them. I tried a PostScript file, and it loaded it but did not display anything. So, I had to resort to a rather boring DVI file in order to show off the current state of the user interface, but this does not show off its rendering capabilities very well.

It does bear a close resemblance to okular as far as its user interface is concerned. This is mostly due to the fact that they utilise the same standard Qt and KDE libraries to draw many of the user interface elements. Since I could not get it to render any documents, I could not compare its actual usability to okular. Please keep in mind, however, that it is in a state of development at the moment, so being broken on any given day is nothing to be overly concerned about.

A note about DVI files in general: to view them you need to install some TeTeX files, which on my distribution totals 85 megabytes - a likely reason why DVI files are not a popular format for documents despite their competent rendering abilities. When Ligature finds a hyperlink in a DVI file, it underlined the text in blue to indicate that you could click on it, which while useful in some circumstances, made documents with links look quite ugly. okular on the other hand does not underline links in DVI files, but they still work as expected.

For those wondering about duplication of efforts, okular and Ligature use different internal architectures, but many of the library dependencies depend on are the same (much like how MPlayer and xine have very different internals, but can still use the same low level libraries to decode media). This means that while they cannot easily be merged into one project, any work that trickles down into the lower level libraries will be beneficial to both projects. Regarding availability, okular will be available wherever your distribution packages it, and since most distributions end up splitting packages like kdegraphics into their constituent apps anyway, Ligature will fall into the same category for most users. Of course, GNOME users can also use okular or Ligature as well, if they have the required KDE libraries installed, but of course they can also use Evince which shares many of the same backend libraries, but is better integrated into the GNOME environment.

That's all for this week folks. Hope this clears up any confusion about the nature of both okular and Ligature.


by zonk (not verified)

ad. 5
Yeah, it's not _needed_. But still MUCH more useful to the majority of ppl than some apps that DID get to the base. Think KPovModeler, for example...

by otherAC (not verified)

it takes two to party, and if the teams of amarok, gwenview, kaffeine etc. don't want to get tied into the core kde packages, then it's not going to happen....

by Marc (not verified)


I too think that KDE needs much more focus on usability and stability. Using KDE nowadays feels like many features have been roughly implemented but not been tested and stabilized enough. Many things are just buggy like mediamanager or kdesktop, which I think are nice and important parts of KDE but they are way too buggy.

by Dima (not verified)


In my case, Konqueror is the app that crashes the most. I'm tired of submitting bug reports.

by atte (not verified)

Konqueror? Crashes? I don't recall such thing happening to me and I'm using kde on _fedora_, for chrissakes. Plus I have konqueror always open (and I mean always, I practically never log out).

by otherAC (not verified)

can you point us to some of those bug reports?

by Artem S. Tashkinov (not verified)

Konqueror crashes when
1) Opening certain SVG files (bug reports already exist)
2) Using embedded kaffeine/video kpart and watching certain videos

by Thiago Macieira (not verified)

Stop using Kaffeine. Use the KMPlayer part and your crash problems will be solved.

by litb (not verified)

don't use kaffeine. it is very bugy and slow. use KPlayer. it is very stable, fast (based on mplayer) and has a stable kpart for konqueror too. your crashes will go... it is not konquerors fault!

by Bernd (not verified)

Ok, I don't get it. What the deal?
I thought Kaffein is to become the default video player for KDE.
KMPlayer isn't even in the main repositories of my distro (kubuntu).
Personally I just tried KMPlayer again because you guys mentioned it,
and I have to say, I prefer Kaffein. I think it just looks better. ;)
Yes, I can the confirm that kaffein is sometimes crashing the Konqueror, but I don't often preview videos in Konqueror.
Maybe someone could elaborate why Kmplayer should be better, except that it's more stable, which i think is a very blury statement.

by otherAC (not verified)

I think you should check your installation.
kde is rock solid on all my machines, no crashes at all..

by Diederik van de... (not verified)

> 1) Much faster applications start up

Agreed :)

2 seconds is not fast enough. I always have a second until an app launches. It should be "boom! within one second".

This is mainly a GNU linking issue though. All apps with similar symbols (e.g. functions names gaim_...()) suffers from this. All C++ functions also have a similar prefix (the classname / return value) suffer from this, including Firefox and OpenOffice. Ever noticed Firefox starts up faster in Windows? ;)

by Anon (not verified)

I think Thiago has been working on this with KDE4, trying out the -fvisibility=hidden/ protected/ whatnot GCC flags. I can't remember what his conclusions were, though.

by Thiago Macieira (not verified)

We're working on that, but it will take a fairly recent gcc and binutils to make most out of it. I.e., gcc 4.2 and binutils not yet released at the time of this writing.

by Tim (not verified)

> This is mainly a GNU linking issue though.
Perhaps Firefox is compiled without visibility=hidden? On Windows this would not be a problem (exports are private by default).

by Marius (not verified)

I like your windowdecoration color, what color do you use for the inactive windows?

by Troy Unrau (not verified)

For KDE 4, I use the defaults. In fact, I delete .kde each week to ensure that my shots are accurately showing off the evolving defaults for KDE 4. (Next week will show off some newly minted oxygen stuff, as that is now slowly becoming the default.)

For KDE 3.x, I use #6569AE blended with #7B69B8 for active titlebar, and #DFE1E6 blended with #9D9EBA for inactive titlebar. I use the Crystal window decoration and the Plastik style. Other than a minor palette tweak or two, these are mostly the kubuntu defaults I believe... however they may be the defaults from a few releases ago, as I've been upgrading rather than reinstalling.

Hope that answers your questions :)

by Bert (not verified)

Other plattforms as Mac or Win will be very important in the KDE4 process as the next generation KDE applications would already run there. I think pdf viewers would be a great advertisement instrument for KDE on the MAC. And users are important to mature an application and find or close bugs. Everybody hates the slow Acrobat Reader. So okular or ligature can really become the Firefox of pdf reading.

row at it and also display them correctly AND allow me to edit forms? Or else i'm not interested.

i'll stick to adobe reader.

In fact, I would be happier with only adobe reader on linux instead of kpdf, evince, etc etc etc because atleast then, the users doesn't have to waste his time on trying out different pdf viewers only to discover that the only one that supports the most basic(basic - as it's the whole point of the program; to be able to view pdfs and annotate forms) functionality is in a proprriatory app.

In fact, i'd rather youd scrap both okular and ligature if it meant that the backend library would get more work and eventually support this functionality. Then i'd just use the "old" pdf viewers, only now i'd be assured that they actually WORKED.

Too hard? Then.. if you truly care about your users atleast pop up a message that tells the user that not all pdf's will work and display correctly when you open the program. In fact i'd like one for mplayer aswell and amsn telling me which formats/functionality and movies they DOESN'T support as this is more useful than being told it works "for most".

This is something users will be GRATEFUL for, it's not something they will get ANGRY for... Oh well i have a hangover so this text is a bit weirdly written but my point still stand.

Not likely to happen, as such information usually already exists in the form of TODO lists that are on these application's websites. See the Supported Formats list for okular, for example.

Poppler (the PDF lib powering Evince, Okular, Ligature...) is pretty great, and I've never had a problem rendering a PDF with that library so far. The existing applications that you are referring to, like kghostview, use other libraries that are less maintained. The Poppler library really is becoming the king.

That said, I don't know the status of forms, since I've never encountered a PDF form in my life... other than the fact that I'm aware of their existence...

> telling me which formats/functionality and movies they DOESN'T support
> as this is more useful than being told it works "for most".

Imagine walking into a car dealer and the first thing the sales guy tells you about a car you are looking at is what doesn't work and what it can't do. Is that going to make you think it's a good car? Do car dealers usually do that? No, of course not. People would never see notices like that as something useful or positive - it would just discourage them from using the applications, even if they would be perfectly fine for their needs.

As for PDF forms, you consider this basic functionality, but for me I have never needed to fill in one, or even seen one. Besides, it has already been stated that the functionality will appear when it gets supported in the base library.

by adrian (not verified)

Isnt the reason for, why amarok is not in the official kde packages, because they don't want to be?
As far as I remember they don't like kde's release cycles wich are quite unflexible. Same aplies for k3b I think.

by ligature (not verified)

to open pdf files in ligature, you need to install poppler (and the devel libs) first. w/o poppler, ligature installs fine, but it won't read pdfs.