Using NULL is encouraged for pointers. While fixing that, it turned out
that the comments indicating the current index were wrong, so I'm fixing
them too.
Don't hardcode Valgrind flags in tests/Makefile.am so that
tests/Makefile doesn't need to be rebuilt to use different flags. Not
everybody is looking for memory leaks.
The ChangeLog.pre-* files once generated, cannot be outdated and don't need
update anymore, but the main ChangeLog needs update everytime a git operation
is performed (commit, checkout, etc.) Previously, we were forcing a ChangeLog
recreation by making it a phony target. Now, we break it into two parts: One
up to the latest tag (as returned by git-describe), and another from there.
The former is, again, up-to-date when it exists. The latter, we make it
depend on .git. And since the latter is pretty short anyway, you get a very
first regeneration of it when you change your repo (and that only happens
during 'make dist' by the way.)
For an imaginary cairo-3.6.4 version, we now will generate the following
ChangeLog files:
ChangeLog
ChangeLog.pre-3.4
ChangeLog.pre-3.2
ChangeLog.pre-3.0
ChangeLog.pre-2.0
ChangeLog.pre-1.0
This is useful to review every once in a while to drop duplicate images that
can be dropped. For example, if there are two identical images one named
some-test-svg-rgb24-ref.png and other some-test-svg-argb32-ref.png, those two
can be replaced with some-test-svg-ref.png.
This causes configure to check for libz even if PS/PDF are disabled
or their results is already cached. But that's not much of a problem
as if the cache is enabled, libz results are cached too.
such that removing config.cache is not needed as frequently as it
is currently. We just detect and stale the cache results for our
own backends. If the user installs missing libraries, they still
need to remove the cache manually.
Note that everytime a change is made to configure.in and may change
the results of at least one CAIRO_BACKEND_ENABLE call, the
cairo_cache_version number should be increased.
if we don't want it. This stuff is tricky, but I hope to explain: In your
fontconfig configuration, you may match on "font", or on "pattern". Turning
subpixel on typically looks like:
<match target="font">
<test qual="all" name="rgba">
<const>unknown</const>
</test>
<edit name="rgba" mode="assign"><const>rgb</const></edit>
</match>
This works good enough, and if you set to ANTIALIAS_GRAY, this will not
override that. Now one may forget to match on "font" target, or intentionally
match on the pattern. That happens before cairo font options are substituted
in the pattern. So, to give a hint of subpixel in your config file, you can
write:
<match target="pattern">
<edit name="rgba" mode="assign"><const>rgb</const></edit>
</match>
You don't really need to check for current values, as FcConfigSubstitute is
run before merging cairo_font_options_t in. What this patch does, is to reset
pattern's rgba property if the font options explicitly ask for ANTIALIAS_GRAY.
This is the only place in cairo-ft-font.c that we use FcPatternDel, so I
thought some explanation is needed.
otherwise, it looks like "I don't care" and fontconfig configuration is
allowed to decide to turn subpixel on. This fixes the bug that subpixel
colors where showing up in fallback images in PS/PDF/SVG backends, observed
in the test fallback-resolution.
This only affects the image fallback in those backends, and avoids getting
colored pixels there if user's fontconfig configuration turns subpixel on.
This doesn't quite fix that problem though, more changes are needed/coming.
