Bug 304562 - Viewing djvu files inside rekonq [with solution]
Summary: Viewing djvu files inside rekonq [with solution]
Status: RESOLVED FIXED
Alias: None
Product: rekonq
Classification: Unclassified
Component: web app (show other bugs)
Version: 0.9.1
Platform: unspecified Linux
: NOR wishlist (vote)
Target Milestone: ---
Assignee: Andrea Diamantini
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-08-04 15:58 UTC by Leon Bottou
Modified: 2012-08-14 15:18 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments
rekonq showing the link with okular part (100.04 KB, image/png)
2012-08-12 17:43 UTC, Andrea Diamantini
Details
okularpart inside rekonq (38.99 KB, image/png)
2012-08-12 17:56 UTC, Leon Bottou
Details
okularpart on an indirect djvu document (64.07 KB, image/png)
2012-08-12 18:25 UTC, Leon Bottou
Details
let rekonq use djvu plugin.. (421 bytes, patch)
2012-08-13 22:36 UTC, Andrea Diamantini
Details
yet easy, but clean patch to merge (2.14 KB, patch)
2012-08-14 09:07 UTC, Andrea Diamantini
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Leon Bottou 2012-08-04 15:58:04 UTC
I am the maintainer of djvulibre on a mission to make the djview plugin work inside rekonq. 
Working under kubuntu precise (rekonq 0.9.1)

1) HOW TO MAKE IT WORK

Best is to use the latest git version 
$ git clone git://djvu.git.sourceforge.net/gitroot/djvu/djview.git
Convenient packages at http://leon.bottou.org/morefiles/ if you want to save time.
Then go to the kde control panel, file associations, search mime type vnd.djvu,select the embedding tab, and delete all files associations there, including the okular part and the ns plugin viewer. Then "rekonq http://leon.bottou.org/publications/djvu/jmlr-2011.djvu" work like a charm. Even scripting works quite well.  The only thing that does not work is calling back javascript from the plugin using NPN_Evaluate.  

2) WHAT IS THE PROBLEM

There are in fact three ways for rekonq to show djvu files.
1- Using the okular part.  This is broken on kubuntu 12.04.  Also you do not get the menus.
2- Using the nsplugin part that comes with konqueror.  This is broken too.
3- Directly using the djview plugin.  This is the one I can fix. It works.

The problem is that rekonq only uses the djview plugin if it finds nothing in the kde file associations for embedding data of mime type vnd.djvu. Otherwise it tries to use the kde parts that fail for reasons well beyond my competences.

The worst part is that the user has no way to indicate that he would prefer using the direct plugin support from webkit, because this code path is not represented in the file association dialog. If the konqueror nspluginviewer is installed, the file association shows an entry "Netscape plugin" but this entry is for the nsplugin part which should load the plugin but does it in a way that does not work in rekonq (although it works in konqueror).

As long as the kpart support is incomplete (menubar merging?), it makes sense to prefer the netscape plugins over the kparts. Maybe with a preference option to control this priority.

Thanks.

- Leon Bottou


Reproducible: Always
Comment 1 Andrea Diamantini 2012-08-12 17:41:19 UTC
Hi Leon, and many thanks for your interest about.
Anyway, I'm not sure what is the main problem here. While reading I just tried loading in a new tab the link you gave me without any other change to configuration or package compiling/installation. Result: it just works in my local rekonq! Screenshot following.
Can you please suggest a link where you don't see it working?
Comment 2 Andrea Diamantini 2012-08-12 17:43:08 UTC
Created attachment 73121 [details]
rekonq showing the link with okular part
Comment 3 Leon Bottou 2012-08-12 17:56:30 UTC
Created attachment 73123 [details]
okularpart inside rekonq

Kubuntu 12.04.  Okularpart inside rekonq appears black  This changes when one resizes the window
Comment 4 Leon Bottou 2012-08-12 18:25:45 UTC
Created attachment 73126 [details]
okularpart on an indirect djvu document

Okular cannot show a so-called indirect djvu document, because multiple http requests are necessary to fetch the document pages on demand.
Comment 5 Leon Bottou 2012-08-12 18:27:27 UTC
Hello Andrea,

Attachment 73123 [details] illustrates how okularpart appears inside rekonq when viewing a djvu file under kubuntu 12.04. It is not very eventful, as you can see. Note that the okular part is displayed correctly as soon as you resize the rekonq window. But where are the menus?  How do I select text in the djvu document?  Even when it works, the functionality is incomplete.

Also, viewing djvu files inside a browser is expected to obey various pseudo-cgi options to control what is shown. For instance, clicking on  <http://leon.bottou.org/publications/djvu/jmlr-2011.djvu?djvuopts&page=4&zoom=133> is expected to show page 4 with a 133% zoom factor. There are quite a lot of these options (see http://djvu.sourceforge.net/doc/man/djview4.html). The most important is certainly the "page=xxxx" option. Many sites do not work right without this.

Also there are djvu documents that do not come as a single file but as a collection of files that are loaded on demand by the djvu viewer. This allows random access in large documents.Attachment 73123 [details] shows how okularpart looks like when you click on <http://leon.bottou.org/cgi/djvuserve/publications/djvu/jmlr-2011.djvu/index.djvu>, after suitably resizing the window to get out of the "black" state.

Please do not misread me. Okular is fine as a standalone app to view djvu files stored on your hard disk.  But it does not implement all the things that DjVu does to help viewing documents online (the above, plus progressive rendering, caching and prefetching.) 

But even there, I would say that okular is a reasonable default when the djview plugin is not installed. But what is an unsuspecting user to do when encountering one of these sites?  We cannot even tell the user to install the djvu plugin because the part takes precedence over the plugins.  You'd think it is enough to raise the position of the "Netscape Plugin" line in the file association tab.  But no, this increases the priority of the nsviewpluginpart that comes with konqueror and does not work well in rekonq either (it works inside konqueror.)

It took me a couple hours to realize that the plugin support of rekonq is working very well, and that the only problem was to make sure it would not attempt to load a part when I want the plugin. I wanted to draw the attention of the rekonq people about this simple fact.

Thanks.

 - L.
Comment 6 Andrea Diamantini 2012-08-13 22:35:26 UTC
Hi leon,
what do you think about the attached (super easy) patch?
Comment 7 Andrea Diamantini 2012-08-13 22:36:01 UTC
Created attachment 73148 [details]
let rekonq use djvu plugin..
Comment 8 Leon Bottou 2012-08-14 01:22:22 UTC
If this does what i think it does, this would certainly does the trick when the (correct) djvu plugin is installed. The downside is that we get no djvu support without the djview plugin. At least this is simple to explain. But I cannot help but feel that this is not the "right" way because we take options away from the user.

* Note that there is a similar function in kdewebkit already (see excludeMimeType in http://gitorious.org/dbusmenu/kdelibs/blobs/master/kdewebkit/kwebpluginfactory.cpp). 

* What about a checkbox in the config dialog that gives preference to plugins over parts in general?  I guess the problem is that you do not know which mimetypes are supported by a netscape plugin. This seems hidden in the depths of webkit :-(.  They do not even let you configure the plugin search path!

* The presence of the konqueror-nsplugins package makes things confusing because the file association kde settings now show a "netscape plugin part" option to embed a file. Maybe the webpluginfactory could return zero when the kmimetypetrader finds this part. 

Well, just ideas, and not very satisfactory either...

Thanks.

- L.
Comment 9 Andrea Diamantini 2012-08-14 08:44:26 UTC
Yes, excludeMimeType is exactly what I did in this simple patch.
As you stated, the problem is that we don't know npapi plugins installed by code in qtwebkit. So, we have to decide before. Fortunately, rekonq has a structure, called "ProtocolHandler", that manage the link/urls webkit cannot manage. So, applied the patch you can add/remove djvu plugin and see that rekonq uses plugin/part (plugin via webpluginfactory if it is available, part via protocolhandler, if the link has not been rendered via webkit (or its plugins)
Comment 10 Andrea Diamantini 2012-08-14 09:06:33 UTC
here is the patch I'm going to merge with your ok. Regards,
Comment 11 Andrea Diamantini 2012-08-14 09:07:04 UTC
Created attachment 73156 [details]
yet easy, but clean patch to merge
Comment 12 Leon Bottou 2012-08-14 13:36:58 UTC
OK.

The protocol handler is for fullpage parts, not embeds, correct?
But I guess this is okay because the okular part works poorly for embeds anyway.

Thanks a thousand times.

- L.
Comment 13 Andrea Diamantini 2012-08-14 15:18:33 UTC
Git commit 3b7a1ffae0ae9e5fd0c1dd238434e0bf312fa6ad by Andrea Diamantini.
Committed on 14/08/2012 at 10:57.
Pushed by adjam into branch 'master'.

Get sure rekonq makes use of djvu plugin

Also, clean up mimetype detection, following kdewebkit.

I tried implementing this using the protected excludeMimeType in
kwebpluginfactory, but I fear it has to be declared virtual to let
the trick work. Isn't it?
CCMAIL: adawit@kde.org

M  +13   -1    src/webpluginfactory.cpp
M  +1    -1    src/webpluginfactory.h

http://commits.kde.org/rekonq/3b7a1ffae0ae9e5fd0c1dd238434e0bf312fa6ad