GIMP's path import code is largely copied
from an earlier version of rsvg. Therefore,
it does not include updates that made
number processing more robust
(such as properly parsing 'c1.5.2' as '1.5, 0.2'
for curve coordinates)
Per the suggestion by @federico, this patch
updates our code using rsvg-path.c from
the last version of the C-based librsvg
(updated November 3rd, 2016).
Our original code also broke if there was any
spaces after the last item in the SVG transform
attribute. This patch adds a call to
g_strstrip () to trim any unnecessary spaces
either before or after the transform string
to prevent this issue.
- The "Healing Brush" paper URL is dead. It now leads to one of these
horrible parasitic websites which reuse domain names. And we for sure
don't want to promote this! I'm using instead the associated page on
our developer website. I just created this page and right now it's on
testing only. But this will be the URL for the main website.
- The URL for the foreground extraction paper is still valid, but from
my small research today when writing various algorithm' pages, I think
our own implementation diverged from this original paper (though it
may still have part of this original paper's algorithm; only a deeper
check of the code would tell).
See: https://testing.developer.gimp.org/core/algorithm/foreground-extraction/
Also this PDB procedure is called generically gimp_drawable_foreground_extract()
and it even has an argument to choose the algorithm (even though right
now, there is only a single choice, which is "Matting" algorithm, and
even there you can't choose which one; it's always Matting Global;
Matting Levin cannot be chosen for instance).
So anyway it is not a good idea to point to one specific algorithm,
and even less to leave an external URL (which may also disappear some
day) in API docs. So I am just getting rid of this paper title and
URL, and replace it with actually useful information, which is how to
set the trimap to represent foreground, background and uncertain
pixels (note: I notice that it would have been different with Matting
Levin where uncertain pixels must apparently be set transparent).
Since this is now a build breaker (on purpose), let's add some notes on
how to properly set your build system so that our list of GUI languages
are self-localized as we want them. I am guessing that if we don't add
this info, we may soon get reports by various distributions' packagers
about our build being broken.
This explains so much why I was regularly seeing screenshots of packaged
GIMP with a list of languages in English, in forums or tracker. Unlike
desktop machines, I am guessing that most build servers are just set as
C or POSIX locale and that would just break our pre-localization build
script.
Seems like our CI runners are configured with POSIX locale. Both C and
POSIX locales are basically overriding any attempt to localize during
the build (setting LANGUAGE doesn't work) and unfortunately we are now
self-localizing the list of languages during build.
So let's add a bogus en_US.UTF-8 locale before setting LANGUAGE. This
should fix the issue. It would probably also fix the same issue for
various third-party packages if distributions' build machines are set
similarly!
Resolves#15286
Adds a check to the memory allocation
in pnm_load_raw () with g_size_checked_mul ()
to see if the size would go out of bounds.
If so, we don't try to allocate and load the
image.
Resolves#5627
The current limit for Clipboard Brush and
Pattern maximum size is set to 1024 because
that is the largest value that a 32-bit
architecture can safely handle.
64-bit architectures can support larger
dimensions, as confirmed by
Stanislav Grinkov during testing. This patch
therefore uses macros to increase the
size limit if we detect a 64-bit architecture,
and otherwise default to the 32-bit limit.
Resolves#15292
The IFF specification states that EHB format images
have exactly 32 colors in their palette. However, it
is possible for images in the wild to place an incorrect
palette size. This patch checks for this, and either limits
the palette size or breaks accordingly.
Resolves#13570
The SVG specification prohibits certain characters
from being used as part of a path id attribute, such as
whitespace and hyphens. Rather than try to filter the
path name selected by the user, this patch switches to
an auto-incrementing "path%d" format to ensure any
exported path can be read by strict parsers. This also
matches how we implemented ids in the SVG export
plug-in.
This last argument in libmypaint's mypaint_brush_stroke_to_2() is called
barrel_rotation. If you look at MyPaint's code (in particular file
gui/freehand.py), you see it is taken from GDK_AXIS_WHEEL of the input
event, which corresponds to our coords->wheel (there is this
long-standing question about the difference with GDK_AXIS_ROTATION
because as far as we know, this is probably the same value anyway; as
was explained to us by a Wacom developer long ago).
Unfortunately I can't test as we don't have any stylus with such barrel
rotation feature (and unfortunately this hardware feature is
discontinued and getting a stylus with this is extra-hard now), but that
should work. And at the very least, it does match with MyPaint's
implementation.
Resolves#12755
gimp_edit_selection_tool_active_modifier_key () assumed
that if you press a modifier key while a selection/move tool
is active, we should move the selected item to the last place
recorded. However, it's possible to run this function before
we've moved anything, thus defaulting the "original position"
to 0, 0.
This is most noticeable in the Move Tool, where pressing Ctrl
or Shift after clicking a layer but before moving it will cause
the layer to "jump" based on where the cursor is placed on the
item.
This patch adds an additional condition to the motion function
in gimp_edit_selection_tool_active_modifier_key (), so that
we only do it if we've already moved the cursor at least once.
See: Infrastructure/gimp-web-devel@7be7fbe0
In short, such information is not needed to making/building the
packages, just to submitt/release them, which is maintainer-thing.
But let's keep at least a reference so making them easier to find.
Since we don't necessarily re-render the color area when the color
change, let's store the actually rendered color, additionally to the
supposedly rendered color. Otherwise when changing the color by very
small increments, small enough that the color is always perceptually
identical to the previous color, we never re-render the widget, even
when the rendered color is now quite different. Indeed the "identical
color" algorithm, based on CIE2000 distance, is not transitive.
Additionally I do not check for perceptual identity in
GimpColorSelection anymore, because we also check for this in the
GimpColorArea. Better always having the right color set in the area.
This was raised in #11339 (even though the initial issue was about the
hexadecimal field).
MR glib!4901, backported as glib!4912, will be available in version
2.86.3. Let's keep the workaround so that link layers work without
having to bump the minimum requirement, but add a GLIB_CHECK_VERSION
test. This way, it will be clear that we have to get rid of this part of
the code even if we bump the GLib requirements years ago, when we'll
have completely forgotten about this issue.
Resolves#153494812fddc adds the ability to delete multiple items
at once. However, the limit to delete was accidentally
set to greater than 1, rather than 0. This patch fixes
this mistake.
As of 443947c6, we no longer require passing
the selected drawables to the export plug-ins
(as each plug-in now grabs those from the
image itself).
Therefore, we can remove the restriction that
there must be a selected layer before you
can export or save an image.
This should be unnecessary since GExiv2 did the break properly by
renaming files (making it possible to install side-by-side an older
version of GExiv2 and a newer version). But some packagers are wrongly
renaming the .pc file, tricking our build system into accepting the
newer incompatible libgexiv2.
So let's add an additional test, explicitly forbidding newer GExiv2.
We'll move on to the new version when we'll be ready. For the time
being, there is a reason why files were renamed and packagers should not
force incompatible versions to fit.
