- each annotation was emitted on every page instead of just the page
that contains the annotation
- the document structure did not correctly link to annotation objects
- fix some annotation related memory leaks
The PS output from this test is > 100MB due to the duplicated images.
Using CAIRO_MIME_TYPE_UNIQUE_ID reduces the PS output to 650k, runs
considerably faster, and now produces correct output.
When image data is emitted as strings (required when an image is used
in a PaintProc), the base85 encoded data was emitted inside PS strings
(...) and the image filters included an ASCI85Decode filter.
This has been changed to emit the strings as ASCII85 strings <~...~>
and remove the ASCII85Decode filter since the base85 is decoded when
the string is parsed.
Also factor out the string data source procedure into the prolog.
- Restructure the emit_surface code so that mime types are checked first.
- Add a test parameter to emit_surface to test if the surface will be emitted
as an image or recording instead checking the surface type as the attached
mime may override this.
- Mark surface as not clear when mime is attached to avoid optimizing away
"clear" surfaces that have mime attached.
- Include entire surface in analysis if mime attached (also fixes bug with
calculating the extents CONTENT_COLOR surfaces)
PDF XObjects need to specify the bounding box. Emit unbounded surfaces
when finishing as at this point the extents of all uses of the
unbounded surface are known.
Image data is often accessed using:
image->data + y * image->stride
On 64-bit achitectures if the image data is > 4GB, this computation
will overflow since both y and stride are 32-bit types.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=98165
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
The cairo_set_opacity() routine has been disabled since 2010. There
appears to be support for it internally in the backend, so it is unclear
why it is not enabled or what might break if it were re-enabled. Given
the lack of bug reports about its omission, it may be vestigal. For
now, just hide the doxygen for it to suppress warnings. It may be worth
deeper review to either re-enable it or remove it entirely.
Reported-by: Rafał Mużyło (See fdo bugzilla #82741)
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
Check via the AC_C_TYPEOF macro if GCC's typeof is available. If it is
available via a different spelling, define typeof to that spelling.
Patch from and issue reported by Richard Palo.
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=93027
This happens when _cairo_ft_scaled_glyph_init() returns
CAIRO_INT_STATUS_UNSUPPORTED when called from
_cairo_scaled_glyph_lookup(). In those cases
_cairo_scaled_font_free_last_glyph() is called to release the glyph that
has just been allocated. If there aren't more glyphs,
_cairo_scaled_glyph_page_destroy() is called. The problem is that
_cairo_scaled_glyph_lookup() should always be called with the cache
frozen, and _cairo_scaled_glyph_page_destroy() without the cache
frozen. We can simply thaw/freeze the font before calling
_cairo_scaled_glyph_page_destroy().
https://bugs.freedesktop.org/show_bug.cgi?id=103335
Previously it was assumed the mime image size is the same as the cairo
image surface size. When using the 1 bpp formats (CCITT, JBIG2),
creating a cairo image of the same size will have very large memory
requirements and in some case may exceed the pixman image size
limits. In these cases it is useful to allow the mime image to have a
different resolution to the cairo image and in the PDF/PS output scale
the mime image to be the same physical size as the cairo image.
In PDF, this is easy as all PDF images are scaled to 1x1 unit and the
CTM is used to scale the image to the required size. The PS surface
has been changed to also scale images to 1x1 and use the CTM to get
the required size.
This completes the full set of PDF/PS image filters allowing image
data to be passed though without decompressing then recompresssing in
a less efficient format.
The difficulty with CCITT_FAX is it needs some decoding parameters
that are not stored inside the image data. This is achieved by using
an additional mime type CCITT_FAX_PARAMS that contains the params in
key=value format.
Fixes the race condition when one thread uses cairo_mask_compositor_t
pointer returned by _cairo_image_mask_compositor_get, while another one
started but has not finished it's initialisation yet
Usage:
static cairo_atomic_once_t once = CAIRO_ATOMIC_ONCE_INIT;
if (_cairo_atomic_init_once_enter(&once)) {
/* Initialization code */
_cairo_atomic_init_once_leave(&once);
}
https://bugs.freedesktop.org/show_bug.cgi?id=103037
The combination of both curved strokes and ignoring the ctm in the thin
line check caused some fill-strokes in this test case to be culled.
Modify the thin line check to take the ctm into account and increase
the minimum width to 1 point to prevent curved lines such as tiny dots
from being culled.
https://bugs.freedesktop.org/show_bug.cgi?id=103071
- move num_glyphs_in_face to base struct as it is the number in the font
- move num_glyphs to the subset variables as it is the num glyphs in the subset
- move widths to subset variables as it uses the subset id as the array index
Subset array sizes are allocated based on the number of glyphs in the
font. In this bug the fonts did not contain the mandatory .notdef
glyph, hence the subset arrays were not large enough.
https://bugs.freedesktop.org/show_bug.cgi?id=102922
