The cairo-boilerplate static library cannot use private API defined in
the main Cairo shared library, because it has no access to those
symbols.
Since the code is small, we can just dump it into the boilerplate
library.
The original "slim" symbol rewriting was added without any shred of a
set of performance evaluation, and mostly copy-pasted from a very early
version of pixman. Pixman itself never used them, and most C
libraries—like GLib and GTK—have dropped similar mechanisms over the
past 15 years, as linkers have improved considerably in the meantime.
Modern linkers provide functionality to avoid intra-library PLT jump
through flags like `-Bsymbolic-functions`; we should use that, instead,
and keep the code base more maintainable and debuggable.
Andreas Falkenhahn reported the issue below and indicated that the color
channels are swapped. This commit fixes the byte swap.
The problem is that be32_to_cpu() is a no-op on big endian systems.
However, we also have a bswap_32() function available that always works.
Testing done: None by me, but Andreas Falkenhahn reported that his patch
fixes colors on a PowerPC system.
Fixes: https://gitlab.freedesktop.org/cairo/cairo/-/issues/787
Signed-off-by: Uli Schlachter <psychon@znc.in>
Commit f6a3f6d8ad
"Don't build fontconfig on Windows" made an attempt to prevent Meson
from automatically building Fontconfig as a subproject on Windows when
the 'fontconfig' option has its default value of 'auto'.
Unfortunately, this only made things worse instead of fixing them.
Meson feature options can have three states: 'enabled', 'auto', and
'disabled'. They are primarily intended to be used as a value for the
'required' option of the 'dependency()' function. When the system
dependency is not found, but a fallback subproject is provided
explicitly with the 'fallback' option, a feature option in the 'auto'
state still causes the subproject to get built.
Since there's no apparent way to produce a value of the "feature option
object" type in a specific state, commit f6a3f6d8ad instead
set fontconfig_option = false (when it wasn't set to 'enabled', i.e. it
was either 'auto' or 'disabled') in an attempt to disable building the
subproject. However, a boolean value of false is equivalent to 'auto',
not to 'disabled'. This is documented at
https://mesonbuild.com/Build-options.html#features
So commit f6a3f6d8ad wanted to convert
'auto' to 'disabled', but instead effectively converted 'disabled' to
'auto', causing the Fontconfig subproject to be always built on Windows,
even when explicitly turned off with -D fontconfig=disabled.
A way to accomplish the original goal is available since Meson 0.59;
feature option objects gained the '.disable_auto_if()' method that
exactly converts 'auto' to 'disabled' if the boolean condition is true.
So make use of this method to properly turn off building Fontconfig on
Windows, unless explicitly enabled with -D fontconfig=enabled.
Apply the same for FreeType, which is also not very useful on Windows.
See also: 7f8135bfeb
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
When trying to build with -Dpng=disabled with a new enough FreeType
version, the build would fail in cairo-svg-glyph-renderer.c:
src/cairo-svg-glyph-render.c:1841:15: error: implicit declaration of
function ‘cairo_image_surface_create_from_png_stream’; did you mean
‘cairo_image_surface_create_for_data’?
[-Werror=implicit-function-declaration]
Fix this by disabling HAVE_FT_SVG_DOCUMENT when png is not enabled.
Fixes: https://gitlab.freedesktop.org/cairo/cairo/-/issues/784
Signed-off-by: Uli Schlachter <psychon@znc.in>
This was found while debugging why The Twemoji Mozilla
font renders a white-on-while in pango.
We need to call _render_glyph_bitmap, since we want
FT_Render_Glyph to handle the COLRv0 layers for us.
