../src/cairo-pdf-surface.c: In function '_cairo_pdf_surface_open_content_stream':
../src/cairo-pdf-surface.c:2537:45: error: format not a string literal and no format arguments [-Werror=format-security]
2537 | str);
| ^~~
cc1: some warnings being treated as errors
The master/slave terms are both inappropriate and inaccurate: the tee
surface replicates the rendering commands from a primary surface to
other surfaces.
This change is a mechanical search-and-replace.
We should default on every platform we care about to hidden symbols, to
avoid leaking private symbols.
On Windows this is the default state of affairs with the MSVC toolchain;
with GCC and GCC-compatible toolchains, we need to opt into this
behaviour. Luckily for us, Cairo already has an annotation for public
symbols, so we can easily tweak it to include the visibility attribute.
When building ancillary libraries as part of the Cairo compilation on
Windows, we use a pre-processor symbol to ensure that we keep the
dllexport annotation. This avoids including the cairoint.h header file.
Fixes: #582
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>
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.
cairo_win32_font_face_create_for_hfont is reusing the HFONT object
passed by an argument if possible to create a scaled font. However,
the condition was wrong. It checked the font matrix scale factor is
`-lfHeight`. But it should be `-lfHeight * WIN32_FONT_LOGICAL_SCALE`.
Fixescairo/cairo#3
As we do already in _cairo_recording_surface_finish. Otherwise, the
cleanup path of _cairo_recording_surface_create_bbtree() could call
free() on surface->bbtree which is not dynamically allocated.
Closes: https://gitlab.freedesktop.org/cairo/cairo/-/issues/645
The following clipping text tests of win32/rgb24 target were visibly
failing because clipping didn't work.
* clip-text
* partial-clip-text-bottom
* partial-clip-text-left
* partial-clip-text-right
* partial-clip-text-top
_cairo_win32_gdi_compositor_glyphs sets the clip. However,
_cairo_dwrite_show_glyphs_on_surface unset it.
Fixescairo/cairo#641
The DWRITE_COLOR_GLYPH_RUN1 struct definition of the old MinGW
dwrite_3.h was invalid. To work around the problem, dw-extra.h defined
the correct struct definition and all necessary API from dwrite_3.h.
This approach needed to redefine all necessary API.
This change added DWRITE_COLOR_GLYPH_RUN1_WORKAROUND struct and use it
for IDWriteColorGlyphRunEnumerator1::GetCurrentRun.
The most top and bottom lines of glyphs were clipped in some fonts and
conditions. The glyph bounds were inflated 1px horizontally. It should
inflate vertically too.
Fixescairo/cairo#569
* Use dx and dy instead of dx1 and dy1 to match with the arguments
* Use dx_new and dy_new instead of dx2 and dy2 to match with other parts of the documentation
* Use xx, yx, xy, yy instead of a, b, c, d to match with other parts of the documentation
* Remove the last two sentences that doesn't make sense
The default RGB colorspace must be converted to the GPU's colorspace
using CGColorTransformConvertUsingCMSConverter. Profiling has shown this
function to consume as much as 48% of a redraw cycle in gdk-quartz.
There seems to be no named colorspace that matches the one stored on the
display, so we use the one associated with the main display. This has
some risks for users with multiple monitors but in testing with my own
two-monitor setup, one of which is HDR and the other not, the colorspace
was the same for both.
This is applied to quartz surfaces created with
cairo_quartz_surface_create(); surfaces created with
cairo_quartz_surface_create_for_cg_context will inherit the colorspace
from the context.
In order to generate PNGs that look right I've converted the
existing debugging functions for writing a quartz surface to png
into private functions and wired cairo-boilerplate-quartz to use
them. Using the generic cairo routine produced washed-out PNGs.
Fixes https://gitlab.freedesktop.org/cairo/cairo/-/issues/330
