What can this do that our existing PDF, XPS, and e-book viewers can't?

Not be bloated and slow

I fail to see how our existing selection is either of those, so I'm going to consider that comment as "subjective" until I see benchmarks that state otherwise. Do you have any objective reasons, i.e. features, that would make this a compelling choice over our existing offerings?

Ok, wow. It's not like I'm trying to sell you a loan here. Fine, here are some reasons I think it would be a good thing for Solus to package mupdf.

It's written by devs who know what they're doing
It's written in C
It's actively developed and they actually add useful features while keeping things slim
It doesn't have nonsense deps, case in point:
https://gitweb.gentoo.org/repo/gentoo.git/tree/app-text/evince/evince-3.22.1.ebuild
vs https://gitweb.gentoo.org/repo/gentoo.git/tree/app-text/mupdf/mupdf-1.9a.ebuild
vs https://gitweb.gentoo.org/repo/gentoo.git/tree/kde-apps/okular/okular-16.12.0.ebuild

As you wanted some benchmarks, I fired up my old eeePC with Intel Atom CPU and did some testing. Opening a 216 page pdf, Evince used 54 MiB of memory while mupdf used 9.4 MiB. Doing a search, Evince took noticeably longer than mupdf. Jumping between pages, 100 to 170 and so on, same observation.

Then I opened a 2352 page pdf. mupdf opened almost instantly while Evince took a while to load up and render. mupdf used 13 MiB of memory, Evince 65 MiB. Doing searches, mupdf's memory usage increased by 1.4MiB while Evince got a bit slower and memory usage increased by 13 MiB.

Overall, mupdf was more pleasant to use and a great choice for a user without a powerful PC/laptop. It's also a great choice for Mate/i3 etc.

Cheers

(...) so I'm going to consider that comment as "subjective" until I see benchmarks that state otherwise.

I have just found benchmarks on their website (--> Benchmark Tests): http://artifex.com/mupdf-technical-information/#main-item-2

Their full list of annotation features (and planned features for the desktop version) is also very impressive: http://artifex.com/mupdf-technical-information/#sub-item-3

Website: http://artifex.com/products-mupdf-overview/
Licenses: http://artifex.com/licensing/

Since 1.10rc1 they also have a new CJK font with language specific variants which improves readability for Asian languages.

I would be very happy to see this in the repository.

MuPDF is a minimalistic keyboard-driven document viewer. I'm using it for several years beside evince and can confirm it's significantly faster and seems to better render the document pages.(Opening a pdf file of around 100 MB is obviously faster in MuPDF)
Considering the fact that the program is under active development and is included in Ubuntu, Debian, Fedora, and OpenSUSE official repos I think it should be added to solus repo.

@JoshStrobl
What's the way to ask for a reconsideration without triaging issues?
All I was mentioning in my previous comment were related to Inclusion Policy i.e. Value Add, Software Age, 2-Distro Waiver

In T2156#37923, @JoshStrobl wrote:

What can this do that our existing PDF, XPS, and e-book viewers can't?

It is one of the best and fastest EPUB reader (it is rendering software though) available in Linux, Okular is slow and require KDE dependencies, fbreader is too ugly (I don't want to use different e-book reader just to read some epub files when I can read PDF and EPUB with mupdf ) , Evince doesn't even support EPUB, Zathura has support through mupdf https://git.pwmt.org/pwmt/zathura-pdf-mupdf
here is an article which describes why mupdf is useful
http://www.linux-magazine.com/Issues/2015/180/MuPDF

this page describes why mupdf is great
http://artifex.com/products-mupdf-overview/
I am currently using it by building it locally, having it in Solus official repository will be great.

The reason I see the MuPDF is valuable is that it does a really good job at reloading modified documents. I tried with evince and zuathura, both of which experience screen flickering when the pdf file is modified and reloaded. This is annoying when working with latex with a real-time compiling setup.

On the other hand, mupdf can reload the file without any flickering by using the command "killall -HUP mupdf".

Is it still possible to reconsider this request?

@JoshStrobl Sorry if this is an unwanted necro, but I thought this would be better than opening a new task when this already exists.

I've recently been having issues with evince and both (a) large (>100MB) pdf files and (b) reloading a medium-sized (10-100MB) latex-compiled pdf files.
Looking online it seems that MuPDF has developed a reputation for being significantly faster with rendering, and doing a particularly good job at supporting features not found in other PDF editors.
For example in this blog post http://freesoftwaremagazine.com/articles/opening_large_pdf_files_mupdf_comes_rescue/ the author recounts an example where MuPDF was able to easily handle a document which evince struggled with.

Evince, Okular and Zathura (the pdf readers currently in the solus repo) all use the poppler rending engine. A test done between poppler and MuPDF shows the following performance gap:

To me, this makes a compelling case for the benefit of having MuPDF available. Would you consider including it?

@JoshStrobl any chance of a response?

Another use case:

I started using muPDF a few weeks ago, as a replacement for pdftk, to split/extract/sign pdf files on command-line.

I've been long-time user of pdftk (10 years perhaps) and the lack of it in solus is a problem for me.
Pdftk has been requested several times (T866, T3323, T3488), saw no progress even after being accepted, and died.
It is in addition needed in other software (e.g. T8364) for pdf manipulation.

There are other candidates that could replace pdftk.
After trying a few of them, I was very impressed by the performance of muPDF.

btw, I packaged it locally. Both the x11 and gl versions worked swimmingly. On pdf files containing large vector graphics, evince/okular are extremely slow in rendering, but mupdf renders instantly.

Registering to mention that I also find it necessary. I ended up installing it myself. Other pdf-viewers have noticeably slower navigation and loading speeds, especially for large documents.

I would also want to have MuPdf available in our repository. The reason is I wanted something lightweight, straightforward, with good benchmarks, and supporting keyboard navigation. I was sure it would be included based on those characteristics compared to alternative PDF readers, so I went straight to terminal and ran sudo eopkg it mupdf. When it failed, my first assumption was just that it was spelled differently in our repos because I was assuming it is a standard thanks to its performance and would be included, but later understood it just is not there.

I do use Okular for the edit functions, but would really prefer using MuPdf for everything related to just reading. The minimalistic UI is also very nice to have when multitasking with many windows displayed at once.

@JoshStrobl Could you provide your thoughts regarding our feedback? It is not really good for us to keep giving our perspectives while seeing no response from the core team.

@JoshStrobl Can you take a look at this request and see whether it's worth re-evaluating its inclusion in the repo?

Not meaning to put any pressure on Josh, but just to bring grist to the mill, some recent observations on another Linux device:

I am using MuPDF on my phone (which runs a desktop Linux distribution inside SailfishOS via chroot or nspawn and xfce4) because (1) it just is lightning fast even of such hardware, (2) the keyboard commands make it extremely convenient because my phone has a hardware qwerty slider keyboard and I never have to tap on tiny icons on a small screen, and (3) the minimalist UI allows for more content to be displayed, which is crucial on small screens. And by using it, it reminded me of several features I had forgotten about, but that are readily available in MuPDF without messing with menu bars, context menus, or external tools, like rotating pages, fitting to width or height, switching between grayscale and colors, inverting colors, etc., all with keyboard shortcuts.

All features and characteristics mentioned above would make a lot of sense on real computers too, not just in my particular phone use case. The fact that it is (the most) useful (document viewer) in my particular niche case just shows that MuPDF is a very relevant offering, because it is lightweight, has many features in a small and simple package, and is keyboard-driven; those are things no alternative document viewers combine in the same way.

Marvellous! Thank you very much for reconsidering this request.

Since this has been accepted, and Zathura is currently in the repo, there is a closely related item worth mentioning: https://github.com/pwmt/zathura-pdf-mupdf
This project appears to be actively maintained, it adds MuPDF as a backend for Zathura.

Should I make a separate task for this, or is it alright to just leave this commit here?

@tecosaur Feel free to provide it as a patch alongside muPDF.

Heh. I'd love to but as much as I'm keen to contribute I've never packaged anything and have a fair bit on my plate already for the foreseeable future ?.
Currently, I'm just able to clamour for the packages I think would benefit the Solus ecosystem, and cheer on those that take up the mantle ?

@hashhsah would you consider also doing https://github.com/pwmt/zathura-pdf-mupdf ?

The MuPDF included in the repository was not built with the shipped third party library that is required for clipboard and unicode support in freeglut. The system freeglut package does not support system copy/paste or unicode, so these features are missing in our version of MuPDF in the Solus repository.

MuPDF developpers have tried submitting their patch upstream to the freeglut folks, but it has proven difficult to get them to do anything about it. They are now considering adding a warning if MuPDF is not built with the shipped library to make it clear that key features will be missing.