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.
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)
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()).
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.
Cut'n'paste from commit c1f765:
Without these checks, a user could hit an assertion failure by passing
a finished surface to cairo_surface_write_to_png_stream. Now we return
a nice CAIRO_STATUS_SURFACE_FINISHED error in that case instead.
It is possible for _cairo_hull_prev_valid to be called just once
right before the calling loop is going to terminate. In this
case we really don't want to walk off the beginning of the
array and start wandering.
Thanks to Jonathan Watt for noticing this problem:
https://bugzilla.mozilla.org/show_bug.cgi?id=306649#c21
Without these checks, a user could hit an assertion failure
by passing a finished surface to cairo_surface_write_to_png.
Now we return a nice CAIRO_STATUS_SURFACE_FINISHED error in
that case instead.
As identified by Vladimir Vukicevic,
_cairo_xlib_surface_create_similar_with_format() was erroneously passing
down the source Visual when creating a surface with a different
XRenderPictFormat.
If the xserver doesn't support the RENDER extension or simply doesn't
have the matching PictFormat then xrender_format might be NULL. Check
and fallback in this case.
This reverts commit 731e121c80.
This commit introduced various problems, (some likely noticeable
in the test suite, and others perhaps not). For some details, see
the latest comments in the original bug report leading to the
fix now being reverted:
http://bugs.freedesktop.org/show_bug.cgi?id=15349
In tests such as smask-mask (and others) the cairo_mask operation
is used in the construction of a mask. In this case, the single
document->mask_id value was being incremented at inappropriate
times.
We fix this by adding a new _cairo_svg_document_allocate_mask_id
that returns the current value and increments it. That way,
callers can hold onto this reliable value for the desired lifetime
that the code needs the identifier.
The smask-fill test was failing for PDF output because in some places
where the surface size is changed (eg when emitting patterns or
smasks) the cairo_to_pdf matrix was not updated.
Fix this by adding a function to handle the surface size change and
replace all the duplicated code for changing surface size with a call
to this function.
Right now the two filters are implemented identically, so there's
no real change for now. But in the future, it's conceivable that an
X server could implement some crazy, high-quality filter for BEST
without regard to performance, (since that's what BEST means).
Meanwhile, GOOD actually captures what we want by default which is
a good mix of both quality and performance.
If the .notdef glyph is the first glyph in the subset to be mapped in
scaled font, we do not know if the subset will scaled or unscaled. We
can put it in the unscaled subset as Type1-fallback will embded an
empty glyph if it can not get the path.
Bug 15348 references the following PDF that was printing incorrectly
when running through poppler and cairo to generate PostScript.
http://launchpadlibrarian.net/12921700/UbuntuDesktop.pdf
The PostScript output had too much space between each word causing
strings of glyphs printed with the TJ operator to overlap.
The original PDF file contains an CFF font with CID Identity-H
encoding. The PDF file is using character code 0 (glyph 0 due to
Identity-H encoding) as a space character. The CFF specification
defines glyph 0 to be the .notdef glyph.
The PS backend subsets CFF fonts as a Type1-fallback
font. Type1-fallback creates it's own empty .notdef glyph with an
arbitrary glyph advance of 500. The problem here is the TJ operator
used to output the glyphs depends on the glyph advance being
correct. pdf-operators.c uses the glyph advance returned by
_scaled_glyph_init(). However the PostScript interpreter sees the
glyph advance of 500 for .notdef. This problem does not occur when
generating PDF as the PDF font dictionary contains an list of glyph
advances that override the font metrics.
Fix this by making Type1-fallback not treat .notdef as special and to
create it the path and metrics obtained from _scaled_glyph_init(). As
a special case, make it not fail if _scaled_glyph_init() is unable to
return a path for .notdef. This was probably the reason Type1-fallback
previously created it's own .notdef glyph as calling
_scaled_glyph_init(_GLYPH_INFO_PATH) for glyph 0 returns
CAIRO_INT_STATUS_UNSUPPORTED for some fonts.
This ensures the Type1-fallback font metrics match the metrics used
by pdf-operators.c to position the glyphs. This also results in the
removal of some duplicated code.
5050c55f93 fixed type1-fallback to use the glyph advance instead of
glyph width in the stored glyph metrics in the font. However it did
not fix the same bug in Type 2 charstrings (used by CFF fallback in
PDF). This problem was not noticed since the glyph widths in the PDF
font dictionary overrides these values.
Fix this in case any software reading cairo PDFs uses these values.
If _cairo_scaled_glyph_lookup() returns CAIRO_INT_STATUS_UNSUPPORTED
it will be caught by the ASSERT_NOT_REACHED in
_emit_unscaled_font_subset in PS/PDF. It is more useful to catch this
closer to the source.
This fixes the filter-bilinear-extents test case and the
related bug entry:
bad clipping with EXTEND_NONE
http://bugs.freedesktop.org/show_bug.cgi?id=15349
Though there are still differences in the PDF and PostScript
backends, (primarily because we can't capture cairo's filter
modes in those file formats).
This covers the known-to-broken 1.3 servers such as appeared
in Fedora 8. It also leaves the workaround off, (since it's
a severe slowdown), for the known-to-be-working 1.4.99.901
server as appears in Fedora 9 Betas.
XRenderAddGlyph() does not split its image data across multiple requests
and so the glyph surface must be smaller than XMaxRequestSize or else
the server will disconnect the client, causing "Fatal IO error 104".
As this will require an extension to the XRender spec, we can work
around the issue by using our fallbacks if we detect that the glyph will
be too large for a single request.
See bugs https://bugs.freedesktop.org/show_bug.cgi?id=4339 and
http://bugs.freedesktop.org/show_bug.cgi?id=13266 for examples.
