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 irc.freenode.org) is the lead developer of okular. Currently it is being developed in KDE SVN and its sources are available in
/trunk/playground/graphics/okular 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.

Comments

I have found a small trick that works rather well, to extract specific pages : I print them using the PDF pseudo printer of Kprint, selecting the appropriate pages in the process. It generates a new file with the pages you want.
Maybe playing with the print settings and order of printing should allow you to rotate and move pages.

An important feature I'd like to see in either or both of these is the ability to easily create PDF's from scanned documents. With full acrobat, you can scan a document directly into a PDF. In fact, if you have multiple pages to scan it will keep prompting you for the next page until you indicate you are done. I use that feature to archive my important records. It's really about the only time I NEED windows. If this feature is added I will be a happy camper.

you can't use kooka, and print the resulting file to a pdf??? Works fine here. Every KDE app can print to PDF, and why would a viewer support scanning? Or burning to cd, or sending email etcetera? Basic page-oriented editing, ok, copy-paste from it, printing, saving, editing meta-data, annotating - fine. But scanning?!?

Of course I can do that. But that takes a step or two more than the process I'm talking about. Plus, I haven't been able to easily combine multiple pages into a single PDF file. Maybe Kooka is the right place to put this functionality.

Yeah, I've been thinking about writing a small program to do that sort of thing (working title Kopier), just a basic app that simply joins up input from scan or file to output to print, file or fax. Think of it as a software MFC. The underlying KDE framework is there, it's just finding a nice way to join it all together.

I encourage you to first try out the latest stable version of Dolphin to really see its potential. I'm a die-hard Konqueror fan, But I do think that there are things that Dolphin gets right. That's not mentioning a cleaner code beneath.

The location bar in Dolphin is not removed. The devs would be crazy to do that. The button (or shorcut keys) to show it is clearly there. But the breadcrumb widget itself is more than a match for what Nautilus currently has.

Dolphin is apparently meant to be a light, simple, and fast file manager. It can never really replace Konqueror in functionality. So Konqi won't be going away anytime soon. I do hope, though, that a lot of this work will be somehow applied to Konqueror, too.

Dolphin and konq share things like icon views, and so forth. So improvements to Dolphin are also improving konq. Which is a good thing, because Dolphin, while a very smooth file manager, just does not have the power user functionality that I've come to rely on from konq. Things like splitting panes and then doing drag and drop from an ftp site to my server via fish, and so forth.

So, Dolphin will improve konq. and provide an easier to use file manager for more basic user needs. Analogous to how kwrite is a simplified kate, with reused components... (I know it's not a 1:1 analogy, but it's simple enough)

This is doubly bad for Konq because the exposure that most users get to Konqueror Web Browser is through the filemanager because *most* distributions change the default web browser to firefox. So the only time you see Konqueror is when you click on it for file management, oh and then you find out it's world-class web browser and keep using it for everything.

I'll only use Dolphin if it has a tree view (of only directories) in a separate panel, and if there is an address field where I can type in where I want to go (and is on by default, or can be made so). Dolphin from the screenshots I have seen does not have these, and so is of no interest to me.

Dolphin may not currently have a tree view like the one in Konqueror's navigation panel. But it has something that's equally functional, and might even actually be better.

When you click and hold on a folder name button in the breadcrumb widget, you get a dropdown list of the subdirectories in that folder. A picture speaks a thousand words, so this screenshot might explain it better.

Wow. That is a pretty pretty file manager. When I first heard about dolphin my first thought was why would anybody want to replace konqueror. I understand now, although I think I'd still rather see a lot of those changes ported to konqueror instead of having them in a separate application.

I gave dolphin a try and didn't like it at all. Can it do ftp'ing? I didn't get it to work...also, looots of space on the left (in the sidebar) is empty and wasted for nothing...not excited at all, sorry guys.

The only thing I know about Dolphin are screenshots making it look roughly like Gimp's load/save boxes (I said roughly...), with the path as buttons and things like that.
I just wanted to say that personnaly, I absolutely hate this stuff and that since Gimp has put it in, it takes thrice as much time to just load or save a file than before. Being unable to cut/paste a path using the good X11 middle button is something I'm really furious against.
For the same reason, the full tree on the right side is incredibly more efficient than hovering over a directory name to see the other subdirectories : I can visualize the full tree by just rolling the wheel of my mouse and quickly find directories I've been searching for. Partial views make it a lot more complicated to do so.
And as a matter of fact, Konqueror being a file manager and a browser is absolutely perfect for me and a great idea, in particular ssh, telnet and ftp accesses. I miss it so much on other systems where I need to fire several apps to do the same.
There are things that need to be changed, I suppose, for KDE 4, but the Konqueror concept is not one IMHO.

It seems that Ligature will be part of the default KDE-tarballs (kdegraphics). Distributions have of course a possibility to override this.

Anyway, personally I'm happy that only one "universal viewer" is part of the default KDE-tarballs. I personally also don't care which one it is. I just think that desktop/menu clutter isn't helpful for users.

> It seems that Ligature will be part of the default KDE-tarballs
> (kdegraphics). Distributions have of course a possibility to override this.

There's no ligature in kdegraphics packages of _stable_ releases.
The only ligature in official KDE modules is the KDE 4 version that can be found in kdegraphics; it has been lonely to much time, and now the time to restore the status quo of KPDF/okular in KDE 4 again has come.

I've always been a passionate user of kpdf which is now re-branded okular, but i believe it deserves a more intuitive user interface and iconification. I am particularly pleased with the transformation and i believe okular can only get better.

1) KDE applications already start up pretty fast. I barely ever have to wait for anything. And if so, it's the bad occurrence of having to use Firefox or OpenOffice. Notable not KDE applications.

2) What are you talking about? I am having an uptime of 2 weeks now on my desktop, and the last time something crashed, was Kontact (when the IMAP server was not running, and I clicked cancel to the password dialog) at startup.

3) I don't need KOffice to do that, OpenOffice does that trick already. For my own documents, I write them in ODF now, or KOffice native formats. I would rather have KOffice people concentrate on fine ODF support. Once our main customer goes ODF, I would love to NOT have to use OpenOffice still.

4) You, see it's funny. Maybe because I use Kubuntu, but everything works fine in Linux, which doesn't under Windows. For example, my optical wireless mouse, when the batteries get low, I have to exchange them, because under Windows (gaming) it stops working. Can't configure anything. The batteries continue to work for many weeks. Then my onboard sound driver, the last driver was released 2003, 4 years ago. It must have been perfect. Ok, except that I can play Oblivion and Eve only without sound. With sound the system crashes to power off reproducible and within like 30 minutes of play. Can't blame a 2003 driver for not working with 2006 games though. But an update is not expected. The WLAN PCI card (RaLink, GPL driver) that I bought, works perfect with Linux. I am having many hours of interrupt free connection (and fast) to my router. Under Windows, this is not so. Sometimes I have to reboot, because connection never lives longer than a few seconds, it's maddening, sometimes problems start after 1 or 2 hours, then go away again.

No really. It's quite good, hardware integration and correctness under Linux has not been an issue for years to me.

5) Why do you need applications included in the base at all? Is that somehow magically going to make them better? I am content as long as they end up packaged by Debian and thereby Ubuntu.

6) I am not using the KMenu. Never not at all. I have quickstart buttons a few, and then I use ALT-F2 mini-cli to launch things. One or two keys, and it completes to what I want. When I want to find applications, I use google. Once I have their names, I search in Kubuntu the package and install it. Then I don't bother to hunt it in menus, I know it's called "krita" anyway.

7) Reads like what Plasma is going to give. Maybe an unfriendly side note and I have no right to say so, but Plasma was a more popular theme on certain persons blogs for a lot time, until Trolltech recruited. I would like a statement, if Plasma still has the priority, it had.

8) I don't need smooth scrolling. Scrolling text is hard to read. I need fast scrolling. And that I have in KHTML and Kate parts. Sometimes I am even annoyed by too much smoothness in KPDF, where I rather want to see things now. Thing is, while it's moving, I can't read it.

So you, go away, don't say "us". I need completely different things than you do.

7) You referring to Aaron? If so I think it's a little unfair, isn't he sponsored by Trolltech rather than employed and they don't therefore tell him what to do. I suspect he stopped blogging on plasma because the hype is too much already and he's maybe fed up with everyone asking about it and speculating.

Granted, it is entirely unfair. And yes, who else? Who owned the plasma hype since its inception?

Being fed up from the hype after having produced the hype _entirely_ yourself, would be unfair too. I welcome the fact that he became sponsored, it meant a whole lot of gain for KDE and us, don't get this wrong. He certainly is one of the more talented KDE developers, and a voice.

I still remember how innovative plasma should be. But maybe it is too boring now, before it's done even. I have "talk is cheap" on my mind here. Applies to me and him.

Guess, I shouldn't react that way, just because everybody else has their pet techs shaping up already, doesn't mean Plasma needs to be ready.... ah well, we want news about it. now already ;-)

"8) I don't need smooth scrolling. Scrolling text is hard to read. I need fast scrolling. And that I have in KHTML and Kate parts. Sometimes I am even annoyed by too much smoothness in KPDF, where I rather want to see things now. Thing is, while it's moving, I can't read it."

I have a dell laptop with a crappy ATI onboard video (no acceleration with fglrx or xorg driver), and I have SuSE on the laptop which includes a smooth scroll patch for at least Konqueror. On some larger pages (like a long Slashdot article), trying to scroll down can take MINUTES (because it can't redraw/rerender fast enough) instead of instant without smooth scrolling (1 redraw versus say 50, which would think would be easier?). Unfortunately I have no clue how to disable the smooth scrolling short of switching distros. Also 'scrolling text is hard to read' is DEAD on, I've never seen any application use smooth scrolling that didn't make it hard/painful/impossible to somewhat read the text while scrolling. Basically, you're spot on especially on this one (mostly commenting cause while scrolling a long page it uses so much CPU time that Amarok will stop playing until it finishes).

1) KDE apps? The only ones I find a little slow are things like Firefox and OOo (because they have to load more libraries not being kde integrated? I don't know). Not much kde can do about them, except continue to improve the kde alternatives. Likely some improvements with qt4 anyway?
2) Really? Which ones? Only thing I've managed to crash recently is a beta of k9copy, which isn't core kde and is a beta (need to look into a bug report sometime)
3) Koffice is getting reworked. Already 1.6.x is a big improvement over 1.5.x Not so sure about .doc support etc, with MS switching to OOXML and everyone else to ODF I think it's unlikely to be pursued (sure, it would be nice to support every format)
4) I agree, although some of this is more the distro's jobs. Adept is rapidly improving in debian land. Knetworkmanager is quite usable. A graphical xorg thing would be nice, did I see one on kde apps?
5) Kaffeine - I agree, or KMplayer. Is Ktorrent not in the base, I lose track? Gwenview is moving into kdegraphics, I think? K3b, again nice. Some distros install these by default anyway. There's nothing else in your list that I need, except kio_iso sometimes. So no _we_ don't need all that
6) Reworked kmenu is coming, actually I don't mind the current one anyway
7) Plasma?