The loop was unnecessarily written in a way that fails
to terminate if len is 0 (ie for the empty string).
Avoid that by checking for len > 0 explicitly.
When a color glyph is completely clipped away, we
get the non-zero status 'nothing to do'. In that case,
we must not exit early, since there might still be work
to do for the other color glyphs.
This bug was showing up as color glyphs stopping to render
in GTK+ entries that are scrolled to the right, and also
as color glyphs not rendering inside the selection sometimes.
See https://bugzilla.gnome.org/show_bug.cgi?id=790255 and
https://bugzilla.gnome.org/show_bug.cgi?id=788071.
Commit 38fbe621 added use of the ptrdiff_t type in a header file,
however `make distcheck` complains:
In file included from headers-standalone-tmp.c:1:0:
../../../src/cairo-image-surface-private.h:74:5: error: unknown type name ‘ptrdiff_t’
ptrdiff_t stride;
^
Add a cairo_svg_surface_set_document_unit() function to allow users to
set a unit for the width and height values of the root <svg> element.
In particular this allows to draw in pixels and still have the expected
result when generating SVG output.
Add also the correspondent getter function.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=90166
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
Until now fopen was used on Windows to open files for reading and
writing. This assumed however that the filename would be encoded in the
current codepage, which is a major inconvenience and makes it even
impossible to use filenames that use characters from more than one
codepage. This patch enforces the use of UTF-8 filenames on all
platforms.
Based on the work of Owen Taylor (https://lists.cairographics.org/archives/cairo/2007-February/009591.html)
- 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.
