I was wrong in the previous message where I said I had ghostscript 8.61
installed. I do now, (and "gs --version" says the same thing), and
here are the new reference images.
Presumably these are due to ghostscript version churn. I don't
know what version was used in the past, but we're going to be
more careful about documenting versions now.
The ghostscript package I used here advertises itself as "8.61"
and "gs --version" reports 8.15.3.
This one doesn't have any associated poppler bug report. The
rendering by poppler is totally reasonable, and not problematic
at all with respect to what the test is actually testing for.
This is justified by the following new bug report:
Poppler should paint images with CAIRO_EXTEND_PAD
https://bugs.freedesktop.org/show_bug.cgi?id=14578
The four affected tests are:
paint-source-alpha
paint-with-alpha
rotate-image-surface-paint
scale-source-surface-paint
We had several pdf tests disabled waiting for this bug fix:
Poppler does not correctly handle knockout groups
https://bugs.freedesktop.org/show_bug.cgi?id=12185
That's in place for poppler now, so we're turning the tests
back on. Some of the affected tests now pass perfectly:
over-above-source
over-around-source
over-below-source
over-between-source
Some just needed new reference images:
operator-clear
clip-operator-pdf-argb32
The remaining tests still fail, but none of the failures can
obviously be ascribed to just poppler problems:
clip-operator-pdf-rgb24
operator-source
unbounded-operator
The first two have some serious problems, while in the case
of unbounded-operator the problem is extremely minor (a white
grid appears in the background where the reference image is
all black).
This avoids unnecessary rasterization in many cases when using
cairo_surface_create_similar with an SVG surface. Because of that
it eliminates test-suite failures for the -similar cases where we
have svg-specific reference images. Namely:
font-matrix-translation, ft-text-vertical-layout-type1,
ft-text-vertical-layout-type3, mask, meta-surface-pattern,
paint-source-alpha, paint-with-alpha, rotate-image-surface-paint,
scale-source-surface-paint, source-clip-scale, text-pattern,
text-rotate
In all of these cases the test suite was kindly noticing that we
weren't getting the same 'native' SVG output that was desired.
This prepares for analyze_operation to be able to return more than
just two values, (which will allow the svg backend to take advantage
of CAIRO_INT_STATUS_FLATTEN_TRANSPARENCY).
This reverts commit 7f21bfb0a8.
We don't yet have consensus on whether this is a good change or not.
So for now, we're favoring the existing behavior until we can work
that out.
This was triggering an infinite loop (with 24.8 fixed-point) just before
the previous fix.
NOTE: I usually put bug demonstrations just before the fixes, but this
one was quite harsh---not only was cairo looping infinitely, but it
was appending to an array on each iteration---so not kind at all.
Sometimes > rather than >= can make a bug difference. The infinite loop
was noticed here:
Infinite loop when scaling very small values using 24.8
http://bugs.freedesktop.org/show_bug.cgi?id=14280
Note that that particular test case only exposes the infinite
loop when using 24.8 instead of 16.16 fixed-point values by
setting CAIRO_FIXED_FRAC_BITS to 8.
These two functions were hiding away some important details
about strictness of inequalities. Also, the callers differ
on the strictness they need. Everything is cleaner and more
flexible by making the callers just call _cairo_slope_compare
directly.
This was an initial attempt to fix the infinite loop bug
described here:
Infinite loop when scaling very small values using 24.8
http://bugs.freedesktop.org/show_bug.cgi?id=14280
This doesn't actually fix that bug, but having a more robust
comparison function can only be a good thing.
Remember to destroy the sub_font if we fail to reserve the .notdef glyph
during construction.
Whilst in the vicinity, adjust the function prototype to remove
duplicated calls to _cairo_error().
The PDF backend has always used "\r\n" for the newline character.
There was no particular reason for this choice. PDF allows "\n", "\r",
or "\r\n" as the end of line marker.
Since the PS backend (which uses "\n") has started sharing
cairo-pdf-operators.c with the PDF backend, the PS output has been
getting mixed "\n" and "\r\n" newlines.
Fix this by changing the PDF backend to use "\n".
The optimization to avoid sqrt() for horizontal/vertical lines in
_compute_normalized_device_slope was causing us to return a negative
magnitude with a positive slope for left-to-right and bottom-to-top
lines, instead of always returning a positive magnitude and a slope
with an appropriate sign.
Minor correction for a build failure on AIX:
"mozilla/gfx/cairo/cairo/src/cairo-gstate.c", line 45.43: 1506-294 (S)
Syntax error in expression on #if directive.
(Fixes https://bugzilla.mozilla.org/show_bug.cgi?id=415867.)
In order to correctly report the error back to the user during the
creation of a scaled font, we need to support a nil object per error.
Instead of statically allocating all possible errors, lazily allocate
the nil object the first time we need to report a particular error.
This fixes the misreporting of an INVALID_MATRIX or NULL_POINTER that
are common user errors during the construction of a scaled font.
Partial revert of commit 0086db893c.
This is a follow to the earlier commit that allowed creation of scaled
fonts using a NULL font options (by interpreting the NULL as meaning
use the default options) to reflect the comments made by Behdad
(http://lists.cairographics.org/archives/cairo/2008-January/012714.html).
The intent is that the public font options getter/setter API has similar
defensive behaviour to that of the core objects - i.e. do not overwrite
the nil object and if the object is in error then return the default
value. For the indirect use of a NULL/nil font options (e.g. creation of
scaled fonts), then an error should be returned rather than crashing.
