To avoid these warnings:
configure.in:29: error: possibly undefined macro: LT_CURRENT
If this token and others are legitimate, please use
m4_pattern_allow.
See the Autoconf documentation.
configure.in:33: error: possibly undefined macro: LT_REVISION
configure.in:38: error: possibly undefined macro: LT_AGE
we simply use an m4_define for those variables instead.
Franz Schmid reported on the mailing list,
http://lists.cairographics.org/archives/cairo/2008-April/013912.html,
an issue with drawing a dashed rubber band in Scribus. The problem
appears when segments of the dashed rectangle are outside the image,
with the errant dash connecting the ends of the visible segments.
The beos backend involves a source file written in C++.
Apparently, automake sees the conditional inclusion of
that source file and insists on doing the final link of
cairo with g++ even though that file isn't being compiled
at all.
We definitely don't want that as it makes libcairo link
and depend on libstdc++ unnecessarily, (which can break
distribution packaging when not expecting it, etc.).
This reverts commit 9cfd82e87b.
The fix was broken as it introduced crashes by calling
XSetClipMask with a NULL GC, (basically a reintroduction
of the bug originally fixed here:
7802de6d5edaf998c98b141870dc2c6b4c0f3e91
Let's revert for sake of the release, and fix this correctly
on master.
The Td and Tm operator emulation were setting the font matrix like this:
/some_font [xx yx xy yy x0 y0] selectfont
where [xx yx xy yy] is the font matrix and [x0 y0] is the position of
the first glyph to be drawn. This seemed to be the easiest way to
emulate the Tm operator since the six arguments to Tm required by PDF
are xx,yx,xy,yy,x0,y0.
Before the switch to pdf-operators the font matrix was set like this:
/somefont [xx yx xy yy 0 0] selectfont x0 y0 moveto
The selectfont operator is equivalent to calling findfont, makefont,
and setfont. The makefont operator creates a new font dictionary for
specified font that contains the specified font matrix. The
description of the makefont operator in the PostScript Language
Reference Manual states:
"The interpreter keeps track of font dictionaries recently created
by makefont. Calling makefont multiple times with the same font and
matrix will usually return the same font rather than create a new
one."
So the emulation of Tm and Td was creating a new font dictionary every
time a text string was displayed due to the change in the translation
components of the font matrix. Previously the font dictionary was
re-used as with the translation components of the matrix set to zero,
the font matrix did not change frequently.
Some printers did not handle well the frequent creation a font
dictionary every time a few glyphs were displayed.
Fix this by ensuring the translation components of the font matrix
used in the emulation of Tm and Td operators is always set to
zero. Use moveto instead for the translation components.
(cherry picked from commit c5814d2aa3)
It is possible for _cairo_hull_prev_valid to be called just once
right before the calling loop is going to terminate. In this
case we really don't want to walk off the beginning of the
array and start wandering.
Thanks to Jonathan Watt for noticing this problem:
https://bugzilla.mozilla.org/show_bug.cgi?id=306649#c21
This reverts commit 07122e64fa.
The extra testing did find a pdf bug, and that should be fixed,
but the extra maintenance burden of running another iteration
of all tests does not seem justfied at all---particularly since
it looks like dozens of new reference images would be needed
for the svg backend.
Also, the new "failures" of the image backend with this new
testing look like a misunderstanding of exactly what the new
testing is actually drawing.
Without these checks, a user could hit an assertion failure
by passing a finished surface to cairo_surface_write_to_png.
Now we return a nice CAIRO_STATUS_SURFACE_FINISHED error in
that case instead.
As identified by Vladimir Vukicevic,
_cairo_xlib_surface_create_similar_with_format() was erroneously passing
down the source Visual when creating a surface with a different
XRenderPictFormat.
If the xserver doesn't support the RENDER extension or simply doesn't
have the matching PictFormat then xrender_format might be NULL. Check
and fallback in this case.
Test surfaces using similar surfaces with both CONTENT_COLOR and
CONTENT_COLOR_ALPHA, if applicable. This seems justified by the apparent
bugs in the pdf backend when going from an ARGB32 similar surface to
a destination RGB24 surface as well as isolated bugs in the image
backend.
The original goal was to try and trick the test suite into producing
a xlib surface with mismatching Visual/XRenderPictFormat. This succeeds,
although with a little bit of brute force in the xlib backend, but the
search to reproduce a BadMatch error fruitless.
I don't know if we made minor changes to the pdf backend, or
if this was due to a poppler change, (we recently bumped the
poppler required for testing up to 0.8.0), but any way around
it these test results look just as good as the reference images
they are replacing.
This test case does show a bug, and we have lots of ideas on how
to fix the bug, but we want to wait until after the 1.6 release
before we fix it. See:
http://bugs.freedesktop.org/show_bug.cgi?id=15349
This reverts commit 731e121c80.
This commit introduced various problems, (some likely noticeable
in the test suite, and others perhaps not). For some details, see
the latest comments in the original bug report leading to the
fix now being reverted:
http://bugs.freedesktop.org/show_bug.cgi?id=15349
In tests such as smask-mask (and others) the cairo_mask operation
is used in the construction of a mask. In this case, the single
document->mask_id value was being incremented at inappropriate
times.
We fix this by adding a new _cairo_svg_document_allocate_mask_id
that returns the current value and increments it. That way,
callers can hold onto this reliable value for the desired lifetime
that the code needs the identifier.
The smask-fill test was failing for PDF output because in some places
where the surface size is changed (eg when emitting patterns or
smasks) the cairo_to_pdf matrix was not updated.
Fix this by adding a function to handle the surface size change and
replace all the duplicated code for changing surface size with a call
to this function.
