We do not want to enforce the gtk-doc markup in the preformated
examples, so run the files through sed to filter out <programlisting>
before checking with the error detecting regexp.
Extend the documentation for cairo_ft_font_face_create_for_ft_face() to
demonstrate using cairo_font_face_set_user_data() to destroy the FT_Face
after the final reference to the cairo_font_face_t has been dropped.
The font_face created from cairo_ft_font_face_create_for_ft_face()
was being kept alive by a reference from the context beyond the
lifetime of the parent cairo_scaled_font_t (which owned the FT_Face).
Correct the example in the test code to remove this errant reference
before cleaning up the fonts. (To be fair, to actually trigger a bug
one has to evict the FT_Face from the cache before using the font_face
- merely creating a cairo_scaled_font_t for every font on the system is
enough.)
cairo_ft_scaled_font_lock_face() and friends are unused internally
(instead _cairo_ft_unscaled_font_lock_face() is used directly), so
remove the unnecessary aliases.
After specifying how to transform the various colour modes into ones we
can handle, re-read the image header to confirm that the output on
reading the PNG will be RGB24 or ARGB32. This simplifies our logic
considerably as we no longer have to second guess the colour space
transformation that will be performed by libpng. (And allows for some
paranoid checks.)
Check that when loading from index/gray/rgb PNGs, with and without
alpha/transparency, that the correct surface is generated by read_png(),
i.e. if the PNG contains an alpha channel then the image must be an
ARGB32 surface.
jeremie54 reported a regression in the handling of transparent paletted
PNGs beween 1.4.14 and 1.6.4. This was caused by the change to load
opaque PNGs into a RGB24 image surface, which made the assumption that
indexed PNGs were opaque. However, alpha/transparency in PNG is more
complicated, as PNG uses a tRNS chunk to supply transparency data for
paletted images and other image types that don't need a full alpha
channel. Therefore if the PNG contains a tRNS chunk always generate an
ARGB32 surface.
When replaying the meta-surface to the target, we apply a stack-based
clip to the surface. However, we did not remove this clip from the
surface and so a pointer into our stack existed beyond the scope of
function.
Saving the original clip pointer and restoring it before leaving the
function resolves the issue and appears to fix
https://bugzilla.mozilla.org/show_bug.cgi?id=429071.
The postscript backends depends upon cairo-pdf-operators.c, so list it
as a requirement in ps_sources. This enables the postscript backend to
build even if the pdf backend is disable by the user during configure.
(Fixes http://bugs.freedesktop.org/show_bug.cgi?id=15532.)
This gets us a fix for not linking with g++ from 1.6.4
We don't take from 1.6.4 the revert of the addition of
missing locking from the GC cache, (meanwhile, we've
already got a corrected fix for this).
Conflicts:
src/cairo-xlib-screen.c
ExtTextOut() does not work with Type 1 font glyph indices when
printing. The same code works fine when dst->dc is a display. It
appears that ExtTextOut expects unicode character values when using
Type 1 fonts and a printer DC.
Fix this by making Type 1 fonts in the win32-printing surface use the
fallback path for non Windows fonts. ie the glyphs will be emitted as
filled paths.
If you think this commit is reminiscent of
40558cb15e, you would be right as it fixes
exactly the same bug I made then and reintroduced in dc714106e1.
So quoting 40558cb:
After consuming the GC we need to unset the clip reset flag, so that
if we try and get a new GC without first putting a fresh one we do not
try to call XSetClipMask on a NULL GC.
This bug first was fixed in 40558cb15e,
but then reintroduced in 9cfd82e87b, which
became part of the 1.6.2 quick release.
As penance to make sure I never repeat this same bug again, I offer this
test case which exercises the XSetClipMask(NULL) path and hopefully
simulates some 'typical' usage of cairo by GUI toolkits.
The beos backend involves a source file written in C++.
Apparently, automake sees the conditional inclusion of
that source file and insists on doing the final link of
cairo with g++ even though that file isn't being compiled
at all.
We definitely don't want that as it makes libcairo link
and depend on libstdc++ unnecessarily, (which can break
distribution packaging when not expecting it, etc.).
This reverts commit 9cfd82e87b.
The fix was broken as it introduced crashes by calling
XSetClipMask with a NULL GC, (basically a reintroduction
of the bug originally fixed here:
7802de6d5edaf998c98b141870dc2c6b4c0f3e91
Let's revert for sake of the release, and fix this correctly
on master.
The Td and Tm operator emulation were setting the font matrix like this:
/some_font [xx yx xy yy x0 y0] selectfont
where [xx yx xy yy] is the font matrix and [x0 y0] is the position of
the first glyph to be drawn. This seemed to be the easiest way to
emulate the Tm operator since the six arguments to Tm required by PDF
are xx,yx,xy,yy,x0,y0.
Before the switch to pdf-operators the font matrix was set like this:
/somefont [xx yx xy yy 0 0] selectfont x0 y0 moveto
The selectfont operator is equivalent to calling findfont, makefont,
and setfont. The makefont operator creates a new font dictionary for
specified font that contains the specified font matrix. The
description of the makefont operator in the PostScript Language
Reference Manual states:
"The interpreter keeps track of font dictionaries recently created
by makefont. Calling makefont multiple times with the same font and
matrix will usually return the same font rather than create a new
one."
So the emulation of Tm and Td was creating a new font dictionary every
time a text string was displayed due to the change in the translation
components of the font matrix. Previously the font dictionary was
re-used as with the translation components of the matrix set to zero,
the font matrix did not change frequently.
Some printers did not handle well the frequent creation a font
dictionary every time a few glyphs were displayed.
Fix this by ensuring the translation components of the font matrix
used in the emulation of Tm and Td operators is always set to
zero. Use moveto instead for the translation components.
(cherry picked from commit c5814d2aa3)
Convert the boilerplate specific flattened content value to the ordinary
CAIRO_CONTENT_COLOR_ALPHA for use with cairo_push_group_with_content() -
otherwise cairo rightfully flags an error and the test harness decides
that the similar surface is not available.
Within the library, we know the precise size of the struct and so can
allocate temporary font options on the stack - eliminating the need
to export an internal alias of cairo_font_options_(create|destory).
We depend on values stored on the context that become invalid upon an
error, so stop processing as soon as an error occurs. Prior to
adjusting, the values returned from the error context, this would cause
an infinite loop whilst calculating the number of segments required for
a tolerance of 0.
Return the default values instead of zero for an error context. This
helps to prevent application logic faults when using the values from
the error context (for an example, see _cairo_arc_in_direction()).
