Wrap new $PATH stuff done (to get dummy 'inkscape' used,
for rsvgconvert purposes) in quotes to try and help with
build problems Shin-ichi had with the Windows version.
Tim Dickson wrote in --
I figured out the cause of the out-of-tree fontconfig cache
creation, and (with help from another packager) a fix.
The problem only occurs when inkscape is installed (which changes the
target tool that imagemagik uses for converting svg files from
rsvgconvert to inkscape's svg conversion program.)
A new `PACKAGE_ONLY` variable to Makefile can be used to
place launcher icon files into $(DESTDIR)$(PREFIX), rather
than using `xdg-...` tools to install them. (Avoids polluting
local filesystem while generating packages, e.g. for Slackware Linux)
h/t Tim Dickson
The requested font & actual font loaded will be echo'd to STDOUT
when specifying the `uifont` option.
This uses Pango library directly (I was unable to convice SDL2_Pango.h
to actually notice that pango.h was #include'd before it, and expose
its SDLPango_GetPangoFontDescription() function!). This is okay,
since we want to also add a "--uifont list" option (or similar),
that will list all of the available fonts, if a user wishes to
query them. (And similar code will be added to tuxpaint-config to make
the setting available as a pull-down, rather than (or as well as) a
freeform type-in field.)
Was failing to compile on Haiku for Luc (apparently building with
no SVG support), since I started using that function outside of
SVG-related places.
Also, to continue being able to compile on Linux with no SVG support --
* Always use SDL_TRUE & SDL_FALSE, not TRUE & FALSE
* Always link tuxpaint with "-lm"
Finally, verbose version info ("tuxpaint --verbose-version") now states which
SVG build (new RSVG or old Cairo)
If `convert` fails, and didn't generate a file at all, `make` would
abort due to `rm` being unable to delete the non-existent broken
thumbnail. Using `rm -f` now, so it doesn't abort if the thumbnail
file didn't get created AT ALL.
h/t Luc
Motivation - Without SDL2_Pango, languages like Japanese,
Arabic, and Thai do not render properly. Currently, Debian
(and hence Ubuntu) do not have SDL2_Pango, so Tux Paint 0.9.28
is adversely affected. Fedora DOES have SDL2_Pango, so works well.
This also allows us to delete a lot of ancient cruft code.
Closes https://sourceforge.net/p/tuxpaint/bugs/268/
h/t Pere
(INSTALL docs to be updated momentarily)
Mended a stamp scaling bug just now, so probably worth another
release candidate before making a final release.
N.B. Still waiting to hear back from Pere about Kaleido-# tools
not appearing on Android, before cutting a new release.
When in the middle of adjusting a drawing with Zoom or Perspective,
you could change the color. However, the background would not
relfect this until you further adjusted the zoom/perspective.
Now, a color change causes the background to update immediately.
This involved updating the Tux Paint Magic API to send more
arguments to each Magic tool's "XYZ_set_color()" function,
which means a bump in the API version.
(Forthcoming, all other Magic tools will have their set_color()
functions updated.)
Also, add other social media accounts to list of places to
announce Tux Paint in RELEASE docs.
Also, list a ton more options missing from default example config file
"src/tuxpaint.conf"
Previously Pango loaded system-supplied fonts instead, which could lead
to fonts not rendering in a human-readable text. This change fixes
https://sourceforge.net/p/tuxpaint/bugs/265/
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/
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
