-------------
data:
* Fix typo in URL (#2030, Germán Poo-Caamaño)
Developers:
* Germán Poo-Caamaño
Translations:
* Efstathios Iosifidis (Greek)
* Balázs Úr (Hungarian)
* Hugo Carvalho (Portuguese)
There's nothing in the PDF backend making use of it. It is only used
in libdocument/ev-xmp.c, which is unconditionally added as part of
libdocument, so add the dependency as global instead
Evince is one of GNOME's core apps. All of them have an explicit
requirement on GNOME systems icon theme, which is currently
libadwaita. That's by design. Let's not clutter the build
infrastructure for something that should be known
At least 4 different bugs were filed against the Flathub version of
evince because Flatpak prominently shows the appdata version in the UI,
making users think that there was a bug in the packaging, or that the
package had not been updated.
Avoid this problem in the future by failing the build if the NEWS or
appdata files aren't updated on release.
* Replace deprecated dep.get_pkgconfig_variable(...) by
dep.get_variable(pkgconfig : ...)
* get_pkgconfig_variable was deprecated in version 0.56 and
we require 0.57, and the replacement has been available since
version 0.51.
Since version 43, nautilus extension breaks the API and depends on
gtk4. Therefore, we build the evince extension for nautilus only
if the version is older. Assume 42.20 is a upper top.
Fixes#1822
Even though Evince can be built with older versions of Poppler,
this plays against users, who depends on distributions to update
the version of Poppler to build Evince. In other words, we are
defering the decision to distributions to determine which version
is better for the users.
However, as we follow closer the development of the libraries
we depend on (at least the most important ones), we are likely be
in a better position to say which version is best for the users
and that is stable.
As of today, poppler is very stable, and the development is
incremental, and they try hard to avoid regressions, as much as we
do.
My motivation to bump the requirement is that I saw users stating
about some bugs or features missing in Evince that has been supported
for more than a year, but Evince could not take advantage of because
the Poppler version was old. For example, searching words in multiple
lines. Like this, there has been several fixes in Poppler that were
originally reported in Evince. If we do not "force" to update Poppler,
it will take longer for the users to see these fixes, and probably
blame Evince because of that.
libspectre usage in the dvi backend is used conditionally on
a cairo device. Therefore, the lack of headers for libspectre
should not disable the support for DVI files.
Evince uses t1lib to render T1 Postscript fonts. However, the library
has been unavailable from distributions like Debian since about 2014.
By then, it had unattended security issues, and no development for
about three years.
The issue was discussed in Debian, see the issue:
"t1lib: history of security issues, unmaintained upstream, unsupportable"
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=637488
In Evince, t1lib was used to rasterize, not to draw glyphs. Still,
it is very likely that the code was never built and/or used since
t1lib stopped being available in distributions.
Time to remove it from Evince codebase.
It's clear that most DjVu "images" are actually one-page documents so
should be loaded in evince, as there unfortunately aren't any DjVu image
viewers available in GNOME.
Use the newly added EV_PUBLIC macro to explicitly mark symbols to be
exported, instead of exporting everything starting with "ev_".
This removes lots of accidentally exposed, private functions. Since
those are not contained in public installed headers, this should be ok.
