From https://github.com/hadess/gnome-thumbnailer-skeleton/

Those files were necessary for autotools, but just contain duplicate
information nowadays, remove them.

The content attribute of the meta tag is supposed to point to another
item with that id, but we can easily support it pointing directly to an
image path.

Look for the "cover-image" manifest item property as defined in the
EPUB 3.2 spec:
https://www.w3.org/publishing/epub3/epub-packages.html#bib-epub32

Closes: #2

This makes it easier to check on the process without having to
instrument the code manually.

Ed Bruck authored Oct 23, 2019 and Bastien Nocera committed Oct 23, 2019

https://en.wikipedia.org/wiki/EPUB#Version_3.0.1

There is not a direct replacement for
GNOME_COMPILE_WARNINGS([maximum]), we can use
AX_COMPILER_FLAGS([WARN_CFLAGS],[WARN_LDFLAGS]) but that enables
Werror by default so I think is better to resolve that in a
separate commit

https://bugzilla.redhat.com/show_bug.cgi?id=1103325

Chris Lee authored Apr 04, 2014 and Bastien Nocera committed Apr 07, 2014

If the OPF file is in the root dir, g_path_get_dirname returns "."
instead of an empty string. This results in an invalid key for the cover
image, because it looks like "./OEBPS/cover_path.jpg" instead of
"OEBPS/cover_path.jpg" and then unzipping for that path fails.

We were never checking the retval of get_cover_img_num() so if
no covers were found, we'd try to read index-of-first-img minus 1.

Chris Lee authored Nov 13, 2013 and Bastien Nocera committed Nov 13, 2013

The image data isn't encrypted, so we can still generate thumbnails.

http://wiki.mobileread.com/wiki/MOBI#MOBI_DRM

It's useless doing so, and only leads to confusion.

This stops a crash in the thumbnailer if the cover cannot
be found.

This makes it easier to debug decompression problems.

The error domain used (0) is invalid. We now use errors in the
G_IO_ERROR domain instead.

Propagate errors from internal functions.
Don't doublefree sections on errors.