Backends package is: 4:16.12.0-0neon+16.04+build1

Can't reproduce it on a self-compiled okular master (which has no changes which touch the cbz support). Moving to neon.

I have the same trouble with Okular, Since framework 5.29.0 and Okular 1.0.1, I can not open CBZ file with Zip file above v1.0. Okular not say me any error, only "Can't open file:[PATH]".

I confirm this is a problem.  No idea why.

<Riddell> leinir: looking in Dolphin it says my .cbz file is a zip archive, so I wonder if okular is getting the wrong mimetype indeed
<leinir> file says that here as well...
<leinir> so... that would make sense

<leinir> (i'm on opensuse tumbleweed)

FWIW, on my openSUSE 13.2 system with Frameworks 5.30, dolphin 16.12.1 does show .cbz files as "Comic Book Archive", but okular 16.12.1 (1.0.1) still fails to open them.
(okular 16.08.3, i.e. the KDE4 version, works fine though)

Both kmimetypefinder and kmimetypefinder5 recognize them as "application/x-cbz".
And according to okular's konsole output, it seems it does try to use the comicbook backend.

So this does not (only) seem to be related to the mimetype recognition...

I test with http://embra.edinburghlinux.co.uk/~jr/tmp/comic.cbz

(In reply to Jonathan Riddell from comment #8)
> I test with http://embra.edinburghlinux.co.uk/~jr/tmp/comic.cbz

Yes, with that I get the behavior described in comment#7.
I.e. it is recognized as application/x-cbz here, okular 1.0.1 tries to open it with the comicbook backend but fails.

If I rename it to comic.zip (so that it is actually recognized as application/zip), I additionally get an error message that okular cannot find a suitable plugin and debug output in the terminal:
No plugin for mimetype '"application/zip"'

sending back to okular as it has been confirmed in multiple distro setups

Actually I think this is a problem with karchive.

Okular opens the archive fine and sees all individual images. But opening them with QImageReader fails.
OTOH, opening them with QImage::loadFromData(dev.data()->readAll()) works, i.e. this patch "fixes" the problem:
diff --git a/generators/comicbook/document.cpp b/generators/comicbook/document
.cpp
index 34c4cb5..6798606 100644
--- a/generators/comicbook/document.cpp
+++ b/generators/comicbook/document.cpp
@@ -184,11 +184,12 @@ void Document::pages( QVector<Okular::Page*> * pagesVector )
 
         if ( ! dev.isNull() ) {
             reader.setDevice( dev.data() );
-            if ( reader.canRead() )
+            if ( 1 )
             {
-                QSize pageSize = reader.size();
+                QSize pageSize;
                 if ( !pageSize.isValid() ) {
-                    const QImage i = reader.read();
+                    QImage i;
+                    i.loadFromData(dev.data()->readAll());
                     if ( !i.isNull() )
                         pageSize = i.size();
                 }


I suspect it's related to KCompressionDevice::seek(). readAll() does not use seek() of course, but QImageReader does.

Wolfgang which Qt and KArchive are you using?

This is still work fine for me

(In reply to Albert Astals Cid from comment #12)
> Wolfgang which Qt and KArchive are you using?

Qt 5.7.1 and karchive 5.30.
Also tried with Qt 5.8.0, the same problem.

I also tried other distributions last week using LiveCDs:
- openSUSE Tumbleweed (20170123) with Qt 5.7.1 and karchive 5.29
- KDE Neon user edition (20170119-0019)
- KDE Neon developer edition (20170125-0806)

This was reproducible everywhere.

It's a bug in KArchive or a bug in Qt.
https://mail.kde.org/pipermail/kde-frameworks-devel/2017-February/042506.html

Was a KArchive bug https://cgit.kde.org/karchive.git/commit/?id=14653ce06ab31eaaa7a9eef75a257e17a048f9ba

(In reply to Albert Astals Cid from comment #15)
> Was a KArchive bug
> https://cgit.kde.org/karchive.git/commit/
> ?id=14653ce06ab31eaaa7a9eef75a257e17a048f9ba

I can confirm that opening .cbz files in Okular works here now with this commit.
.cbt (tar) and .cbr (rar) still work too.