[Okular-devel] Wishlist: Ideas for Okular development - by a wannabe developer

[Pino Toscano]

Hi,

> I wasn't sure if this mail belonged in the Okular Development mailing list.
> So I had sent a personal mail to Pino first, which I didn't get any reply
> to.

Sorry for not having replied earlier, but given that your email was quite long 
and not the only one to reply in (limited) time, I started writing bits for 
its reply offline.

> 1. Additional functionality for annotations in PDF files : Default values
> of opacity, width, font size, etc should be adjustable.

Ok.

> Another thing I
> find very annoying is that Highlighting is not possible neatly in a
> 2-column file. Is it not possible to figure out that a file is in 2-column
> format (some hack like looking for a vertical line of blank space, maybe?)
> and adapt the Highlighting feature accordingly?

If it would have been easy it was there already ;) This is reported already as 
bug #161324.
Basically, the work is figuring out how to layout the text entities we have 
(each text character+its position in the page), recognizing also things like 
"²" (which have a bounding box slightly up wrt the other ones in the same 
"text line"), etc.

> 2. This should be simple: just a "Back" button in the navigation toolbar
> (at the bottom of the window) so that it's easy to go back after you've
> clicked on a link (a hyper-reference in a pdf file).

This was bug #192143 already.

> 3. Library management : Would it be possible to have a management of files
> on the personal computer from within Okular?

As written in the bug report, we decided time ago to not going this route.
The reasons are various: adding those functionalities inside Okular is simply 
overloading a viewer with stuff which don't belong to it. Also, given that 
Okular provides a KDE KPart (okularpart), it is fairly easy (~5 LOC) to load 
and embed it in any KDE application.
That said, we encourage any external application doing that, and using the 
okularpart for allowing the user to view documents.

> Another useful feature would be a snapshot of links in files, in particular,
> links within the file. For example, if you could see a snapshot of an
> equation, a publication reference (just the citation at the end of the
> paper, say) or a figure when a reference to the item occurs in the file.

Loading external links is not cheap, so this might not feel "smooth". There's 
also the privacy concern, ie somebody could know you are reading a document 
because you are hovering a link and downloading another document/file from the 
Internet.
For links to local pages, there's bug #128434 (originally for KPDF, which I 
just moved, as KPDF will not have it anyway).

> I am an undergrad EE student with some programming experience, but no
> software development (nothing >1500 lines of code!). I would be interested
> in joining the development team to help with these aspects, if possible. Is
> there a large barrier to entry, in terms of size of code or lack of
> experience?

Theorically there's no "large barrier"; although being "big" (even if not that 
much, actually), Okular' source code is more or less "divided" into various 
parts, for example the core library, the ui parts for 
viewing/annotating/forms/etc. Of course some components show their complexity 
(like the Document, the PageView - which is more than 4k LOC -), but I'd say 
that generally the trick should be understanding first the system behind page 
generation and visualization. Once understood that, allthe other pieces can be 
(more or less) easily related to it.

-- 
Pino Toscano
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/okular-devel/attachments/20090708/739d5114/attachment-0001.sig