To avoid any possibility of uninitialized memory.
The exceptions are:
- where the allocation is immediately overwritten by a memcpy or struct copy.
- arrays of structs to avoid any performance impact (except when the
array is returned by the public API).
This implements Type 3 color fonts for PDF for any font with a
CAIRO_SCALED_GLYPH_INFO_RECORDING_SURFACE. This includes user-fonts,
SVG fonts, and COLR fonts.
Glyphs with foreground colors are not yet implemented as Type 3 glyphs
and will be rendered as images by cairo-surface.
In _cairo_type3_glyph_surface_create(), we call
_cairo_surface_clipper_init(), but nothing ever called
_cairo_surface_clipper_reset() in this call. This commit adds that
missing call.
This fixes a leak of a clip.
Since I have no clue about this code (does _cairo_pdf_operators_fini()
possible use the clipper?), I did the patch like this. This should avoid
any possibility for a use-after-free.
Fixes: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=51043
Signed-off-by: Uli Schlachter <psychon@znc.in>
COLR fonts can have a layer with the same color as the current text
color. This change passes the current color (if solid) through to
the font backend where it can be used to render color fonts.
scaled_glyph_lookup checks if the foreground color has changed (for
glyph that require it) and requests a new color surface if required.
This also fixes a bug where scaled_glyph_lookup would always request a
color surface for glyphs for glyphs in color fonts that do not have
color.
_cairo_malloc(0) always returns NULL, but has not been used
consistently. This patch replaces many calls to malloc() with
_cairo_malloc().
Fixes: fdo# 101547
CVE: CVE-2017-9814 Heap buffer overflow at cairo-truetype-subset.c:1299
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
When an unbounded recording surface is used multiple times with
different extents for each operation we need the XObject containing
the recording surface to have the same origin for each operation. This
is not possible when the recording surface is converted to PDF
coordinates because each operation has different extents resulting in
a different origin when the Y-axis is flipped (since the flip matrix
depends on the recording surface height which for unbounded surfaces
depends on the extents of the operation that paints the recording
surface).
Switching to cairo coordinates by emitting a Y-axis flip matrix as the
first object of each page allows the recording surface to be emitted
in cairo coordinates. This results in the same origin for all
operations using the recording surface XObject.
since the PS Document Structing Conventions impose a 255 character
line limit. PDF does not require wrapping.
pdf-operators is designed to emit the same output for PS and PDF.
Unfortunately some PDF interpreters don't like strings split with
'\\\n' and some PS interpreters don't like strings split with ')('.
So we are forced to make pdf-operators handling string wrapping
differently for PDF and PS.
Bug 85662
Having spent the last dev cycle looking at how we could specialize the
compositors for various backends, we once again look for the
commonalities in order to reduce the duplication. In part this is
motivated by the idea that spans is a good interface for both the
existent GL backend and pixman, and so they deserve a dedicated
compositor. xcb/xlib target an identical rendering system and so they
should be using the same compositor, and it should be possible to run
that same compositor locally against pixman to generate reference tests.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
P.S. This brings massive upheaval (read breakage) I've tried delaying in
order to fix as many things as possible but now this one patch does far,
far, far too much. Apologies in advance for breaking your favourite
backend, but trust me in that the end result will be much better. :)
A common requirement is the fast upload of pixel data. In order to
allocate the most appropriate image buffer, we need knowledge of the
destination. The most obvious example is that we could use a
shared-memory region for the image to avoid the transfer cost of
uploading the pixels to the X server. Similarly, gl, win32, quartz...
The other side of the equation is that for manual modification of a
remote surface, it would be more efficient if we can create a similar
image to reduce the transfer costs. This strategy is already followed
for the destination fallbacks and this merely exposes the same
capability for the application fallbacks.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Step 1, fix the failings sighted recently by tracking clip-boxes as an
explicit property of the clipping and of composition.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Allow a backend to completely reimplement the Cairo API as it wants. The
goal is to pass operations to the native backends such as Quartz,
Direct2D, Qt, Skia, OpenVG with no overhead. And to permit complete
logging contexts, and whatever else the imagination holds. Perhaps to
experiment with double-paths?
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
I updated the Free Software Foundation address using the following script.
for i in $(git grep Temple | cut -d: -f1 )
do
sed -e 's/59 Temple Place[, -]* Suite 330, Boston, MA *02111-1307[, ]* USA/51 Franklin Street, Suite 500, Boston, MA 02110-1335, USA/' -i "$i"
done
Fixes http://bugs.freedesktop.org/show_bug.cgi?id=21356
Split into a general cairo_image_surface_coerce() that coerces to one of
the 3 supported formats (ARGB32, RGB24, A8) based on content and the
more general cairo_image_surface_coerce_to_format() that coerces to a
specified format.
The PDF file referenced by bug 26186 contains a Type 3 font with non
identity font matrix and a "1/2" glyph created by drawing the "1" and
"2" from a Type 1 font. This combination exposed a bug in the font
scale and glyph position in _cairo_type3_glyph_surface_show_glyphs
when printing user font glyphs.
The device is a generic method for accessing the underlying interface
with the native graphics subsystem, typically the X connection or
perhaps the GL context. By exposing a cairo_device_t on a surface and
its various methods we enable finer control over interoperability with
external interactions of the device by applications. The use case in
mind is, for example, a multi-threaded gstreamer which needs to serialise
its own direct access to the device along with Cairo's across many
threads.
Secondly, the cairo_device_t is a unifying API for the mismash of
backend specific methods for controlling creation of surfaces with
explicit devices and a convenient hook for debugging and introspection.
The principal components of the API are the memory management of:
cairo_device_reference(),
cairo_device_finish() and
cairo_device_destroy();
along with a pair of routines for serialising interaction:
cairo_device_acquire() and
cairo_device_release()
and a method to flush any outstanding accesses:
cairo_device_flush().
The device for a particular surface may be retrieved using:
cairo_surface_get_device().
The device returned is owned by the surface.
As a simple step to ensure that we do not inadvertently modify (or at least
generate compiler warns if we try) user data, mark the incoming style
and matrices as constant.
Replaying a meta surface can be achieved by using it as a source for a
cairo_paint() so exporting a separate API is unnecesary and confusing.
So after consulting Chris and Carl, we decided to remove the function
again.
Handling clip as part of the surface state, as opposed to being part of
the operation state, is cumbersome and a hindrance to providing true proxy
surface support. For example, the clip must be copied from the surface
onto the fallback image, but this was forgotten causing undue hassle in
each backend. Another example is the contortion the meta surface
endures to ensure the clip is correctly recorded. By contrast passing the
clip along with the operation is quite simple and enables us to write
generic handlers for providing surface wrappers. (And in the future, we
should be able to write more esoteric wrappers, e.g. automatic 2x FSAA,
trivially.)
In brief, instead of the surface automatically applying the clip before
calling the backend, the backend can call into a generic helper to apply
clipping. For raster surfaces, clip regions are handled automatically as
part of the composite interface. For vector surfaces, a clip helper is
introduced to replay and callback into an intersect_clip_path() function
as necessary.
Whilst this is not primarily a performance related change (the change
should just move the computation of the clip from the moment it is applied
by the user to the moment it is required by the backend), it is important
to track any potential regression:
ppc:
Speedups
========
image-rgba evolution-20090607-0 1026085.22 0.18% -> 672972.07 0.77%: 1.52x speedup
▌
image-rgba evolution-20090618-0 680579.98 0.12% -> 573237.66 0.16%: 1.19x speedup
▎
image-rgba swfdec-fill-rate-4xaa-0 460296.92 0.36% -> 407464.63 0.42%: 1.13x speedup
▏
image-rgba swfdec-fill-rate-2xaa-0 128431.95 0.47% -> 115051.86 0.42%: 1.12x speedup
▏
Slowdowns
=========
image-rgba firefox-periodic-table-0 56837.61 0.78% -> 66055.17 3.20%: 1.09x slowdown
▏
The meta-surface is a vital tool to record a trace of drawing commands
in-memory. As such it is used throughout cairo.
The value of such a surface is immediately obvious and should be
applicable for many applications. The first such case is by
cairo-test-trace which wants to record the entire graph of drawing commands
that affect a surface in the event of a failure.
Be careful not to pass an error object down to emit_image() hook,
propagate the error instead. This relieves the burden of the error check
from the callee -- which was causing an assertion failure in the ps
backend.
When coercing from one image format to another we performed a paint
operation using a temporary context - this is overkill as we can just call
_cairo_surface_paint() directly.
A surface will have the chance to use span rendering at cairo_fill()
time by creating a renderer for a specific combination of
pattern/dst/op before the path is scan converted. The protocol is to
first call check_span_renderer() to see if the surface wants to render
with spans and then later call create_span_renderer() to create the
renderer for real once the extents of the path are known.
No backends have an implementation yet.
Add a "cairo_rectangle_int_t *extents" argument to to the following
backend functions:
paint
mask,
stroke
fill
show_glyphs
show_text_glyphs
This will be used to pass the extents of each operation computed by
the analysis surface to the backend. This is required for implementing
EXTEND_PAD.
Only copy the pattern if we need to modify it, e.g. preserve a copy in a
snapshot or a soft-mask, or to modify the matrix. Otherwise we can
continue to use the original pattern and mark it as const in order to
generate compiler warnings if we do attempt to write to it.
After discussing the scaled font locking with Behdad, it transpired that it
is not sufficient for a font to be locked for the lifetime of a scaled glyph,
but that the scaled font's glyph cache must be frozen for the glyph'
lifetime. If the cache is not frozen, then there is a possibility that the
glyph may be evicted before the reference goes out of scope i.e. the glyph
becomes invalid whilst we are trying to use it.
Since the freezing of the cache is the stronger barrier, we remove the
locking/unlocking of the mutex from the backends and instead move the
mutex acquisition into the freeze/thaw routines. Then update the rule on
acquiring glyphs to enforce that the cache is frozen and review the usage
of freeze/thaw by all the backends to ensure that the cache is frozen for
the lifetime of the glyph.
Images in PDF are scaled to a unit square. In PS we set the
ImageMatrix to do the same. When the image is painted we scale the
graphics state to paint the image at the right size. In the case of
Type 3 fonts consisting of bitmap images we want to paint the images
at their original size so we scale the graphics state by the image
width and height.
The bug was that we were scaling by the width/height in the glyph
metrics. For non rotated fonts this worked. However for rotated fonts
the width/height of the glyph images may be larger than the
width/height in the glyph metrics. This resulted in a Type 3 font
where the glyph images were scaled slightly smaller than they should
have been.
This function emits the glyph to a null stream with the side effect
that other glyphs referenced by this user-font glyph will be added to
the font subsets.
Quick summary of changes:
- Move list of cairo source files out of src/Makefile.am and into
src/Sources.mk,
- Generate files src/Config.mk and src/Config.mk.win32 that choose
the right set of source files and headers based on configured
backends and features. This drastically simplifies building
using other build systems. The src/Makefile.win32 file needs
to be updated to reflect these changes.
- Add README files to various directories,
- Add toplevel HACKING file.
show_glyphs inside a Type 3 font currently results in a fallback
image. Some refactoring is required before font subsets can be created
while emitting all the font subsets.
