The _GNU_SOURCE macro needs to be defined first, (so that now included
file includes any C library header (such as stdio.h) without this
definition in place. Without this fix, "make check" in the perf
directory would fail.
In order to be consistent with the semantics of cairo_arc() using a
radius of 0 should simply degenerate into a line-to.
Reported-by: Benjamin Berg
(cherry picked from commit a0ea0b63fd)
Type 1 fonts embedded in PDF may omit the fixed-content portion of the
font that contains the "cleartomark" operator.
(cherry picked from commit cee3a6169b)
Type 1 fonts embedded in PDF have the the encrypted portion in binary
but the existing check for binary only works for Type 1 fonts in PFB
format.
Add an additional check based on the first 4 characters of eexec data.
The Type 1 specification gurantees that at least one of the first 4
bytes of ciphertext is not an ASCII Hex character.
(cherry picked from commit ac59c75808)
At the end of the private dictionary a new line is appended so that
the trailing zeros will not exceed 80 columns. In hex mode (used for
PS embedding) extra white space is harmless as it is ignored when
parsing the ascii hex encoded data. But in binary mode (used for PDF
embedding) the new line must not be added as it corrupts the binary
data.
https://bugs.launchpad.net/ubuntu/+source/cups/+bug/419143
(cherry picked from commit a4a59be600)
Cairo should include the contents of subwindows when using a Window as a
source but will clip to subwindows when using a Window as a destination.
This can be set using the GC's subwindow_mode.
XCopyArea and XFillRectangle can however only use one GC for both source
and destination. Cairo's mode is set to (the default) ClipByChildren.
This means that copying from a Window is broken, so we only allow the
optimization when we know that the source is a Pixmap.
The performance impact of this change has not been tested. It should be
small, as the code will use XRender otherwise.
If it turns out to be a bigger impact, the optimizations could be
improved by doing a two-step copy process:
1) Copy to an intermediate Pixmap with IncludeInferiors
2) Copy to the destination with ClipByChildren
(potentially omitting one one of the steps if source or destination are
known to be Pixmaps).
references:
commit 0c5d28a4e5https://bugs.freedesktop.org/show_bug.cgi?id=12996
Bug 23067 -- using clear drawing operator crashes printing
http://bugs.freedesktop.org/show_bug.cgi?id=23067
Here we were hitting an assert within the paginated surface after creating
a zero sized fallback image, due to the paginated surface being created
with an x fallback resolution of 0 dpi (by
_gtk_printer_create_cairo_surface(), gtk/gtkprinter.c:924).
Avoid the bug by guarding against bad input to
cairo_surface_set_fallback_resolution() which also allows us to identity
the invalid caller.
We need to translate the path in order to compensate for the device offset
applied to the group surface when pushing and popping. (The path is
transformed to device space on creation, and so needs recomputing for the
new device.)
When cairo_curve_to happens to start a new subpath (e.g., after a call
to cairo_new_sub_path()), it also needs to update the last_move_point.
Otherwise the new current point after a close_path() will be at an
unexpected position.
Therefore, call _cairo_path_fixed_move_to() explicitly.
If GetGlyphOutlineW(GGO_METRICS) fails to retreive the metrics for the
specified glyph it returns GDI_ERROR. Like ft, do not interpret this as a
fatal error but just mark the glyph as empty.
Fixes http://bugs.freedesktop.org/show_bug.cgi?id=20255
Bug 20255 -- cairo_scaled_font_glyph_extents breaks with invalid glyph id
_font_map_release_face_lock_held() was being called unconditionally during
_cairo_ft_font_reset_static_data(). This presents two problems. The first
is that we call FT_Done_Face() on an object not owned by cairo, and the
second is that the bookkeeping is then incorrect which will trigger an
assert later.
As reported in https://bugs.freedesktop.org/show_bug.cgi?id=19283, the
fallback freetype version compare is broken inside the configure script as
the $1-$3 arguments are interpreted as the script is constructed. To avoid
making that awk comparison any more complicated, we import a version compare
from the autoconf archives - such that we have a reusable macro for the
furture.
Bug 21706 -- zombie ft_font_face / ft_unscaled_font mutual
referencing problems
[http://bugs.freedesktop.org/show_bug.cgi?id=21706]
There can be more than one zombie font_face belonging to an unscaled_font,
but only the first is destroyed. This leaks the client's FT_Face
(and associated font data) as release of the FT_Face depends on release
of the font_face.
(The reason why Firefox ends up with two different font_faces for one
unscaled_font is that load_flags for faces with artificial oblique have
FT_LOAD_NO_BITMAP set.
https://bugzilla.mozilla.org/show_bug.cgi?id=486974)
Also it's possible for _cairo_ft_font_face_create to pull out a zombie
font_face from the unscaled_font, which would crash
_cairo_ft_font_face_scaled_font_create, as that expects non-null
font_face->unscaled (if !font-face->pattern).
Truc Troung reported that the behaviour of
cairo_set_tolerance()/cairo_get_tolerance() was inconsistent with the
documentation, i.e. we failed to mention that the tolerance would be
restricted to the smalled fixed-point value.
Add a sentence to the documentation that describes the restriction without
mentioning what that is... Hopefully that is sufficient detail to
accommodate the reporter, without exposing internal implementation details.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=20095
Bug 20095 - The cairo_set_tolerance() function behavior is inconsistency
with the spec
As pointed out by Truc Truong,
cairo_image_surface_create_from_png_stream() cannot return NULL and so the
documentation was incorrect.
Fixes http://bugs.freedesktop.org/show_bug.cgi?id=20075
Bug 20075 There is a misprint in the spec for
cairo_image_surface_create_from_png_stream() function
If a matrix was something like [0 .000001 0, .000001 0 0] the old code would
assume that xx and yy were greater than 0 and turn the nearly degenerate matrix
into an actual degenerate one. This caused things to blow up later on. Now we
check that our nearly rectangular matrices are not nearly degenerate, and let
the nearly degenerate ones fall through to the non-rectangular path.
Note: I'm not sure why NEARLY_ZERO(d) is fabs(d) < 1/65536 instead of some
other value. Hopefully, it's a useful definition.
This problem was found by a test case attached to:
https://bugzilla.mozilla.org/show_bug.cgi?id=467423
