Okular fails to open archives full of image files as comic book files when explicitly told to do so; however, renaming the files to end in either .cbr or .cbz will make Okular open them without an issue. Ideally, Okular will ignore any non-image files in the archives, such as erroneously included "Thumbs.db" files. Reproducible: Always Steps to Reproduce: 1. mkdir okulartest && cd okulartest && for i in {0..9}; do convert -size 2480x3508 xc:white -gravity Center -weight 700 -pointsize 600 -annotate 0 "$i" $i.png; done; cd .. && zip -r okulartest.zip okulartest/ 2. okular okulartest.zip 3. mv okulartest.zip okulartest.cbr 4. okular okulartest.cbr Actual Results: Step 2: Okular says it could not open okulartest.zip, and shows the error message "Can not find a plugin which is able to handle the document being passed." The console output reads: okular(5259)/okular (app) Okular::Document::openDocument: No plugin for mimetype '"application/zip"'. Expected Results: Okular tries to treat the zip file like a cbr file before complaining to the user.
Should we really do this? How can we be sure it is not EPUB or comressed FB2? I looked at code. For now, Okular uses KMimeType to decide which file we pass to it. To make sure it is a comicbook we would need to parse contents of the archive and somehow decide that it can't be anything other.
The simplest solution would check if there are only image files and optionally subfolders with image files in the archive while ignoring Thumbs.db and .DS_STORE. This would not read ACBF cbr files ending in .rar or .zip as they contain a "acbf" file with XML metadata, but that could either be added to the list of files that are being ignored in determining whether it's a comic book, or even better, can be used to explicitly determine that it must be a comic book. As to whether we should do this, I can only say that I do not see any downsides to being able to read the file as long as the application doesn't by accident read something that it cannot handle properly. However, if it's a case of image files + optionally some system files of other OSes, then Okular can display it just fine and it may as well be a CBR apart from the file extension. This isn't even a case of "quacks like a duck, swims like a duck, might as well be a duck", more one of "it is a duck that doesn't know it's a duck and sits in a cage labelled 'bird'".
I don't think this should be that hard, sure, it needs some twekaing to make sure it's not messing up the detection and opening things wrong, but it should be doable
Huh. Actually, it already works. All what needs to be done is to include application/zip to .desktop files.
I've made a review request with changed .desktop files. rar archives opens too. Code to handle x-rar/zip mimetypes in comicbook lives in ComicBook::Document::open().
As somebody in the review request ( https://git.reviewboard.kde.org/r/125020/ ) stated, this may not be a good idea. Currently, Okular gets the mimetypes it can open from the .desktop files if I understand the code correctly; however, adding zip- and rar-files to those desktop files would mean that Okular would appear as a choice for opening these files. The core issue, which is that Okular assumes it cannot open a file if it is not in the .desktop, could also be fixed differently: If no mimetype match is made, try to see if the filetype is recognised by any magic numbers, completely ignoring the file extension; this, for example, could be done with libmagic, which is also what the "file" utility uses. Since Okular currently recognises the magic number of things passed to it via stdin, it already has this functionality built into it somewhere, but not used in the way I propose. This would have the benefit that .cbr and .cbz files could also be opened by Okular if they're read from stdin, since Okular only sees the data that way and currently concludes that it is a zip- or rar-file and therefore cannot be opened.
Soumya, why did you change the assignee?
At some point, modifying desktop files stopped working. Instead to get okular to open .zip as cbz I ended up replacing the one occurence of "cbz" by "zip" in the compiled okularGenerator_comicbook.so, which worked so I guess the source of truth moved somehow. However this stopped working with version 20 where this wild hack instead gave me segfaults (specifically the debian package at version 4:19.12.3-2 and some previous versions tolerated the hack, 4:20.04.0-1 segfaults with the hack). Even if it's not considered an acceptable default could the controls be moved back to a human editable file?