Adds include of <sys/wait.h> if system has it, in order to fix:
../test/pdf-structure.c: In function ‘check_pdf’:
../test/pdf-structure.c:551:21: error: implicit declaration of function
‘WIFEXITED’ [-Wimplicit-function-declaration]
551 | WIFEXITED (ret) ? WEXITSTATUS (ret) : -1);
| ^~~~~~~~~
../test/pdf-structure.c:551:39: error: implicit declaration of function
‘WEXITSTATUS’ [-Wimplicit-function-declaration]
551 | WIFEXITED (ret) ? WEXITSTATUS (ret) : -1);
| ^~~~~~~~~~~
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
test/meson.build:663: WARNING: Project targets '>= 1.3.0' but uses feature deprecated since '0.64.0': copy arg in configure_file. Use fs.copyfile instead
- If a link has both 'dest' and 'uri', the 'dest' will be used if it
exists, otherwise it will fallback to using the 'uri'.
- Ensure that a missing 'dest' does not result in an error. Instead a
warning is printed if CAIRO_DEBUG_TAG is set, and a link to the
current location is embedded in the PDF. ie the link does
nothing. Cairo needs to embed a link even if no destination is
available because when links are embedded at the end of the
document, the content stream already contains link tags.
- Remove cairo_pdf_interchange_write_forward_links. This code was
originally used prior to !463 when cairo wrote the links at the end
of each page. Now the links are written at the end of the document
so there are no longer any forward links with an unknown
destination, unless the destination does not exist.
- When 'internal' is not used, use the 'dest' name to reference the
link. Ensure non ASCII names are correctly encoded.
Specially important for font variations, which before did not
work in PDF, etc, output.
Script surface is not updated. It seems out of date with all
recent additions to cairo_font_options_t, so it loses the
variations :(.
Fixes https://gitlab.freedesktop.org/cairo/cairo/-/issues/819
Traditionally, loading a malformed PNG file with
cairo_image_surface_create_from_png() resulted in
CAIRO_STATUS_NO_MEMORY. This was apparently changed in commit
c5ee3f11b5 by adding CAIRO_STATUS_PNG_ERROR and using it for errors
returned from libpng. However, I don't see how this was supposed to
actually work.
There are a couple of error codes supported by
_cairo_surface_create_in_error(). Anything else is turned into
CAIRO_STATUS_NO_MEMORY, which is not a helpful status. For this reason,
CAIRO_STATUS_PNG_ERROR would be turned into CAIRO_STATUS_NO_MEMORY.
This commit adds support for CAIRO_STATUS_PNG_ERROR to
_cairo_surface_create_in_error() so that this error can actually be
returned to the caller.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This test creates surfaces and patterns that it never cleans up. Found via
running:
CAIRO_TEST_TARGET=image valgrind --leak-check=full ./cairo-test-suite -f bug-431
Output before this commit:
==21310==
==21310== HEAP SUMMARY:
==21310== in use at exit: 569,788 bytes in 26 blocks
==21310== total heap usage: 1,523 allocs, 1,497 frees, 2,034,252 bytes allocated
==21310==
==21310== 336 bytes in 2 blocks are definitely lost in loss record 5 of 17
==21310== at 0x48407B4: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==21310== by 0x48BE2B0: _cairo_pattern_create_solid (cairo-pattern.c:614)
==21310== by 0x48BE4B1: cairo_pattern_create_rgba (cairo-pattern.c:720)
==21310== by 0x1358C6: draw (bug-431.c:50)
==21310== by 0x129EDB: cairo_test_for_target (cairo-test.c:938)
==21310== by 0x12B36A: _cairo_test_context_run_for_target (cairo-test.c:1545)
==21310== by 0x12C370: _cairo_test_runner_draw (cairo-test-runner.c:258)
==21310== by 0x12DEA0: main (cairo-test-runner.c:962)
==21310==
==21310== 278,534 (144 direct, 278,390 indirect) bytes in 1 blocks are definitely lost in loss record 15 of 17
==21310== at 0x48407B4: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==21310== by 0x48BE51E: cairo_pattern_create_for_surface (cairo-pattern.c:756)
==21310== by 0x135838: draw (bug-431.c:41)
==21310== by 0x129EDB: cairo_test_for_target (cairo-test.c:938)
==21310== by 0x12B36A: _cairo_test_context_run_for_target (cairo-test.c:1545)
==21310== by 0x12C370: _cairo_test_runner_draw (cairo-test-runner.c:258)
==21310== by 0x12DEA0: main (cairo-test-runner.c:962)
==21310==
==21310== 278,534 (144 direct, 278,390 indirect) bytes in 1 blocks are definitely lost in loss record 16 of 17
==21310== at 0x48407B4: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==21310== by 0x48BE51E: cairo_pattern_create_for_surface (cairo-pattern.c:756)
==21310== by 0x488274D: _cairo_default_context_set_source_surface (cairo-default-context.c:327)
==21310== by 0x49063DB: cairo_set_source_surface (cairo.c:977)
==21310== by 0x1AC1DD: _cairo_boilerplate_get_image_surface (cairo-boilerplate.c:337)
==21310== by 0x12A486: cairo_test_for_target (cairo-test.c:1145)
==21310== by 0x12B36A: _cairo_test_context_run_for_target (cairo-test.c:1545)
==21310== by 0x12C370: _cairo_test_runner_draw (cairo-test-runner.c:258)
==21310== by 0x12DEA0: main (cairo-test-runner.c:962)
==21310==
==21310== LEAK SUMMARY:
==21310== definitely lost: 624 bytes in 4 blocks
==21310== indirectly lost: 556,780 bytes in 16 blocks
==21310== possibly lost: 0 bytes in 0 blocks
==21310== still reachable: 12,384 bytes in 6 blocks
==21310== suppressed: 0 bytes in 0 blocks
==21310== Reachable blocks (those to which a pointer was found) are not shown.
==21310== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==21310==
==21310== For lists of detected and suppressed errors, rerun with: -s
==21310== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 0 from 0)
Signed-off-by: Uli Schlachter <psychon@znc.in>
A scaled font contains font options. Since commit 67eeed44, this can
contain an extra allocation for a custom palette. Since commit
edf9497c3a, this contains an extra allocation for a string. Before these
commit, font options could just be dropped, but now they need to be
freed.
This commit makes the relevant code for creating and finishing scaled
fonts also clean up the font options.
The test added in the previous commit also hits this bug (I only found
these leaks accidentially!). Running "valgrind --leak-check=full
./cairo-test-suite -f leaks-set-scaled-font" no longer reports the following
after this change:
40 bytes in 1 blocks are definitely lost in loss record 1 of 11
at 0x48407B4: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x4886C62: _cairo_font_options_init_copy (cairo-font-options.c:105)
by 0x48DAFFB: _cairo_scaled_font_init_key (cairo-scaled-font.c:675)
by 0x48DC077: cairo_scaled_font_create (cairo-scaled-font.c:1096)
by 0x15BF08: leaks_set_scaled_font (leaks.c:43)
by 0x129EF0: cairo_test_for_target (cairo-test.c:938)
by 0x12B37F: _cairo_test_context_run_for_target (cairo-test.c:1545)
by 0x12C385: _cairo_test_runner_draw (cairo-test-runner.c:258)
by 0x12DEB5: main (cairo-test-runner.c:962)
40 bytes in 1 blocks are definitely lost in loss record 2 of 11
at 0x48407B4: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x4886C62: _cairo_font_options_init_copy (cairo-font-options.c:105)
by 0x49337BB: _cairo_ft_font_face_scaled_font_create (cairo-ft-font.c:2073)
by 0x48DC340: cairo_scaled_font_create (cairo-scaled-font.c:1176)
by 0x15BF08: leaks_set_scaled_font (leaks.c:43)
by 0x129EF0: cairo_test_for_target (cairo-test.c:938)
by 0x12B37F: _cairo_test_context_run_for_target (cairo-test.c:1545)
by 0x12C385: _cairo_test_runner_draw (cairo-test-runner.c:258)
by 0x12DEB5: main (cairo-test-runner.c:962)
40 bytes in 1 blocks are definitely lost in loss record 3 of 11
at 0x48407B4: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x4886C62: _cairo_font_options_init_copy (cairo-font-options.c:105)
by 0x48DB280: _cairo_scaled_font_init (cairo-scaled-font.c:742)
by 0x4933804: _cairo_ft_font_face_scaled_font_create (cairo-ft-font.c:2076)
by 0x48DC340: cairo_scaled_font_create (cairo-scaled-font.c:1176)
by 0x15BF08: leaks_set_scaled_font (leaks.c:43)
by 0x129EF0: cairo_test_for_target (cairo-test.c:938)
by 0x12B37F: _cairo_test_context_run_for_target (cairo-test.c:1545)
by 0x12C385: _cairo_test_runner_draw (cairo-test-runner.c:258)
by 0x12DEB5: main (cairo-test-runner.c:962)
Signed-off-by: Uli Schlachter <psychon@znc.in>
cairo_gstate_t contains a cairo_font_options_t. Since commit 67eeed44,
this can contain an extra allocation for a custom palette. Since commit
edf9497c3a, this contains an extra allocation for a string. Before these
commit, font options could just be dropped, but now they need to be
freed.
This commit makes _cairo_gstate_fini() finish the font options to free
the memory allocation.
The new test was run via "valgrind --leak-check=full ./cairo-test-suite
-f leaks-set-scaled-font". The following reported leak goes away thanks
to this commit:
1,040 bytes in 26 blocks are definitely lost in loss record 6 of 12
at 0x48407B4: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x4886C62: _cairo_font_options_init_copy (cairo-font-options.c:105)
by 0x488C029: _cairo_gstate_set_font_options (cairo-gstate.c:1757)
by 0x48841D7: _cairo_default_context_set_scaled_font (cairo-default-context.c:1310)
by 0x490809A: cairo_set_scaled_font (cairo.c:3318)
by 0x15BF1F: leaks_set_scaled_font (leaks.c:45)
by 0x129EF0: cairo_test_for_target (cairo-test.c:938)
by 0x12B37F: _cairo_test_context_run_for_target (cairo-test.c:1545)
by 0x12C385: _cairo_test_runner_draw (cairo-test-runner.c:258)
by 0x12DEB5: main (cairo-test-runner.c:962)
Fixes: https://gitlab.freedesktop.org/cairo/cairo/-/issues/795
Signed-off-by: Uli Schlachter <psychon@znc.in>
The ctype(3) character classification and mapping functions have a
peculiarly limited definition (C11, Sec. 7.4 `Character handling
<ctype.h>', p. 200):
`The header <ctype.h> declares several functions useful for
classifying and mapping characters. In all cases the
argument is an int, the value of which shall be
representable as an unsigned char or shall equal the value
of the macro EOF. If the argument has any other value, the
behavior is undefined.'
In other words, in the most common case of 8-bit char and EOF = -1,
the domain of the 257 allowed arguments is:
-1, 0, 1, 2, ..., 254, 255
The ctype(3) functions are designed for use with stdio functions like
getchar and fgetc which return int values in the same domain.
In an ABI where char is signed (e.g., x86 SysV ABI used by most
Unixish operating systems), passing an argument of type char as is
can go wrong in two ways:
1. The value of a non-EOF input octet interpreted as `char' may
coincide, as an integer, with the value of EOF, leading to wrong
answers for some non-EOF inputs.
E.g., if EOF = 1, and an input octet has all bits set, i.e., 255
as an unsigned char, then as a char the value is -1, which will be
confused with EOF. In the ISO-8859-1 locale, the code point 255
is (in Unicode terminology) LATIN SMALL LETTER Y WITH DIAERESIS,
for which isprint, isalpha, &c., are true. But isprint, isalpha,
&c., are false for EOF. So if char *s points to a string with
that character, isprint(*s) will return false when it should
return true.
2. Passing a negative char whose value does not coincide with EOF is
undefined behaviour.
This isn't purely theoretical: often the functions are implemented
by an array lookup, #define isprint(c) (ctypetab[c] & ISPRINT).
If c is out of range (e.g., 192, ISO-8859-1 for LATIN CAPITAL
LETTER A WITH GRAVE, which convers to (signed) char as -64), then
you can get garbage answers by reading uninitialized memory or
application crashes with SIGSEGV if the page preceding the table
is unmapped.
If what you have is an arbitrary char (e.g., from a char * string
pointing at user input), then the only correct way to use the
ctype(3) functions is by converting to unsigned char first -- e.g.,
isprint((unsigned char)*s). (If the functions were defined as macros
that convert to unsigned char first, they would then spuriously
interpret EOF as a non-EOF, so they can't do that themselves.)
It is possible, in some cases, to prove that the input always
actually lies in {0, 1, 2, ..., 127}, so the conversion to unsigned
char is not necessary. I didn't check whether this was the case --
it's safer to just adopt the habit of always casting char to unsigned
char first before using the ctype(3) macros, which satisfies a
compiler warning on some systems designed to detect this class of
application errors at compile-time.
The code is doing "if (!double_buf_equal () != 0)" which seems to be a
convoluted way to do "if (!double_buf_equal ())". Fixes:
../test/pattern-getters.c:153:6: warning: logical not is only applied to the left hand side of this comparison [-Wlogical-not-parentheses]
if (!double_buf_equal (ctx, new_buf, expected_values,
^
../test/pattern-getters.c:153:6: note: add parentheses after the '!' to evaluate the comparison first
if (!double_buf_equal (ctx, new_buf, expected_values,
^
(
../test/pattern-getters.c:153:6: note: add parentheses around left hand side expression to silence this warning
if (!double_buf_equal (ctx, new_buf, expected_values,
^
(
../test/cairo-test-runner.c:730:48: warning: parameter 'str' set but not used [-Wunused-but-set-parameter]
_has_required_ghostscript_version (const char *str)
This implements Type 3 color fonts for PDF for any font with a
CAIRO_SCALED_GLYPH_INFO_RECORDING_SURFACE. This includes user-fonts,
SVG fonts, and COLR fonts.
Glyphs with foreground colors are not yet implemented as Type 3 glyphs
and will be rendered as images by cairo-surface.
The GL support in Cairo has always been a prototype, and
nothing happened in the past 10+ years to make it work as
it was meant to.
GL support is not enabled by any downstream packagers of
Cairo, so nobody should notice its absence.
