See: https://gitlab.gnome.org/GNOME/gimp/-/issues/11876
For 3.0 we will support only Lua 5.1, since we need to figure out how
much of the Lua 5.1 API is compatible with newer versions (Lua minor
versions aren't like Python minor versions, there is API breakage so
plug-ins would be completely unreliable, this commit prevent this).
Also, change some files to not force luajit since it isn't mandatory.
New code uses pango_attribute_as_font_desc() which appeared with Pango 1.50.
Since it's currently present in Debian stable, I don't bother too much and bump
this dependency.
Also let's use the same version for pango, pangocairo and pangoft2. They all
come from the same project/repository, so we must likely expect them to be equal
(if they are not, there is likely a problem).
We use US English which uses behavior. So we replace all occurrences of
behaviour.
Most notable is File Open behavior in preferences. Besides that several
mentions in function documentation and a few in comments.
If we want to encourage meson usage in GIMP 2.99.12 as a test run, our
INSTALL file should target meson commands and options.
Also I took the opportunity fix a bit some parts which were outdated.
intltool has long been dead upstream. Let's not poke the dead corpse,
please.
This commit is quite large, but that's mostly since trying to support a
hybrid of both gettext and intltool with both Meson and Autotools was
really hard, so I stopped trying.
Due to gettext relying on quite some things being at the exactly right
place in the autotools build (like `ABOUT-NLS` and `config.rpath`) we
really needed to cleanup the `autogen.sh` to only call `aclocal` and
`autoreconf`. No more strange magic; I tried to do it without changing
too much in the file, and things just broke. If people want to do
something more custom, they can just change the script directly. This
change also uncovered some problems in our `configure.ac`, like using
deprecated macros.
The following major changes happened:
* meson: Changed `custom_target()` to `i18n.merge_file()` for all
supported file types
* Added `.its` and `.loc` files for the GIMP-specific XML formats, so
that gettext understands them
* For the `.isl` (Window installer stuff) file, there's no easy way to
do this in gettext, so instead we start from an XML file (again with
its own ITS rules etc), translate that with gettext, and then use
`xsltproc` with a bit of magic to output the .isl file for each
language
* the `po*/Makefile.in.in` files are migrated to `Makevars` files,
which gettext natively understands.
Fixes: https://gitlab.gnome.org/GNOME/gimp/-/issues/8028
It's not a direct dependency and doesn't prevent GIMP from any of its
core logics, but HTTP is a used enough format nowadays that we want to
consider it as mandatory nowadays.
From what I know, `gvfs` might be for Windows only though. This would
explain issues we have with remote URL on other platforms.
Recent libtiff supports loading BigTiff automatically so we didn't have
anything to do there (as long as a recent libtiff was used). For
creating a BigTIFF though, we simply needed to add a "8" flag to
TIFFOpen/TIFFClientOpen when creating a new image (i.e. using "w8"
mode) as explained here in the "Implementation Strategy" section:
http://www.simplesystems.org/libtiff/BigTIFFProposal.html
What this commit does:
- Explicitly bump our libtiff requirement to version 4.0.0 or higher
(which is where BigTiff support appeared).
libtiff 4.0.0 was apparently released on 2011-12-22 and is available
on all current distributions, so it's probably not a problem.
- Switch to detect libtiff with a pkg-config test (added in libtiff
commit faf5f3eb before 4.0.0 release, so it's fine) instead of
function checks.
(Note: meson was already detecting for libtiff-4 with pkg-config,
which was obviously wrong since it should have mimicked autotools, but
well… then changes were minimal on meson)
- Add a new "bigtiff" boolean argument to the "file-tiff-save" PDB
procedure, FALSE by default. I set this as the first argument as I
figure that choosing the format you want is quite a major choice.
Unless I misunderstood something, since BigTIFF is really designed to
be an evolution of TIFF with a "minimum change strategy", i.e. mostly
using 64-bit instead of 32-bit offsets, everything which is possible
in TIFF will be in BigTIFF (and oppositely as well, except of course
having huge files) so there is no need to have 2 separate procedures.
- Adding this new argument to the GUI dialog as a checkbox.
- Tweak the load and export procedures' documentation strings to make
clear we support both TIFF and BigTIFF.
Note: interestingly there doesn't seem to be a separate mimetype for
BigTIFF so nothing to update on this side.
- Tweak the procedure labels too to mention BigTIFF. Since BigTIFF is
still a different format (though very closely resembling) from TIFF,
unlike some others which are just extensions embedded in a TIFF file
(like GeoTIFF we recently added), I figure it deserves to be
explicitly cited.
This was added in commit 88f97aedef and only expected to last until
fontconfig had a fix **and** it got into a released version.
This is now done.
I could verify in the git repo that fontconfig's commit 55eb1ef is
included since their tagged release 2.13.95 which is now on MSYS2
(2.13.96 there even), so we will use it for our next release.
Thanks to frogonia (long time no see! \O) for following up on this!
See also fontconfig report:
https://gitlab.freedesktop.org/fontconfig/fontconfig/issues/144
Rust dependencies are not really making everyone happy apparently. We
don't want to make SVG support optional anymore because it is too
important, and unfortunately there doesn't seem to be any suitable
replacement SVG libs so far (or we haven't found them).
We explain this in the INSTALL file and also explain a bit how to bypass
the SVG parts for packagers really needing to do so, allowing GIMP to be
as portable as possible.
See also issue #6821.
Currently it's a mandatory option (and it has been the case for years,
ever since commit 43e218859b) so let's update the info.
Note that there are still discussions going on about this dependency and
it being hard or impossible to build on many platforms (which are stuck
on old C version, before the move to Rust). See #6821.
We'll see how it goes.
Especially now that this is not a blocking build dependency on GEGL, we
want to have the information somewhere so that packagers (and other
people building GIMP themselves) know this is at least an optional
runtime dependency.
Recently updated my distrib, so it's a good time to see what is wrong in
our instructions. In particular, we must build GEGL with Cairo,
otherwise gegl:npd is not built (and it's a mandatory operation for
GIMP).
We are not going to duplicate the whole autotools documentation. Let's
rather just state we follow the GNU build standards, hence refer to
relevant documentation with a link.
Since recently, one can also install the new "libmypaint-v1" branch. It
is not so different, but has several fixes. Among them, it fixes
building with recent automake.
Older --enable-binreloc configure option had basically the same purpose
as the newer --enable-relocatable-bundle, though the old binreloc was
only used for gimpenv.c code.
As a consequence, commit 10ce702188 was still not working fine since
gimp_installation_directory_file() also need binreloc enabled (to be
actually relocatable).
Let's get rid of this whole mess, by implying we want binreloc code to
be used when --enable-relocatable-bundle is ON. We don't need the
m4macros anymore, since AM_BINRELOC was basically just checking that
`/proc/self/maps` was present. But anyway being present at compile time
does not mean it will be at runtime (nor the opposite). So this test is
not that useful. The binreloc code will anyway fallback gracefully to
the non-binreloc code (i.e. trying to use build-time install paths) if
the procfs is lacking at runtime.
This is a runtime dependency. If absent, we simply won't have access to
the alternative Matting Levin engine in the foreground selection tool.
If we don't add a test in configure, this may be easily forgotten. I
created the `gegl --exists` feature specifically for this kind of
checks, so let's check operation existence.
Bruno