This adds a blend mode for all known psp blend modes that were not
converted yet except for adjust.
I couldn't find any information about adjust and it's value of
255 suggests that it is not a normal blend mode.
Reduce number of undo steps created by Spryrogimp previews.
First, by grouping them into a single undo.
The implementation adds a function for clearing the
incremental preview drawing that is being executed as an idle task,
and closing an undo group in case the preview left it open (which
would usually be the case). A second way to reduce undos is
by generating a new preview only upon mouse button release of
scales in the UI, and not while dragging the scale.
So it turns out there are still a few bugs in librsvg position/size
computation. One of them is described in my comments:
https://gitlab.gnome.org/GNOME/librsvg/-/issues/250#note_900325
To work around them, I had to increase stroke width of a SVG <circle> to
be over 0.5px.
It now uses rsvg_handle_get_geometry_for_layer() instead of
rsvg_handle_get_(position|dimensions)_sub() which have been deprecated
in favor of the new function which returns accurate (double) positioning
and size.
Back when I first made this build tool, librsvg had several blocking
bugs to make icon extraction work properly. This seems to improve
nicely.
Nevertheless I still don't build this tool because after testing, more
bugs remain and icon extraction is still not right. Just updating the
code to undeprecate it but leave the build commented out for now. ;-(
See librsvg#134, librsvg#128 and librsvg#250 for bug reports following
these issues.
See commit 1e5cf10585.
I am reorganizing again a bit the global file with all icons to
experiment a bit again with icon extraction using librsvg (let's see how
the library evolve since last time I tried, a few years ago!).
Traditional -config scripts are awkward for cross-compilation, multilib
systems (lib/lib64), and multiarch systems like Debian; only one copy
of the -config script can be in the PATH. As a result, some OS
distributions are starting to deprecate or even remove them.
pkg-config is designed to be a replacement for traditional -config
scripts, and is cross-compilation-friendly: the PKG_CHECK_MODULES macro
looks for an architecture-specific executable like
x86_64-linux-gnu-pkg-config, which can look in an architecture-specific
search path for library metadata, before falling back to a generic
pkg-config executable.
As a bonus, pkg-config also compares version numbers correctly
(see #2454).
libwmf having pkg-config metadata seems to be a relatively new thing,
so I've kept the -config script code path too, using it if pkg-config
does not find libwmf.
Bug-Debian: https://bugs.debian.org/956183
Signed-off-by: Simon McVittie <smcv@debian.org>
AVIF import and export (need libheif >= 1.8.0)
High bit (10/12) import and export
Auto pre-select suggested output bit depth in save_dialog
NCLX color profile import (link with lcms)
Metadata import (link with gexiv2)
Plugin will not return GIMP_PDB_SUCCESS in case of failure to import file.
Our currently registered JPEG magics was using possible fields at the
start of the file (JFIF, Exif) in 7th byte. A JPEG provided in #5584 was
starting with yet another field (apparently some Photoshop-specific
field "Photoshop 3.0.8BIM") thus magics detection failed (and since
extension was wrong, the file was sent to another plug-in, hence loading
failed).
Looking further, it looks like the 3 first bytes are actually always
common to all JPEG and are the right magics/signature for a JPEG. These
3 bytes don't seem to be used by other formats as well according to my
research, which means we should not have false positives either. So
let's switch to this magics 0XFFD8FF at byte 0.
To build GIMP without vala the arguments "--enable-vala=no --with-vala=no"
must be used during the configuration process. If the --with-vala is not
provided the build process will still try to build some vala based plug-ins.
Fixes https://gitlab.gnome.org/GNOME/gimp/-/issues/5389
These icons are not available in any of our themes (Symbolic or Color).
Also they don't seem to be available in many icon themes either actually
and I'm not sure GIMP properly fallbacks to system icon theme when an
icon is missing in the selected theme anyway (I think to remember this
used to work, but it doesn't look like it works anymore).
Anyway I just copied the 2 symbolic switch on|off icons available in the
GTK+ repository at gtk/icons/scalable/status/. These are supposed to be
used by GtkSwitch but somehow they aren't. So for the time being, let's
bundle them directly with GIMP (until we figure something better out).
I put them in hicolor because this is the generic/default theme which is
always used as last resort and is common to any theme. It means any
specific theme will be able to override these icons, but if missing,
hicolor will be able to provide a fallback.
Starting from psp file version 4 the specification recommends to always use the
block/chunk length to determine the next part of the image. This way it is
possible to skip parts you don't know or don't care about or additions in
newer versions.
This change makes sure to always do this which fixes reading several images
which crashed the plug-in before.
Also only try to read layer data if it is a raster layer.
When clicking on the selection mask (in the dockable view) or when
dropping a color on this same view, we can now select by color based on
the selected layer composition (not only one single layer, nor the whole
image as sample merged, but also a specific list of composited layers).
gimp_channel_select_by_color() is made multi-drawable aware as a
consequence of this.
I discover that the selection editor has these hidden features that (1)
you can click on the selection mask (in the editor dockable) and it
behaves like the Select by Color tool (not sure exactly how useful this
feature is as you can't really see where you click though) and (2) you
can drop a color and it will select this color also as though clicked by
the Select by Color tool (which looks quite useful!).
These features use the option values as set in the Select by Color tool.
Unfortunately both these features were broken when a non-zero threshold
was set because it expects a [0-1] range whereas threshold is [0-255].
Fix the parameters in gimp_channel_select_by_color() call.
Additionally to loading the default fontconfig configuration file, GIMP
also looks up /etc/gimp/<version>/fonts.conf and
$XDG_CONFIG_HOME/GIMP/<version>/fonts.conf (or equivalent in other
OSes). If these don't exist (which is the most common case), this is not
considered a bug. Fontconfig had a regression bug of
FcConfigParseAndLoad() in 2.13.92, which was fixed in a later commit:
fcada52291
As a consequence of this bug, font loading failed in Windows when these
non-mandatory files were absent.
The current commit, originally proposed by Jacob Boerema (@Wormnest) and
slightly reviewed works around the issue, because anyway there is never
any reason why failing to load these files should break font loading as
a general rule. Even if these files exist and are broken (wrong syntax
or whatnot), we should just output some warning on stderr and continue
loading without these additional confs.
With fontconfig 2.13.92, warnings will be also outputted (wrongly), but
at least it won't block loading anymore.
Also let's unref() the `config` object even when the whole font loading
succeeds. Man of FcConfigSetCurrent() clearly says that the reference
count of config is incremented since 2.12.0 (our current minimum
fontconfig is 2.12.4) so let's not leak one reference.
Jehan