Previously, using the ps or pdf backend with a bitmapped font would
result in a coorupt output file, filled with uninitialized values and
missing procedures for drawing the glyphs.
Now, the file should actually be valid, but it's simply drawing black
boxes instead of the correct glyphs.
This allows graceful recovery when first requesting a path from a font
that only supports bitmapped glyph. The changed return type is also
pushed down into the scaled_glyph_init function of the
cairo_scaled_font backend.
The aliases should allow binaries with the old symbols to continue to run.
Meanwhile, the macros in cairo.h prevent any code from being compiled without
using the new, future-proof function names.
This is a temporary, transition strategy and the aliases will be dropped
before the next major release.
Most internal cairo types are transparent within cairo and have init and fini
functions to intialize and finialize them in place. This way they can be
easily be embedded in other structs or derived from. Initially, the
cairo_output_stream_t type was proposed as a publically visible type and
thus kept opaque. However, now it's only used internally and derived from
in a number of places so let's make it an embeddable type for consistency
and ease of use.
The patch keeps _cairo_output_stream_create() and _cairo_output_stream_close()
around for (internal) backwards compatibility by deriving a
cairo_output_stream_with_closure_t stream type.
The patch also moves all cairo_output_stream_t functions out of cairoint.h
and into new file cairo-output-stream-private.h, thus chipping away at the
monolithic cairoint.h.
When the glyph format does not match the font format, the glyph will
be rendered incorrectly. Setting the {x, y}_offset correctly when
converting glyph format fix that.
For doing so, I've changed document owner to be the paginated surface,
instead of the svg surface like previously. That's because fallback
resolution is stored in paginated surface.
With previous commit, freetype font backend is able to transform
both bitmap and outline glyphs, so ignores FC_MATRIX from now,
cairo doesn't need this for artificial oblique. And cairo doesn't
use FC_MATRIX direct anyway, it has its own font matrix that may be not
equal to FC_MATRIX in the font pattern! You should pass the matrix
(usually the matrix is multiplied by font's pixel size) to cairo when
creating scaled font.
This function is used to shape bitmap glyphs(outline glyphs are
transformed by freetype). That means freetype backend is able to
tranform both bitmap & outline glyphs now. This is needed for glyph
rotating, artificial oblique etc.
The old behavior of returning "infinite" extents is inconsistent with
the current usage of meta-surface where it is always created for
replay against a particular (sized) target surface and that size is
passed to _cairo_meta_surface_create.
Also clarify documentation of _cairo_surface_get_extents to eliminate
the possibility of inifinite extents.
(This is covering up my mistake from the last batch of 12 commits which
wasn't ready to be pushed yet. This fixes some of the crashes which
were introduced, and is a good thing to do regardless.)
The trick is to create a new scaled_font with the device_transform
multiplied into the CTM within _cairo_surface_show_glyphs before
calling into the backend. The fallback-resolution test shows that
the font size is now correct.
The trick is to simply multiply the device_transform into the CTM
within _cairo_surface_stroke before passing the CTM down to the
backend. The fallback-resolution test shows that the stroke width is
now correct.
Add new, private _cairo_surface_set_device_scale for getting at the
scaling components of device_transform. Use this in paginated surface
when replaying to an image surface. The fallback-resolution test now
clearly shows that image fallback resolution can be controlled by the
user. Hurrah!
This is a step toward allowing device scaling in addition to device offsets.
So far, the scale values are still always 1.0 so only the translation is
actually being used. But most of the code is in place for doing scaling as
well and it just needs to be hooked up.
There are some fragile parts in this code, all of which involve using the
translation without the scale, (so grep for device_transform.x0 or
device_transform->x0). Some of these are likely bugs that will hopefully
be obvious once we start using the scale. Others are OK if only because
we 'know' that we aren't ever setting device scaling on a surface that
has a device offset (we only set device scaling on surfaces we create
internally and we don't export device scaling to the user).
All of these fragile parts in the code have been marked with comments of
the form: XXX: FRAGILE.
This just provides the mechanics for storing the value and removing the old
function calls. The new value is still not used anywhere (though nor where
the old values), so there should be no functional change (other than forcing
any programs calling the old API to be updated).
Global advance exists for historical reasons. Nowadays, most of fonts
support unicode, means it's no guaranteed to every glyphs in the font
has the same advance.Sometimes it maybe is biger/smaller then the global
advance even for monospace fonts!So forcing their advance to global
advance, it's obviously wrong.
A recent renaming from CAIRO_MAXSHORT also changed the range of some
values from INT16_MAX to UINT16_MAX. The test suite shows one case
where this introduces a bug, (push/pop_group with SVG and RGB24
surfaces).
I haven't tracked the bug down, (presumably there's overflow of the
unsigned value at some point), but I'm now reverting this to avoid
triggering the bug.
This rectangle has regular integer values, not fixed-point values.
So the old name was horribly wrong and misleading, (and yes I think
it was even I that had suggested it).
