This was recently broken in commit 40d5082c24
which uses a base85-stream but without strings for encapsulating image
data. The bug was that the protection for ~> was only being applied
to the string encodings rather than all base85 streams.
We got lucky recently that the 24.8 change just happened to put the ~>
sequence on the line-wrap boundary so the test suite tripped up the
bug. Otherwise, we could have missed this for quite some time.
The additional 8 bits of integer allows device space to be 256
times larger before applications need to start worrying about
any issues with overflow. So this should help in many cases.
And the loss of 8 bits of sub-pixel precision shouldn't cause
any harm at all---16 was really much more than necessary.
With this change the details of rasterization for several tests
are changed slightly, (particularly on arcs, for example), so
many reference images are updated here.
NOTE: This change is currently breaking get-path-extents for
ps/pdf/svg as well as push-group for ps. We do not yet know
the reasons for these new failures.
The rectangle_int16_t usage was causing failures on 24.8 (due to a wrong
pointer used to get_extents); I removed all the specific int16/int32 typedefs
to avoid this situation in the future.
Propagate the true status value back from the _cairo_gstate_init_copy()
instead of assuming that is a NO_MEMORY and re-raising the error in the
caller.
I was wrong in my assertion that the call to
_cairo_path_fixed_interpret_flat() could not possibly fail with the
given _cairo_path_bounder_* callbacks - as I had missed the implicit
spline decomposition. (An interesting exercise would be to avoid the
spline allocation...) As a result we do have to check and propagate the
status return through the call stack.
Modify cairo-pdf-operators.c to emit to 're' path operator when the
path contains only a rectangle. This can only be done when the path is
logically equivilent to the the path drawn by the 're'
operator. Otherwise dashed strokes may start on the wrong line.
ie the path must be equivalent to:
cairo_move_to (cr, x, y);
cairo_rel_line_to (cr, width, 0);
cairo_rel_line_to (cr, 0, height);
cairo_rel_line_to (cr, -width, 0);
cairo_close_path (cr);
which is also equivilent to cairo_rectangle().
The surface size and clip needs to be saved before and restored after
replaying meta surface patterns back to the analysis surface. The clip
is reset and the correct surface size is set before replaying the meta
surface.
The FT_Set_Char_Size() docs say it replaces sizes smaller than 1.0 with 1.0.
So, we can't use x_scale and y_scale values less than one. The fix is easy thouh,
cap them to 1.0 and let the FT transform do the scaling down.
For A8 and A1 masks, the embedded mask image doesn't have an alpha channel.
In this case, the feColorMatrix should not be used, since it's goal is to
discard the color channels and to only keep the alpha one (which is what
we want when we have an ARGB32 mask image, since SVG uses all the channels
for the mask operation, where cairo only use the alpha channel).
SVG doesn't support extend reflect for image pattern, and there isn't
any trivial way to emulate this feature. So we use the image fallback
for now. This fix also forces an image fallback for extend-reflect, but
in the end, it generates more or less the same file (one big image for
the pattern). No other test is forced to use an image fallback by this
patch.
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.
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.
