GitLab

Although I haven't been able to reproduce it, it is apparently
possible to get a Stack Overflow when loading xcf files with
presumably very large dimensions on Windows. From what
I'm reading Windows normally has a smaller stack size than
Linux, probably why it hasn't surfaced there.

Instead of allocating on the stack let's do a g_malloc0
combined with g_free.

Based on the proposed process proposed by Akkana Peck. Thanks Akk!
For now, it's only in the meson build, which is fairly terrible to use
as soon as we do custom build rules. Here are the list of issues:

- meson does not allow building in subdir (issue 2320 on meson tracker).
  Sure I could make several subdirs with meson in them. But here the
  future goal would be to be able to generate docs for other
  introspected languages, and maybe also other output formats (epub or
  whatnot). For this, since these are basically the same commands which
  are used, the best practice would be to have loops generating one
  target per language/format combination, reusing code rather than ugly
  copy-pasting in subdirectories' meson files).
- custom_target() requires the output parameter to be the complete list
  of generated files. But we have more than a thousand of them. It's not
  practical. Maybe we could try to find a way to generate the list from
  the contents of the .def files which are already exhaustive and exact.
- Install also requires the output list to be complete.
- I temporarily have these docs not generated by default (because the
  gtk-doc option is already crazy slow as it is, making meson near
  unusable for development if it's enabled). If you want to generate the
  docs, the commands are as following (yeah I don't understand what the
  target names are for since meson does not actually create targets with
  these names, so we have to use fake output names instead):

> ninja devel-docs/g-ir-docs/Gimp-python-html
> ninja devel-docs/g-ir-docs/GimpUi-python-html

The `precision` parameter in particular had no min/max, which meant we
could provide a forbidden parameter (e.g. a negative precision) which
would cause a core CRITICAL. We must forbid illegal values from PDB side
(hence outputting a normal plug-in error message, not a core bug).

Also improving a bit the description of this parameter as I was
wondering what precision was needed exactly to get a stroke length. This
is the precision for determining whether a portion of the stroke is
"straight enough" or if we want to break it into smaller pieces until we
get a straight portion.

All it will mean is that we are looking for perfectly straight lines
when deciding if a bezier curve can be considered straight. It's a fair
condition and represents perfectly what a precision of 0.0 would mean.

… apply to GIMP GUI not text layer rendering in image.

Reviewer note: this is the theoretical fix, but it won't work right now
because Cairo explicitly bypasses grayscale antialiasing when system set
subpixel one. Still let's push this first patch, but the issue will be
actually fixed when Cairo will merge my MR too:
https://gitlab.freedesktop.org/cairo/cairo/-/merge_requests/114

Argh I should have properly reviewed !392 (commit c264f0b7).
It was leaking the return value of a g_path_get_basename().

In GIMP 3, plug-ins are mandatorily under a subdirectory. Though on GIMP
2.10.x, both cases are still possible. So only the previous commit
should be backported to gimp-2-10 branch.

See discussion in !392.
Thanks also to Christopher Nielsen for helping.

gimp: macOS: fix for file export dialogs GIF and PNG. Authored by @pietervo, and he should be credited with this.

This commit fixes the issue when requested page width/height was
not honored because DPI resolution value was constrained to whole
integer numbers only.

(cherry picked from commit 342ad0b8)

(cherry picked from commit ede0292f)

The tool now takes care of the portion of the layer effectively displayed
on the screen. This allows faster expansion/shrink of the selection since
an area smaller than the whole layer is used.

It will also limit the impact of the incoming multilevels processing, which
tends to decrease the segmentation accuracy on thin structures, since users
often zoom-in to work on such thin details.

PNG has support for profiles, which is the state-of-the-art way to
handle color management nowadays. But it also had some very basic color
management based on a gAMA chunk (for the gamma) and a cHRM chunk
(primary chromaticities).
We don't have a core concept with just these and don't want to walk
backward anyway, but we can easily make basic RGB profiles from these.
This is what this commit is about. It generates profiles at import which
were not actually inside the image, but only represented by these 2 PNG
chunks. What gives it away is that GIMP will propose to convert/keep the
profile at start (unless configured otherwise, as any profile), and the
profile name will specify it is a profile generated from PNG chunks'
values.  One can even discard the profile later (if you didn't convert),
so it gives a solution if somehow these metadata were not proper.

darktable GUI is "mangled" when opened from GIMP for a reporter. There
was already some debug info outputted (when running with DARKTABLE_DEBUG
environment variable). Adding the environment list (and some separation
titles to make it easier to distinguish what is what). Hopefully it will
help debugging.
See #6195 and https://github.com/darktable-org/darktable/issues/7402

There is a possible bug in libheif. Lossless setting is not working
when AVIF is saved via rav1e encoder.
This is a workaround of the problem.

We were not handling all possible record sizes for mask info and
in case it was an unknown size we set everything to 0 instead
of reading the parts we do recognize.

Let's make it more flexible by reading the parts we do know
about and skip the remaining data if any.

Also added a few more g_debug statements to make it
easier to check some values when needed.

Not sure why we didn't see the crash earlier and it suddenly shows up
now. Anyway we must delete the exported image **after** calling
gimp_procedure_config_end_export() on it, obviously.

Commit 01e1587e had directly edited the Makefile.am, which was wrong.
This file is generated by plugin-defs.pl. Add the proper dependencies
for file-heif and regenerate the Makefile.am.

When a profile is set, we should not set the sRGB chunk, because it
would be a contradiction. But when we don't set the profile, then our
code explicitly saves as sRGB. So let's add the sRGB chunk.

Also when we do so, let's also set the relevant gAMA and cHRM chunks
corresponding to sRGB as recommended by the PNG spec:

> An application that writes the sRGB chunk should also write a gAMA
> chunk (and perhaps a cHRM chunk) for compatibility with applications
> that do not use the sRGB chunk. In this situation, only the following
> values may be used: […]

This is why I use png_set_sRGB_gAMA_and_cHRM() and not just
png_set_sRGB().
See also discussions in #5363.

Add in particular some notes about alignments and trailing whitespaces.