This mostly reverts commit 987dc52160
(with some conflicts fixed as the file got further touched).
This table was already properly aligned as what matters is the generated
INSTALL file, which is what will end up in our source tarballs. This
file is also published on the developer website. The reverted commit was
completely breaking the formatting. 😅
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.
From the horse's mouth:
"WARNING: appstream-glib is heavy maintenance mode, use appstream
instead"
Additionally, appstream-glib no longer conforms fully to the
appstream specification.
Some care is taken to taken to support both libappstream 1.0 as well
as libappstream 0.16.x to support stable distros.
Thanks to lazka and the whole MSYS2 project for adding this package to
their repository so that we don't need ugly special-casing anymore.
See: e515fe48bc
It looks like packagers have regular issues with this support. Also I
added info about the fact we also support JPEG2000-in-HEIF (HEJ2) now.
And I made clearer that there may be other encoders/decoders possible
for a given format (though for AV1, we have a clear AOM preference in
our code).
Finally I add info about an environment variable which may be useful
probably in cases when the run prefix differs from the build prefix.
Cf. a case which was recently happening in the Snap package.
See: https://github.com/snapcrafters/gimp/issues/390
Per the (quite off-topic) discussion in #12772, the fact it's quite
broken on Windows, apparently not too maintained anymore and its syntax
clashes with gi-docgen syntax…
* Don't mention 2.99 anymore.
* GIMP_PKGCONFIG_VERSION was actually the version of libgimp regarding
our .pc file, not our pkg-config requirement (per the commit removing
autotools scripts). Now it looks like our pkg-config minimum
requirement used to be version 0.16, but I didn't add this check back.
Let's assume just saying "a recent version" in the INSTALL file is
enough, without hard-check in meson.
* Simplify the end part about failed configuration or optional features,
with a link to our build tutorial online instead of getting into
details and advices to set LDFLAGS or CPPFLAGS (which to be fair, am
not sure are very good advices at all in fact!).
* Fix a few more details.
There are needed at build time because we run various Python scripts
through GIMP, and we made the Python 3 plug-ins non-optional now.
Thanks to Bruno for noticing this needed to be updated in INSTALL.
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.
