Is your Evince compiled with "--enable-djvu" / are "evince-djvu" or "evince-libs" or whatever you distribution calls it installed?

Yes, "--enable-djvu" is present in %build macros:

[1] https://build.opensuse.org/package/show/openSUSE:Leap:42.2/evince

[2] https://build.opensuse.org/package/view_file/openSUSE:Leap:42.2/evince/evince.spec?expand=1

==========================
%build
# on openSUSE, we share the browser plugins between browsers; do not use mozilla's default.
export BROWSER_PLUGIN_DIR=%{_libdir}/browser-plugins
%configure --disable-static --with-pic\
        --libexecdir=%{_libexecdir}/%{name} \
        --enable-djvu\
        --enable-dvi\
        --enable-comics\
        --enable-nautilus\
        --enable-introspection \
        --enable-multimedia
==========================

Created attachment 360140 [details]
Screenshot file

This is the exact error I am facing while trying to open djvu files from evince.

I don't use OpenSUSE, but they appear to split the evince backends into separate packages. Do you have evince-plugin-djvudocument installed?

I see that "image/vnd.djvu" has been removed from the mime types and this was intentional. See bug #754467 for a discussion on having evince only open multi-page djvu documents and not single-page documents.

(In reply to Jason Crain from comment #5)
> I see that "image/vnd.djvu" has been removed from the mime types and this
> was intentional. See bug #754467 for a discussion on having evince only open
> multi-page djvu documents and not single-page documents.

I have the same problem here, however, I have multi-page documents that cannt be opened because they are recognized as DjVu image (image/vnd.djvu), so is that the expected behavior or is it a backward compatibility problem?

I honestly dont know the internal functioning of the DjVu format and therefore I dont know if it is a problem in the creation or conversion of this type of documents on my part, however, I started to download some files from the web and I cannt open them either despite being multi-page documents. 

For me it is a problem since I have a large number of documents in this format (evince is my favorite viewer).

Tested in fedora 27 beta (gnome).

Created attachment 362473 [details]
test screenshot

Here I show a screenshot with a document downloaded from the following link: http://djvu.org/docs/DjVu3Spec.djvu (from: http://djvu.org/resources/) and visualized with DJView to show that it is a multipage document.

(In reply to Bastián Díaz from comment #7)
> Here I show a screenshot with a document downloaded from the following link:
> http://djvu.org/docs/DjVu3Spec.djvu (from: http://djvu.org/resources/) and
> visualized with DJView to show that it is a multipage document.

That file is working for me on Debian sid and gets recognized as image/vnd.djvu+multipage.

(In reply to Jason Crain from comment #8)
> That file is working for me on Debian sid and gets recognized as
> image/vnd.djvu+multipage.

So, could this be a specific distro issue? thank you

$ gio info ~/Downloads/DjVu3Spec.djvu | grep content-type
  standard::content-type: image/vnd.djvu+multipage
  standard::fast-content-type: image/vnd.djvu

(In reply to Bastián Díaz from comment #9)
> (In reply to Jason Crain from comment #8)
> > That file is working for me on Debian sid and gets recognized as
> > image/vnd.djvu+multipage.
> 
> So, could this be a specific distro issue? thank you

More likely Tracker not updating the mime-type in the database.
What's the output of "tracker info" for that file?

(In reply to Mikhail Kasimov from comment #0)
> 've an GjVu file, which is opened with Okular viewer successfully, but
> Evince can't do the same: "Can't open file /path/to/file. File type DjVu
> (image/vnd.djvu) is not supported".

Evince won't open single page images. Though that can always be restored if there's enough evidence that single page DjVu files are always documents.

(In reply to Bastien Nocera from comment #10)
> $ gio info ~/Downloads/DjVu3Spec.djvu | grep content-type
>   standard::content-type: image/vnd.djvu+multipage
>   standard::fast-content-type: image/vnd.djvu
> 
> (In reply to Bastián Díaz from comment #9)
> > (In reply to Jason Crain from comment #8)
> > > That file is working for me on Debian sid and gets recognized as
> > > image/vnd.djvu+multipage.
> > 
> > So, could this be a specific distro issue? thank you
> 
> More likely Tracker not updating the mime-type in the database.
> What's the output of "tracker info" for that file?
> 

This...
--
Consultando la información para la entidad:'/home/diazbastian/DjVu3Spec.djvu'
  'urn:uuid:038787e3-1d85-d8ba-0db1-c82920eaa108'
Resultados:
  'http://purl.org/dc/elements/1.1/date' = '2017-10-29T05:32:24Z'
  'http://purl.org/dc/elements/1.1/date' = '2017-10-29T15:03:22Z'
  'http://purl.org/dc/elements/1.1/source' = 'http://www.tracker-project.org/ontologies/tracker#extractor-data-source'
  'tracker:added' = '2017-10-29T05:42:49Z'
  'tracker:modified' = '2717'
  'rdf:type' = 'http://www.w3.org/2000/01/rdf-schema#Resource'
  'rdf:type' = 'http://www.semanticdesktop.org/ontologies/2007/01/19/nie#DataObject'
  'rdf:type' = 'http://www.semanticdesktop.org/ontologies/2007/01/19/nie#InformationElement'
  'rdf:type' = 'http://www.semanticdesktop.org/ontologies/2007/03/22/nfo#FileDataObject'
  'rdf:type' = 'http://www.semanticdesktop.org/ontologies/2007/03/22/nfo#Media'
  'rdf:type' = 'http://www.semanticdesktop.org/ontologies/2007/03/22/nfo#Visual'
  'rdf:type' = 'http://www.semanticdesktop.org/ontologies/2007/03/22/nfo#Image'
  'rdf:type' = 'http://www.tracker-project.org/temp/nmm#Photo'
  'nie:byteSize' = '472637'
  'nie:dataSource' = 'http://www.tracker-project.org/ontologies/tracker#extractor-data-source'
  'nie:isPartOf' = 'urn:uuid:14650865-2d83-0ede-e5af-c9866b270c86'
  'nie:url' = 'file:///home/diazbastian/DjVu3Spec.djvu'
  'nfo:belongsToContainer' = 'urn:uuid:14650865-2d83-0ede-e5af-c9866b270c86'
  'tracker:available' = 'true'
  'maemo:relevance' = '1000000.0'
  'nie:isStoredAs' = 'urn:uuid:038787e3-1d85-d8ba-0db1-c82920eaa108'
  'nie:mimeType' = 'image/vnd.djvu'
  'nfo:fileLastAccessed' = '2017-10-29T15:03:22Z'
  'nfo:fileLastModified' = '2017-10-29T05:32:24Z'
  'nfo:fileName' = 'DjVu3Spec.djvu'
  'nfo:fileSize' = '472637'

(In reply to Bastián Díaz from comment #11)
>   'nie:mimeType' = 'image/vnd.djvu'

There you go.

(In reply to Bastien Nocera from comment #12)
> (In reply to Bastián Díaz from comment #11)
> >   'nie:mimeType' = 'image/vnd.djvu'
> 
> There you go.

I'm sorry, but I do not understand it.
I updated the mime types database and also restarted the tracker index without results. Currently as a solution I am using Atril to visualize those documents.

https://cloud.woelkli.com/s/68k0EQ8B2AHT8jy

(In reply to Bastián Díaz from comment #13)
> (In reply to Bastien Nocera from comment #12)
> > (In reply to Bastián Díaz from comment #11)
> > >   'nie:mimeType' = 'image/vnd.djvu'
> > 
> > There you go.
> 
> I'm sorry, but I do not understand it.
> I updated the mime types database and also restarted the tracker index
> without results. Currently as a solution I am using Atril to visualize those
> documents.

This shows a problem with Tracker, not an intrinsic problem with evince or gnome-documents. However, it doesn't seem to be the problem you're reporting, sorry, I must have got my wires crossed with gnome-documents bug reports.

I can open that file just fine here with shared-mime-info-1.9-1.fc27.x86_64 and evince-3.26.0-1.fc27.x86_64. The file is detected as a multi-page DjVu document in nautilus' properties, so this would point to another package mucking up the detection.

Does Atril install new mime types definitions? Can you check the output of:
grep -r djvu /usr/share/mime/packages | grep -v freedesktop.org.xml
on your system?

Alternatively, you might want to also look in ~/.config and ~/.local for user-created "djvu" definitions, which might also be causing problems.

(In reply to Bastien Nocera from comment #14)
> (In reply to Bastián Díaz from comment #13)
> > (In reply to Bastien Nocera from comment #12)
> > 
> > I'm sorry, but I do not understand it.
> > I updated the mime types database and also restarted the tracker index
> > without results. Currently as a solution I am using Atril to visualize those
> > documents.
> 
> This shows a problem with Tracker, not an intrinsic problem with evince or
> gnome-documents. However, it doesn't seem to be the problem you're
> reporting, sorry, I must have got my wires crossed with gnome-documents bug
> reports.
> 
> I can open that file just fine here with shared-mime-info-1.9-1.fc27.x86_64
> and evince-3.26.0-1.fc27.x86_64. The file is detected as a multi-page DjVu
> document in nautilus' properties, so this would point to another package
> mucking up the detection.
> 

That's right, the package that generated the conflict was djvulibre.x86_64

> Alternatively, you might want to also look in ~/.config and ~/.local for
> user-created "djvu" definitions, which might also be causing problems.

The solution is not as simple as uninstalling the package, since I had to delete the xml files related to djvu in /usr/share/mime (after trial and error uninstalling applications that handled djvu files in my system) and update share mime info database.

I suppose that other users could have this problem, unless they perform a clean installation (I am updating my system from fedora 24).

Cheers

This is a bug in the djvulibre package, maybe even upstream. Mikhail, do you have that package installed as well?

(In reply to Bastien Nocera from comment #16)
> This is a bug in the djvulibre package, maybe even upstream. Mikhail, do you
> have that package installed as well?

Hello! Unfortunately, have no possibility to check this now: my pc died a month ago (sata controller) and I'm temporary off (writing from Android). Will try to recheck this in two-three weeks (really hope on this so). Sorry.

(In reply to Bastián Díaz from comment #15)
<snip>
> > Alternatively, you might want to also look in ~/.config and ~/.local for
> > user-created "djvu" definitions, which might also be causing problems.
> 
> The solution is not as simple as uninstalling the package, since I had to
> delete the xml files related to djvu in /usr/share/mime (after trial and
> error uninstalling applications that handled djvu files in my system) and
> update share mime info database.

The package is broken. It installs mime definitions but never runs update-mime-database.

> I suppose that other users could have this problem, unless they perform a
> clean installation (I am updating my system from fedora 24).

They wouldn't have this problem unless they install the broken package. I can't do anything about the broken package.

(In reply to Bastien Nocera from comment #18)
> (In reply to Bastián Díaz from comment #15)
> [...]
> > I suppose that other users could have this problem, unless they perform a
> > clean installation (I am updating my system from fedora 24).
> 
> They wouldn't have this problem unless they install the broken package. I
> can't do anything about the broken package.

Report it to upstream and close this bug as NOTGNOME.

(In reply to Germán Poo-Caamaño from comment #19)
> (In reply to Bastien Nocera from comment #18)
> > (In reply to Bastián Díaz from comment #15)
> > [...]
> > > I suppose that other users could have this problem, unless they perform a
> > > clean installation (I am updating my system from fedora 24).
> > 
> > They wouldn't have this problem unless they install the broken package. I
> > can't do anything about the broken package.
> 
> Report it to upstream and close this bug as NOTGNOME.

Bastian isn't the original reporter. See comment 17.

I know you are not, and I did not mean you should report it. But whatever.

(In reply to Bastien Nocera from comment #18)

> 
> They wouldn't have this problem unless they install the broken package. I
> can't do anything about the broken package.


I assumed it, thank you.. I had already thought about opening a ticket in the sourceforge of DjVuLibre directly, but it's still on my to-do list.

I had my own run-in with this problem, and I committed a work-around to shared-mime-info rather than waiting for djvulibre to fix this bug.

This is the commit fixing this for shared-mime-info.

commit c8153d039fa9552121d22a650e8912afb8eb831f
Author: Bastien Nocera <hadess@hadess.net>
Date:   Sat Jan 20 14:38:15 2018 +0100

    Bump priority for our DjVu mime-types
    
    To make sure they're preferred to the djvulibre package ones. The
    djvulibre packages provide a version of the magic that'll always detect
    multi-page documents as "images". We want them to be opened as
    multi-page documents.
    
    See https://bugzilla.gnome.org/show_bug.cgi?id=787481
    See https://sourceforge.net/p/djvu/bugs/283/
    See https://sourceforge.net/p/djvu/bugs/85/
    See http://pkgs.fedoraproject.org/cgit/rpms/djvulibre.git/tree/djvulibre.spec#n168

https://sourceforge.net/p/djvu/bugs/85/ says that djvulibre's own mime-types wouldn't be installed anymore after shared-mime-info gained support for djvu files in 2008. 9 years later, and the djvulibre package still seems to install that file, as shown in the Fedora spec file for it:
http://pkgs.fedoraproject.org/cgit/rpms/djvulibre.git/tree/djvulibre.spec#n168

Work-around are:
- rpm -e djvulibre
  The libraries are in a separate package, so shouldn't impact evince's viewer at least
- add the above patch to shared-mime-info packages
- rm /usr/share/mime/packages/djvulibre-mime.xml && update-mime-data /usr/share/mime/
  You'll have a missing file in the djvulibre package, but at least you'll be able to open the files.

> commit c8153d039fa9552121d22a650e8912afb8eb831f

Returns 'Bad commit reference: c8153d039fa9552121d22a650e8912afb8eb831f' message.

(In reply to Mikhail Kasimov from comment #24)
> Returns 'Bad commit reference: c8153d039fa9552121d22a650e8912afb8eb831f'
> message.

Because:
> This is the commit fixing this for shared-mime-info.

Not Evince.

I will leave this link here for registration. I suppose that for things to work well they must do a degree of coordination between the projects.

https://sourceforge.net/p/djvu/bugs/283/#abc6