A cairo_scaled_font_t can be implicitly shared among multiple threads
as the same cairo_scaled_font_t can be returned from different calls
to cairo_scaled_font_create. To retain the illusion that these
different calls produce distinct objects, cairo must internally lock
access when modifying them.
Each glyph in the scaled font is represented by a cairo_surface_t
which is used when rendering the glyph. Instead of attempting to push
fine-grained locking of these surfaces down to the backend rendering
functions, a simple per-cairo_scaled_font_t lock has been introduced
which protects the entire rendering path against re-entrancy.
Some care was required to ensure that existing re-entrancy was handled
appropriately; these cases are in the wrapping surfaces
(cairo-paginated, test-meta and test-paginated).
Thanks to Vladimir Vukicev and Peter Weilbacher for testing/providing
the mutex definitions for win32 and os2 (respectively).
Previously, with the magic in _cairo_scaled_font_reference(),
cairo_scaled_font_create() was releasing its lock just before
calling into reference() which would re-acquire the lock.
That left a window open during which a font we just discovered
in the holdovers table could be destroyed before we had a chance
to give it its initial reference back.
As in the previous commit with the backend->scaled_font_create
function, we also don't want to hold the lock when calling into
the backend's fini function.
Calling cairo_surface_finish from cairo_surface_destroy was
triggering an error due to finish being called twice. The
error was usually hidden as the surface would still eventually
be destroyed. But it did clutter things up quite badly if a
user was trying to break on _cairo_error to track down a
problem.
Thanks again to Stuart Parmenter <stuartp@gmail.com>
for pointing out the problem.
Current code for subsetting CFF fonts does not write charset information
into it. According to spec this means that font have ISOAdobe charset.
This charset contains only 228 names (excluding .notdef). This is not
enough for subfonts with 256 glyphs and causes bugs when viewing
generated PDFs.
Rotation and other transformations would cause extents to be
computed which were outside the bounds of the surface to be
cloned, (and for non repeating patterns). Now we simply
restrict the computed extents to the surface extents.
This fixes the xlib failure of the recent rotate-image-surface-paint
test, (the apparently distinct ps failure remains).
This test exercises a clone_similar extents bug noticed by
Benjamin Otte. As expected, the xlib backend fails due to
that bug, (and interestingly, the ps backend is showing a
failure as well).
PDF backend sets /LastChar value in Type1C font dictionary incorrectly.
acroread then complains about incorrect /Widths in font.
The last char is numchars - 1, since it's zero-based.
The atsui font backend returned the internal 'unsupported' error
code for errors in operations that do not have fallbacks. Now that
the underlying cause, deleted glyphs, has been fixed, I'm changing
the status code returned to the public 'no memory' one; it should
be the only condition triggering the failure now.
If PKG_CHECK_MODULES fails, it does not print out any check results and so, no
newlines. This is kinda silly, at least in the case that no second branch is
provided, but I think that's the way it is, to let users decide what to print.
We now just do a AC_MSG_RESULT(no) and continue with what we used to do.
Inspired by Tor Lillqvist's similar change in Pango.
The warning happens all the place when the code converts from ullong to __m64.
The way the conversion is done is a C idiom: 1) get a pointer to the value, 2)
convert it to the suitable pointer type for the target, 3) dereference it.
That is "*(__m64*)(&m)" in this case. This is necessarily (as opposed to just
casting to target type) because the two types may not be "compatible" from the
compiler's point of view. Example of types that are not compatbile is structs
vs anything.
The "dereferencing type-punned pointer will break strict-aliasing rules" from
gcc exactly means: "some code may be assuming that pointers with different
types do not compare equal (or otherwise share the same target object). If
you case a pointer to a different type and dereference it, it may happen
here." However, in our usecase, it's clear that the compiler cannot make any
false assumptions. So we just go ahead and hide it by using a middle cast to
"void *". Since the compiler does not many any aliasing assumptions about
generic pointers, it will not warn either. (Though the problems if any, will
still occure. So this is not an ideal solution to this problem and should be
used very carefully, to no hide useful warnings for when things go loose on
some weird architecture.)
Another solution would have been to use gcc's "may_alias" function attribute,
but trying to define a may_alias version of __m64 hit a bug in gcc. That is,
try replacing "__m64" with "m64" and define:
typedef __m64 m64 __attribute__((may_alias));
and see it fail to compile. This seems to be because of the special vector
type that __m64 has.
The former workaround for the lack of non-repeating patterns in PDF
(as far as we can tell) was broken for a source pattern matrix that
resulted in scaling the source surface pattern down. This was
demonstrated by the failure of the scale-down-source-surface-paint
test which now passes.
The old code would have also allowed for bogus repeated pattern
instances to appear if the source surface pattern was translated
sufficiently far off the destination surface in just the right
direction. This bug is also fixed.
