We have tested the case of device transforms that have both translate and
scale. So it basically works. We just are not sure that we handle it in
all places (In fact we know we don't.)
For every glyph evicted from the cache we would allocate a very small
structure to push onto the xlib work queue. This quickly becomes
noticably for an app that consumes a lot of scaled fonts and glyphs,
e.g. trying to draw text at various angles. So we maintain a small array
of glyphs pending finalisation and issue the XRenderFreeGlyphs() once the
array is full.
During the destruction of every font used with an xlib surface, we send
an XRenderFreeGlyphs() for every single glyph in the cache. These
requests are redundant as the server-side glyphs will be released along
with the XRenderFreeGlyphSet(), so we skip the individual glyph
destruction if the font is marked as finished.
XRender performs a round-trip in order to query the available formats on
the xserver, before searching for a matching format. In order to save
that round-trip and to avoid the short-lived allocation of the array of
available formats, we cache the result on the display.
The current solid surface cache returns an existing similar surface only
if it is an exact match for the desired colour. This gives a high hit
rate for the original goal of drawing text, but fails when using a lot
of colours - for example drawing a pie-chart, the mosaic perf case, or
browsing the web. So instead of creating a new surface from scratch we
can repaint an existing one, providing that we have sufficient surfaces
already cached, i.e. if we are going to evict a surface, we may as well
just repaint it.
Use cairo_win32_scaled_font_select_font() instead of
_cairo_win32_scaled_font_select_unscaled_font() to select the font.
Because _cairo_win32_scaled_font_select_unscaled_font() displays a
warning when used with a bitmap font.
The glyph width caculation was not compensating for the
WIN32_FONT_LOGICAL_SCALE resulting in a glyph width and glyph advance
32 times larger than it should be.
158d24412b fixed win32 printing of bitmap fonts by forcing the use
of fallback images. This exposed a bug in the win32 bitmap font
metrics when a device scale is used that resulted in clipped glyphs.
The win32 printing surface has the same problem with bitmap fonts as
it does with Type 1 fonts. ie ExtTextOutW() with glyph indices works
for a display DC but not a printer DC.
Fix this by forcing fallback for bitmap fonts.
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.
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.)
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.
