mupdf 1.10

[Pierre Labastie]

New minor version:

 MuPDF 1.10 (2016-11-21)

The 1.10 release is now available.
MuPDF 1.10-rc2 (2016-11-17)

The second release candidate for version 1.10 is now available.
MuPDF 1.10-rc1 (2016-11-09)

The release candidate for version 1.10 is here!

Headline changes:

    FictionBook (FB2) e-book support.
    Simple SVG parser (a small subset of SVG only).
    mutool convert: a new document conversion tool and interface.
    Multi-threaded rendering in mudraw.
    Luratech decoders for JBIG2 and JPEG2000 (commercial releases only).
    Optional JPEG-XR support (not included by default for security reasons).
    Updated base 14 fonts from URW.
    New CJK font with language specific variants.
    Hyperlink support in EPUB. 

Reduced memory use:

    New tool muraster: example printer driver with limited RAM usage and automatic banding.
    Alpha channel is now optional in pixmaps.
    More aggressive purging of cached objects.
    Partial image decoding for lower memory use when banding. 

Reduced code size when building with a subset of features:

    Reduced default set of built-in CMap tables to the minimum required.
    FZ_ENABLE_PDF, _XPS, _JS, to disable features at compile time.
    Function level linking. 

Interface changes and cleanups:

    Dropped pdf object generation numbers from public interfaces.
    Simplified PDF page, xobject, and annotation internals.
    Closing and freeing devices and writers are now separate steps.
    Improved PDF annotation editing interface (still a work in progress).
    Document writer interface.
    Banded image writer interface. 

Mobile viewers:

    New JNI interfaces to match capabilities of 'mutool run' javascript.
    New android and desktop java examples using new JNI interface.

[Armin K]

It might be a good idea to consider ​http://wiki.linuxfromscratch.org/blfs/ticket/8347#comment:2 when updating the package.

[Pierre Labastie]

Thanks for the heads up. I was wondering why the current instructions were not using make install...

[Pierre Labastie]

Replying to Krejzi:

It might be a good idea to consider ​http://wiki.linuxfromscratch.org/blfs/ticket/8347#comment:2 when updating the package.

Hmmm, make install installs three mupdf commands: mupdf-gl, mupdf-x11, and mupdf-x11-curl. As far as I understand (mupdf documentation is not very explicit...), the first one allows rendering with opengl, but does not have the capability of handling network files, the second does the same using X window for rendering, and the third adds the ability to render files directly from internet (using an ​http://... name), still using X window.

Furthermore, three other tools are installed: mutool, muraster and mujstest. the first is a set of tools to manipulate, convert, etc, PDF files. The second may be used as a print filter, and I have not been able to understand exactly what the third does (converting a javascript program to PDF???).

There are also some (sparse) documentation, two static libraries, and a bunch of header files installed.

All in all, the installed files take ~250 MB on disk, and I am not sure they are worth having. So I think it is better to just cp mupdf-x11-curl (as mupdf) and mutool to /usr/bin, as well as the man pages, and maybe the doc. This would reduce the installed size to ~75 MB.

[Armin K]

That's awful lot of space for such simple program. I suggest you look for a way to turn off the debuginfo. I don't think partial package installs in BLFS for no great reasons are that common, but I can't influence on your decisions - if you think it should be your way, feel free to do it like that.

[Pierre Labastie]

Replying to Krejzi:

That's awful lot of space for such simple program. I suggest you look for a way to turn off the debuginfo.

All the executables are slightly the same size (slightly above 30 MB). I neeed to check, but I guess the reason for such a big size is that all the font glyphs are contained in each executable. It cannot be explained with debuginfo alone. Actually, when running gdb /usr/bin/mupdf, I get:

[...]
Reading symbols from /usr/bin/mupdf...(no debugging symbols found)...done.

[bdubbs@…]

It is interesting that my current mupdf program is 8,7 MB. That is version 1.8 on my workstation. On my development system it is 17 MB for version 1.9.

In my log for 1.9 I see a lot of files like:

GEN generated/NotoSansLimbu-Regular.c

So it looks like they are embedding fonts into the executables.

[Armin K]

What's even more strange is that those fonts are built into every executable, because it uses static linking. That gives you 4 executables and 1 shared library, 25 MB each (here). You can use attached patch to build single shared library. Challenge: Transform it into a sed.

[Pierre Labastie]

Replying to bdubbs@…:

It is interesting that my current mupdf program is 8,7 MB. That is version 1.8 on my workstation. On my development system it is 17 MB for version 1.9.

In my log for 1.9 I see a lot of files like:

GEN generated/NotoSansLimbu-Regular.c

So it looks like they are embedding fonts into the executables.

Looks like they added a lot of fonts recently...

[bdubbs@…]

There is not enough consistency in the changes for a sed to make sense. It could be done, but th epatch makes more sense in this case.

What results do you get with this patch?

[Pierre Labastie]

Replying to Krejzi:

What's even more strange is that those fonts are built into every executable, because it uses static linking. That gives you 4 executables and 1 shared library, 25 MB each (here). You can use attached patch to build single shared library.

Thanks

Challenge: Transform it into a sed.

;-) There is sort of a solution at ​https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/app-text/mupdf/mupdf-9999.ebuild?revision=1.51&view=markup

Actually, the use of XCFLAGS allows to pass -fPIC. Then changing '.a' to '.so' in Makefile, and just adding a rule for %.so, I guess we could achieve the effect of the patch (written just before receiving Bruce's comment)...

I have a question: why is the patch adding THIRD_LIB to MUPDF_LIB dependencies?

[Armin K]

Replying to pierre.labastie:

I have a question: why is the patch adding THIRD_LIB to MUPDF_LIB dependencies?

Well, you can see it for yourself if you don't add it. libmupdf.so references symbols from THIRD_LIB, which causes libmupdf.so link to fail. They're always used together, so it matters a little.

[Pierre Labastie]

Replying to pierre.labastie:

I have a question: why is the patch adding THIRD_LIB to MUPDF_LIB dependencies?

I have the answer now (learned the hard way)... Symbols from this library are needed because we do a link, rather than just an archive .a file.

[Pierre Labastie]

The patch allows to have a much more reasonable size: 42 MB installed... It has to be modified because it does not apply cleanly as is with mupdf 1.10. So I'd rather try to make commands like this (still have to try):

sed -e 's/\.a$/\.so/'                    \
    -e '/$(MUPDF_LIB)/s/$/ $(THIRD_LIB)/ \
    -e '$a$(OUT)/%.so :\n\t$(LINK_CMD) -shared -Wl,soname -Wl,$@ -Wl,--no-undefined' \
    -i Makefile &&
make build=release XCFLAGS=-fPIC

[Pierre Labastie]

Replying to pierre.labastie:

The patch allows to have a much more reasonable size: 42 MB installed... It has to be modified because it does not apply cleanly as is with mupdf 1.10. So I'd rather try to make commands like this (still have to try):

sed -e 's/\.a$/\.so/'                    \

This does not work because there is also libmutool.a. Something like /pdf.*\.a/s/\.a/.so/ should do... But it is somewhat fragile. Let's keep a patch. Armin, what do I write for "Origin"?

[Armin K]

I wrote it myself, with little help from Gentoo, which you referenced in Comment 11.

[Pierre Labastie]

Fixed at r18016

[bdubbs@…]

Milestone renamed