* Enable webpng on MINGW
* Detect GD version using cmake language
* Use _aligned_malloc instead of posix_memalign on Windows
* Include missing "errno.h"
* Fix finding WEBP on MINGW
* Fix finding XPM on MINGW
* Use PkgConfig to find packages on MINGW
* CI: Enable more options for MINGW
Demand for AVIF support on the web is growing, as the word gets out
about this new file format which allows higher-quality encoding at
smaller sizes. Core contributors to major open-source CMSs are
interested in auto-generating AVIF images! They've been simply
waiting for support to appear in libgd.
This PR aims to meet the growing demand, and to help bring smaller,
more beautiful images to more of the web - to sites created by
experienced developers and CMS users alike.
This PR adds support by incorporating libavif in addition to the
existing libheif support. It's generally felt that libavif has
more complete support for the AVIF format. libavif is also used
by the Chromium project and squoosh.app.
In this PR, I've endeavored to incorporate the latest research into
best practices for AVIF encoding - not just for default quantizer
values, but also an algorithm for determining the number of
horizontal tiles, vertical tiles, and threads.
Fixes#557.
With the adoption of AVIF by Firefox and Chromium based browsers (still
in experimental phase), the newer incorporation of HEIF by Canon and Sony
in their cameras and the newer support of both of them in modern software
like ImageMagick, GIMP and Krita, `gd` haven't seen any endorsement for
the formats up until this PR.
Reading and writing is done by `libheif`, with functionality for chroma
subsampling (for now `4:2:0`, `4:2:2` and `4:4:4`), quality (with new
`200` for lossless) and compression (whether `HEVC` or `AV1`) selection.
This was tested with `libheif` version `1.11.0` in my Solus machine.
Also, fixes both #395 and #557.
CMake process of generating VS solution and projects fails, because libgd_static target is not visible at this point. This is a fix for this problem.
Fixes#467.
We've been tracking program deps in the build files, so it ends up
being redundant for a lot of our test/example programs. Clean them
up, and update some of the cmake/automake files as needed.
Since getopt is only needed by various helper programs, we start a new
program utility static library to stuff things into so they don't fill
up the gd library itself.
This comes from NetBSD. Fixes#401.
Pull out the library versioning info out of configure and into a common
script that both cmake & autotools can run. This way we have a single
source of truth for the versioning info.
The cmake build was missing gd_color_match.c which meant the library
didn't export the gdImageColorMatch function. Sync the two lists in
the autotools and cmake files to make this easier to check. Listing
header files in autotools source lists isn't a problem.
This makes sure we don't export symbols in libgd.so that we shouldn't.
We now assume that, if you're using gcc, you're using at least version
3.3 as that's the first to support the visibility attribute. We can
wait to see if anyone complains before worrying about older ones.
The standard behavior in distros nowadays is to build shared libs and
omit static libs. Split the build knobs in cmake to support this. It
also matches what's available with the autotools build.
Clean up redundant header logic and focus on what we actually care about:
whether specific headers exist.
Update the program list to omit programs when required libs are not found.
The Makefile.am has no changes other than sorting & unwrapping the files
to make it a bit more readable (and dropping duplicate entries).
The CMakeLists.txt gains a few files that were added recently but left
out of the cmake build.
Closes#183.
* For VS2013 and below, it will compile and additional file `src/snprintf.c`, which contains the fallback implementation. The
function is included with `extern` in other files where required.
* In `src/CMakeLists.txt`, `snprintf.c` is included in sources conditionally; only for
VS2013 and below.
* Note that I have also guarded it with condition inside the `snprintf.c` file, so if any consumer/downstream is not using `cmake` but their own build system (say gyp), this will still prevent them redefining snprintf for VS2015 even if they add `/src/snprintf.c` in to-be-compiled sources unconditionally.