Avoid STDERR messages on launch:
libpng warning: Interlace handling should be turned on when using png_read_image
(Except the fact that Tux Paint _itself_ saves drawings with
interlace enabled. :-/)
With this, closes https://sourceforge.net/p/tuxpaint/bugs/252/
Check output for "libpng warning:" lines; the tool also echos
its own "test-png warning" lines about other possible concerns
(e.g. strange bitdepths, etc.) which are not necessarily going
to cause Tux Paint to echo things to STDERR.
New tool, "test-png", which exercises libpng library on
a set of PNG image files, allowing us to find those which
cause Tux Paint (via SDL_image, in turn via libpng) to
report back warnings to STDERR.
h/t Tim Dickson, per https://sourceforge.net/p/tuxpaint/bugs/252/
For the AppStream metadata (appdata.xml), there is a
rule saying that the summary shouldn’t end with a period
(as confirmed by ‘appstream-util validate-strict’).
For the .desktop file, *most* applications omit the period.
The rule is not language-dependent, so I have also
removed the period from all translations (.po files).
If given more than one argument, 'which' prints the path to each one (if
found). Previously, which was passed two arguments: 'xdg-icon-resource',
and 'install'. But in the contained block of statements, 'install' is
an argument passed to 'xdg-icon-resource'. Pass only 'xdg-icon-resource'
to which.
gettext 0.19.7 gained support for translating appdata files, whereas
support for metainfo files was added in 0.20. These file formats are
effectively the same: as documented in the AppStream specification,
desktop applications can install files with the suffix .appdata.xml
rather than .metainfo.xml and these will still be handled correctly.
It is desirable for this project to support RHEL 7, which has gettext
0.19.8.1, so let's use the older filename.
As noted in the same section of the specification, appdata files were
previously installed to /usr/share/appdata rather than
/usr/share/metainfo, but the spec asserts that the newer metainfo path
works all the way back to RHEL 7, so we keep the newer installation
path.
Thanks to Shin-ichi TOYAMA for flagging this issue.
https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#spec-component-location
