In a couple of instances, code is present where two numbers are being
multiplied in a type like unsigned int, but immediately being casted
to a wider type like size_t.
This means, although the result can be any size_t value, the
multiplication can potentially overflow before it's used because
unsigned int has a smaller range of values.
In another more niche case, I also cast to size_t before multiplying
a signed integer, since the result is immediately used as an argument
to memcpy, which would give memory corruption if the value was negative
anyway.
The documentation for cairo_font_options_status says it can return
either CAIRO_STATUS_SUCCESS or CAIRO_STATUS_NO_MEMORY, but the
implementation can also return CAIRO_STATUS_NULL_POINTER, which wasn't
mentioned.
In some places, there were int variables being compared to unsigned
ints when they would never take a negative value, exposing some edge
cases that didn't need to be there.
cairo-script has a special case for drawing a set of rectangles. The
rectangle detection can trip over a "degenerate rectangle": Just a
horizontal line. It detects the line as the beginning of a rectangle and
then claims CAIRO_STATUS_INVALID_PATH_DATA when the other sides of the
rectangle are missing.
This commit simply changes the return value to
CAIRO_INT_STATUS_UNSUPPORTED to trigger a fallback to the generate case.
Test case is a straight-forward adaption from the original bug report.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Fixes: https://gitlab.freedesktop.org/cairo/cairo/-/issues/535
When rendering clusters that have colored and non-colored
glyphs, we were falling back to using show_text_glyphs,
rendering all glyphs in the cluster without color.
Instead, make composite_one_color_glyph smart enough
to handle non-color glyphs, and only skip clusters
that are entirely non-color.
Testcase: hb-view AmiriQuranColored.otf -u 627,64e
When the run contains a mix of color and non-color
glyphs, composite_color_glyphs returns the non-color
glyphs unhandled in the same array. In the rtl case,
the glyphs are processed from the end and the unhandled
glyphs are accumulated at the end as well, and we
need to move them to the beginning of the array before
we return. Add the missing memmove call to do that.
Fixes: #533
Symbols from cairo-tag-stack.c are used by cairo-tag-attributes.c, so
this should be in the same list of sources as that. Fixes this build
error:
```
/usr/bin/ld: src/libcairo.so.2.11705.0.p/cairo-tag-attributes.c.o: in function `parse_array':
/path/to/cairo/_build/../src/cairo-tag-attributes.c:347: undefined reference to `_cairo_tag_error'
/usr/bin/ld: src/libcairo.so.2.11705.0.p/cairo-tag-attributes.c.o: in function `parse_name':
/path/to/cairo/cairo/_build/../src/cairo-tag-attributes.c:359: undefined reference to `_cairo_tag_error'
/usr/bin/ld: src/libcairo.so.2.11705.0.p/cairo-tag-attributes.c.o: in function `parse_attributes':
/path/to/cairo/cairo/_build/../src/cairo-tag-attributes.c:410: undefined reference to `_cairo_tag_error'
/usr/bin/ld: /path/to/cairo/cairo/_build/../src/cairo-tag-attributes.c:431: undefined reference to `_cairo_tag_error'
/usr/bin/ld: /path/to/cairo/cairo/_build/../src/cairo-tag-attributes.c:441: undefined reference to `_cairo_tag_error'
/usr/bin/ld: src/libcairo.so.2.11705.0.p/cairo-tag-attributes.c.o:/path/to/cairo/cairo/_build/../src/cairo-tag-attributes.c:455: more undefined references to `_cairo_tag_error' follow
/usr/bin/ld: src/libcairo.so.2.11705.0: hidden symbol `_cairo_tag_error' isn't defined
```
This commit fixes the following warning from our check-def.sh:
PASS: check-def.sh
Checking documentation for incorrect syntax
./cairoint.h (523): ERROR: Get invalid doc id (should be 'cairo_...:')
./cairoint.h (534): ERROR: Get bad line: ' */'
./cairoint.h (534): ERROR: Get documentation comment not closed with **/
Signed-off-by: Uli Schlachter <psychon@znc.in>
This commit copies clip-unbounded.base.rgb24.ref.png to
clip-unbounded.rgb24.ref.png. This makes the test pass for rgb24
targets.
This failure goes back to commits 6647511 / 049060 which changed the
image comparison in the test suite. Previously, transparent "nothing"
and black compared equal, but said commits fixed that. Thus, having a
special reference image with black instead of transparency is the right
fix.
Signed-off-by: Uli Schlachter <psychon@znc.in>
PDF output uses q/Q operators to reset the clip path. This also resets
the PDF graphics state including the current blend mode.
When resetting the clip path, reset the current blend mode tracked by
the PDF surface so that if a non-default blend mode is required, the
surface will emit the correct blend mode.
Fixes#514
The expression "1 << whatever" has type int, no matter what the type of
"whatever" is. Thus, "1 << 31" ends up overflowing an "int" and
undefined behaviour occurs.
The above happened in cairo-mempool.c. I saw the following line:
pool->free_bytes += 1 << (bits + pool->min_bits);
being executed with bits=15 and pool->min_bits=16, i.e. we had 1 << 31.
This ended up being INT_MIN due to the overflow. This was then promoted
to size_t and we ended up with a *huge* value being added to free_bytes.
This is obviously not the intended behaviour. Thus, this commit replaces
the "1" in all left shifts in cairo-mempool.c with "((size_t) 1)".
This fix avoids the integer overflow, but it does not fix issue #510,
because some allocation keeps the memory pool alive.
Related-to: https://gitlab.freedesktop.org/cairo/cairo/-/issues/510
Signed-off-by: Uli Schlachter <psychon@znc.in>
The FT change is because my MinGW build is using a more recent version
of FT.
Remove the disabled _cairo_win32_scaled_font_text_to_glyphs() code to
fix the defined but not used warning.
_cairo_win32_scaled_font_text_to_glyphs() was diabled in d9408041aa with
the comment:
"Currently disable the win32-font text_to_glyphs(), until that one
is updated. Or better yet, remove it and implement
ucs4_to_index(). It's the toy font API afterall."
_cairo_win32_scaled_font_ucs4_to_index() was added in d1c619bc7d.
