The intention here is: "if show_text_glyphs is unsupported,
try show_gyphs". We need to make sure to set the status to
unsupported before checking it, otherwise we end up looking
at the status that was set by composite_color_glyphs if
show_text_glyphs is NULL.
This showed up in https://github.com/harfbuzz/harfbuzz/issues/2675
Add a _cairo_tag_error(fmt, ...) function that is used liked _cairo_error()
but allows an error message to be specified. When CAIRO_DEBUG_TAG is defined
the error is printed.
This allows all objects that were previously emitted uncompressed to
be compressed into a an object stream.
Currently only /Page, /Pages, and /Catalog have been converted to use
object streams.
On 64-bit windows, long is 32-bit. When compiling there are a large
number of warnings about mismatched sizes when casting long to/from a
pointer.
Use the (u)intptr_t type for any integer that will have a pointer stored
in it. Use a (u)intptr_t cast when integers are stored in pointers to
silence warnings.
Fixes#263
Commit 2fbd53 added another test to create-for-stream that failed for
cairo-pdf. Manual testing shows that this test also fails for cairo-svg.
However, this was not noticed because even before this addition to the
test, create-for-stream already failed for cairo-svg. Since the
introduction on CI was done based on "let's ignore all current
failures", this hid the error.
This commit applies the trivial fix for cairo-svg to make this test
pass. It is basically the same error that cairo-pdf had.
Additionally, this removes the hack to ignore create-for-stream failures
in CI since it is now no longer necessary.
Thanks to Knut Peterson for reporting this [0].
[0]:
https://lists.cairographics.org/archives/cairo/2021-July/029291.html
Signed-off-by: Uli Schlachter <psychon@znc.in>
Previously, forward references were required to use named destinations.
This patch is based on the patch in #336 by Guillaume Ayoub <guillaume.ayoub@kozea.fr>
that converted all links to indirect objects written at the end of the document.
I have reworked the patch so that only forward references to future page numbers are
written as indirect objects. Backward references and named destinations remain as they
are. This is to minimize the number of objects written to the PDF file.
Fixes#336
cairo-pdf was silently ignoring write errors in
_cairo_pdf_surface_finish(). Any write errors that happened here ended
up setting a "status" variable, but the value in this variable was then
unused.
This commit fixes this bug by passing this error on to the caller.
Additionally, this also adds a test case for this behaviour based on
writing to /dev/full. This file is non-standard and thus the test first
checks that this file exists and is writable before trying to write to
it.
This bug was found based on a report from Knut Petersen [0].
[0]: https://lists.cairographics.org/archives/cairo/2021-July/029281.html
Signed-off-by: Uli Schlachter <psychon@znc.in>
When strtod cannot do anything, it returns zero and sets the end pointer
to the beginning of the string. This commit changes the code in
parse_float() to treat this case as an error.
Without the fix from commit b7d67433b7, this commit turns the error
from an endless loop into a parse error, which is a lot better error
behaviour.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The function cairo_cff_font_read_cid_fontdict() has a local variable
"cairo_array_t index". This array is first filled with data from the
font with cff_index_read(). Later in this function, each resulting entry
is given to cff_dict_read(). Nothing else is done with the array.
Thus, nothing can keep a reference to "index" and thus this array has to
be finalised at the end of the function to avoid a memory leak.
This commit does that by falling through to the call to cff_index_fini()
that is already there in the error case. This function checks for each
element if its ->is_copy is true and then frees the data. However,
cff_index_read() only creates elements with ->is_copy = FALSE, thus this
does not do anything. At the end, this calls _cairo_array_fini() which
frees the array's memory.
Fixes the following memory leak according to valgrind:
24 bytes in 1 blocks are definitely lost in loss record 173 of 490
at 0x48386AF: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x483ADE7: realloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x4A5ECC3: _cairo_array_grow_by (cairo-array.c:115)
by 0x4A5EEEE: _cairo_array_allocate (cairo-array.c:317)
by 0x4A5EE95: _cairo_array_append_multiple (cairo-array.c:288)
by 0x4A5EE6B: _cairo_array_append (cairo-array.c:265)
by 0x4AFB12E: cff_index_read (cairo-cff-subset.c:438)
by 0x4AFC280: cairo_cff_font_read_cid_fontdict (cairo-cff-subset.c:1022)
by 0x4AFCD42: cairo_cff_font_read_top_dict (cairo-cff-subset.c:1232)
by 0x4AFD145: cairo_cff_font_read_font (cairo-cff-subset.c:1351)
by 0x4AFFDC0: cairo_cff_font_generate (cairo-cff-subset.c:2583)
by 0x4B00D71: _cairo_cff_subset_init (cairo-cff-subset.c:2975)
Fixes: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=30650
Signed-off-by: Uli Schlachter <psychon@znc.in>
