Page MenuHomeSolus

MuPDF
Closed, WontfixPublic

Description

MuPDF
https://mupdf.com/
A lightweight PDF, XPS, and E-book viewer.

AGPL
https://mupdf.com/downloads/
https://mupdf.com/downloads/mupdf-1.10a-source.tar.gz

There's X and OpenGL-based versions which can coexist. Both should probably be enabled. For the (OpenGL-based viewer's) dependencies, see README in source tarball

Event Timeline

fcool created this task.Jan 10 2017, 6:15 AM
anaknaga added a subscriber: anaknaga.

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

fcool added a comment.Jan 12 2017, 9:48 AM

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

JoshStrobl closed this task as Wontfix.Jan 14 2017, 7:10 PM
JoshStrobl claimed this task.

Ok, wow. It's not like I'm trying to sell you a loan here.

Don't really appreciate the attitude.

It doesn't have nonsense deps, case in point:

It's also a great choice for Mate/i3 etc.

We're not based on gentoo, so linking to that isn't really helpful, but rather linking to our own packages via our git. Regardless, zathura should fit the bill for i3 at least, and I'm not seeing any reason for including this compared to our existing offerings.

baimafeima added a comment.EditedSep 11 2017, 9:15 AM

(...) 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.

A-Shahbazi added a subscriber: A-Shahbazi.EditedJan 12 2018, 1:04 PM

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.

A-Shahbazi reopened this task as Open.Jan 12 2018, 1:11 PM
JoshStrobl closed this task as Wontfix.Jan 12 2018, 1:27 PM
JoshStrobl changed the edit policy from "All Users" to "Triage Team (Project)".

Do not triage issues @A-Shahbazi

@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

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.

nofob added a subscriber: nofob.Dec 15 2019, 3:22 PM

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.