Bug 1593832

Created attachment 1453550 [details]
test dvi file

+++ This bug was initially created as a clone of Bug #1358172 +++

Description of problem:
DVI is supported format by Document Viewer (evince) [1], but additional package evince-dvi must be installed to display DVI files. However, user is not informed about it, evince only says, that such file type is not supported. More helpful to user would be message informing, that additional package evince-dvi is required.

[1] https://wiki.gnome.org/Apps/Evince/SupportedDocumentFormats

Version-Release number of selected component (if applicable):
evince-3.28.2-4.el7.x86_64

How reproducible:
always

Steps to Reproduce:
1.Get test DVI file from attachments, or anywhere else.
2.Open evince.
3.Open the DVI file.

Actual results:
Error message appears:
Unable to open document “file:///home/test/automation/evince/data/TestFileTeX.dvi”.
File type TeX DVI document (application/x-dvi) is not supported

Expected results:
Message informing, that additional package evince-dvi is required.

Additional info:

--- Additional comment from Martin Krajnak on 2018-02-02 07:49:30 EST ---

Maybe we should re-think support for this type of files. It haven;t been working for years and more importantly we just found out that opening the affected file blocks the entire gnome-shell session.

--- Additional comment from Michal Odehnal on 2018-02-02 07:58 EST ---

This is what journalctl log show while the test is run.

--- Additional comment from Martin Krajnak on 2018-02-02 08:12 EST ---

Just note that to obtain logs provided by Michal you have to wait up to 10 minutes and also the vm is eating 95% of cpu and 80% of 4096 MB of memory resources gnome-shell panel is gone, but process is running

--- Additional comment from Martin Krajnak on 2018-06-07 09:45:09 EDT ---

I just found out, that .dvi files are working in gnome-documents as charm but I had to install evince-dvi.rpm which enables support for dvi files for both evince and gnome-documents.

Since the DVI file format is listed as a supported format here:
https://help.gnome.org/users/gnome-documents/stable/formats.html.en
I think that it should have evince-dvi.rpm as a dependency in the same manner as it has dependency on libreofficekit for displaying libreoffice documents.

The secondary problem is that evince-dvi has around ~170 dependencies, most of them are TexLive packages which might be unnecessary package overhead for people who will not use DVI format. For that case I would consider at least something like helper message which will tell the user to install additional package (evince-dvi) if he requires .dvi support. 

What do you think Debarshi, what solution will be better ? Should we try t osolve it here or propose upstream ?

--- Additional comment from Debarshi Ray on 2018-06-07 12:02:31 EDT ---

Oh, sorry, I forgot about this bug. Yes, you need the specific evince backends for the MIME type you want to render. Although, it's strange that it blocks the entire session that way. Does evince also do that?

The evince-dvi subpackage shows up as an add-on for evince in gnome-software.  I don't know if it can also be made to show as a gnome-documents add-on.

--- Additional comment from Martin Krajnak on 2018-06-07 12:16 EDT ---

Well, without that addon evince is acting the same way as gnome-documents, it shows the message that the application cannot handle the file.
My point is that from the user perspective, there is no clear way to know that the addon needs to be installed. I found out about the addon thanks to comment in stack overflow thread, otherwise I would think that it is a bug ...

--- Additional comment from Debarshi Ray on 2018-06-08 05:15:24 EDT ---

Thanks for the screenshot!

Other than showing up as an add-on, the error messages can also be improved to let the user know that there might be some missing backends that can be installed. Maybe that can help?

As for evince, does it also block the session when it fails to load the file?

--- Additional comment from Martin Krajnak on 2018-06-08 05:21:35 EDT ---

Ah, sorry I forgot about my comment, the session is not blocked anymore at least on I can confirm that for RHEL 7.5 and Fedora 28, so that is not an issue anymore.