On Mon, 12 Oct 2020 22:17:57 -0500 Douglas R. Reno via blfs-dev wrote: > > On 10/12/20 9:41 PM, Bruce Dubbs via blfs-dev wrote: > > I have been struggling today to get a satisfactory build of > > mupdf-1.18.0. I can get it to build, but it also builds its own > > copies of curl, freeglut, freetype, harfbuzz, lcms2, ligjpeg, > > openjpeg, and zlib and links them into the executables. > > > > There is supposedly a way to use system libraries for the above, but > > the procedure for using it in this version of the package breaks the > > build. > > > > The build procedure for this package is custom. There is a manually > > edited Makefile, but no configure. The details of a build are not > > documented and difficult to discern when reading the Makefile. > > > > In BLFS we already have evince and okular that provide the same > > functionality as mupdf. Is there any reason to not just archive mupdf. > > > > http://wiki.linuxfromscratch.org/blfs/ticket/14110 > > > > -- Bruce > > > The primary reason not to archive MuPDF is that IIRC cups-filters needs > it to function properly (it uses mutool) > -- > http://lists.linuxfromscratch.org/listinfo/blfs-dev > FAQ: http://www.linuxfromscratch.org/blfs/faq.html > Unsubscribe: See the above information page
I use qpdfview which has been quite satisfactory. As to cups-filters, I have --disable-mutool and mupdf not installed. It is an alternative to ghostscript or poppler that a GSOC student implemented that was claimed to be a lighter renderer for mobile devices. On a desktop it wouldn't seem to offer an advantage. You might consider lowering it from Recommended to Optional. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
