Inital commit of Native Quartz surface. The main missing functionality
is mask() support (which is just a noop right now, except for the simple
solid-alpha case).
Add support for the win32 surface using DDBs for similar surfaces and the
like when the orignal surface is created from a DC, or when a DDB is
explicitly created. A DIB is still created if alpha is required.
Also fixes a case where blitting win32 RGB24 -> ARGB32 surfaces was causing
alpha to leak into the ARGB32 surface instead of being set to fully opaque.
cairo_status_t is a signed type, so we need to check for invalid codes
that are < 0 as well.
Also removes the MSVC goop in path-data.c that was attempting to work
around the assert earlier.
There was a bad mix of LIBCMT (the static runtime lib) and MSVCRT (the dynamic
one) before, because LIBCMT is the default. This specifies /MD everywhere.
This patch adds a bunch of makefiles for building cairo with Visual C++.
gnu make is still required, and make must be run from a command prompt
that has the Visual C++ paths set up, as well as has the cygwin environment
in the path. Run 'make -f Makefile.win32'.
This adds a win32 initialization function that is called from all
surface creation and font creation functions to ensure that the win32
mutexes are initialized.
These functions were previously returning a status value that
was almost never being checked. Instead we now make these
functions void and enforce a usage pattern that the destination
array must be pre-grown to accomodate the results. This is
verified with a couple of assert statements.
The pre-allocation was already happening with all but one call.
That call is now also fixed up.
This object doesn't act like a status-holding object, (there are no
"if (status) return;" inertness-enforcing statements for example),
so it shouldn't pretend like it is.
This is a little simpler than the old idiom of calling
_cairo_output_stream_get_status just before calling
_cairo_output_stream_destroy.
I had hoped this technique would apply in more cases, but
many cases want to separate the two actions anyway to do
conditional assignment of the status value, (in order to
not overwrite an earlier error value).
This doesn't actually fix the AMD64 link failure, but it does make the
foo/EXT_foo/INT_foo symbol names generated by the slim_hidden_proto()
and slim_hidden_def() macros consistent in the face of the meddling of
pixman-remap.h.
Signed-off-by: Nicholas Miell <nmiell@gmail.com>
src/check-def.sh checks that the list of symbols exported is the same as the
list of symbols in cairo.def, ie. symbols in public header files. (except for
symbols starting with _cairo)
src/check-plt.sh checks that no PLT entries exist for local function calls.
This makes sure we keep the 'slim' annotations uptodate.
These two are defined as tests in src/ and will be run during "make distcheck".
However, they are skipped if the commands 'nm' and 'readelf' are not found.
(We don't really rely on any functionality of eu-readelf, so using readelf
proper which should be more commonlly installed.)
This patch generates Type 1 fonts for the PS/PDF backends when TrueType
or Type 1 subsetting fails. This has the advantage over the current
Type 3 fallback of reduced font size and better quality rendering
in some PDF viewers. xpdf shows a large improvement in text display
quality with this patch.
PDF Files with Type 1 fonts fail to open in any version of
ghostscript prior to 8.54. The problem is the hex encoding of the
encrypted portion of the font. The PDF reference says this should
only be in binary.
Basically, it's evil to write a loop like:
while ((c -= 4) > 0) {
...
}
for one reason that doesn't work if c is unsigned. And when c is signed, if
for some reason c is about -MAXINT, then it will overflow and not work as
expected.
It's much safer (and more gcc warning friendly) to rewrite it as:
unsigned int c;
while (c >= 4) {
...
c -= 4;
}
Behdad chased this bug down when looking into bug #7593. This
bug is what finally motivated us to figure out how to get -Wextra
(for the "always true" comparisons of unsigned variables against
negative values).
The documentation for GetGlyphOutline() states that outline returned is grid
fitted and if an application requires an unmodified outline it can request an
outline for a font whose size is equal to the font's em unit.
This seems to suggest that the solution to this bug would be to obtain the
unmodified outline data and scale it to the required size.
https://bugs.freedesktop.org/show_bug.cgi?id=7603
The setting of current point to (0,0) is actually harmless, but it
definitely looks like a bug, (since after close_path the current point
is really the last move point).
We don't keep track of last move point here, nor do we even need to.
So we can be consistent with _cairo_path_fixed_close_path by not
adjusting current point at all, (the subsequent move_to coming right
behind the close_path will fix up the current point).
Besides the bug fix, this is a user-visible change since the new
move_to element after the close_path element can be seen in the
results of cairo_copy_path, so we document that here.
We are also careful to fix up _cairo_path_fixed_line_to to defer to
_cairo_path_fixed_move_to to avoid letting the last_move_point state
get stale. This avoids introducing the second bug that is also tested
by the close-path test case.
