Support subpixel positioning with a 4x4 subpixel grid.
When compositing glyphs in the image compositor,
we store the subpixel phases in the high bits of the
glyph index. The _cairo_scaled_glyph_index() macro
has been updated to discard these bits. By storing
the phases in the glyph index, the glyph cache just
keeps working. When loading a glyph, the Freetype
font backend shifts the outline according to the
phases.
FT_PIXEL_MODE_BGRA is an enum member, not a define, so it always appears
as 0 in the preprocessor conditions added in commit c0ed8ce1a1.
There is an existing define for color font support, use that instead.
Since commit a34cb719cd, we need pixman >= 0.36, which is not yet
in the latest Fedora. Thus, this switches to Fedora rawhide to make
things work again.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Found via `codespell -i 3 -w -I ../cairo-word-whitelist.txt -L tim,ned,uint`
Follow up of 12cb59be7d
Reviewed-by: Bryce Harrington <bryce@bryceharrington.org>
The indentation of this line suggests it is a typo. In any case it
causes the function to unconditionally return immediately, thereby
shortcircuiting it entirely, which does not appear to be the intended
behavior.
Fixes: https://gitlab.com/cairo/cairo/issues/2
Similar to writing png, don't squash 16 bpc to 8 bpc and create
a float surface to contain the image.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Bryce Harrington <bryce@bryceharrington.org>
_cairo_image_surface_coerce will round down the image to a lower
bpp when using one of the floating point formats, so don't coerce those.
This makes the code actually work for those formats.
Because a float takes more storage than u16, we have to convert float
to u16 before calling png_write_image, because png_write
doesn't give us back the original row data, but an in-place copy.
With these changes we can dump floating point files with the highest
possible accuracy, with floats clamped between 0 and 1.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Bryce Harrington <bryce@bryceharrington.org>
IGT wants to add support for planes with a bit depth >10, which
requires a higher precision format than we have currently.
I'm using RGBA as format, because of its existence in OpenGL.
With the new formats we can directly convert our bytes to half float,
or multiply a colro vector with a matrix to go to the Y'CbCr colorspace.
This requires pixman 0.36.0, so bump the version requirement.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Bryce Harrington <bryce@bryceharrington.org>
All the cases are the same, except len is different.
Use the already calculated len parameter to handle all
cases except RGB24 the same.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Suggested-by: Bryce Harrington <bryce@bryceharrington.org>
Reviewed-by: Bryce Harrington <bryce@bryceharrington.org>
The code that looked at CAIRO_TEST_NUM_THREADS was removed seven years
ago in commit 6ef9779a6f, because it was dead code. I have not
managed to figure out how long exactly this code was dead already.
This commit removes the last traces of NUM_THREADS.
Signed-off-by: Uli Schlachter <psychon@znc.in>
With VERBOSE=1, a lot more stuff is printed while make runs. Perhaps
most interestingly, this prints the output of a failed test after the
test failed. Thus, this gives us the output of the test suite.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Converting a series of glyphs to a path triggers an out of memory error
if there is a space glyph (bytesGlyph==0). The regression was
introduced by commit 19982393 in cairo-win32-font.c:107.
The behavior of malloc(0) is not well defined - it can return NULL on
some platforms, or an arbitrary (non-allocated) pointer on other
platforms. Commit 19982393 introduced sanity by enforcing that NULL is
always returned in this situation, which inappropriately triggers the
OOM check in _cairo_win32_scaled_font_init_glyph_path(). Instead,
special case the handling for bytesGlyph==0.
Patch authored by Uli Schlachter, based on fix proposed by lb90.
Fixes: https://gitlab.freedesktop.org/cairo/cairo/issues/339
Reference: https://gitlab.gnome.org/GNOME/pango/issues/323
Reviewed-by: Bryce Harrington <bryce@bryceharrington.org>
Run the command below suggested by geirha in ##sed@irc.freenode.net.
git grep -l 'http://.*gnome.org' | xargs sed -i 's|http\(://\([[:alnum:].-]*\.\)\{0,1\}gnome\.org\)|https\1|g'
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Run the command below suggested by geirha in ##sed@irc.freenode.net.
git grep -l 'http://.*freedesktop.org' | xargs sed -i 's|http\(://\([[:alnum:].-]*\.\)\{0,1\}freedesktop\.org\)|https\1|g'
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Run the command below suggested by geirha in ##sed@irc.freenode.net.
git grep -l 'http://.*cairographics.org' | xargs sed -i 's|http\(://\([[:alnum:].-]*\.\)\{0,1\}cairographics\.org\)|https\1|g'
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
From further testing and investigation it appears that many PDF viewers
already have a workaround to invert Adobe CMYK JPEGs, so our generated
PDFs display incorrectly with those viewers due to double-inversion.
Further investigation will be needed to find a better solution that
doesn't cause regression for some PDF viewers; perhaps PDF viewers that
lack this inversion workaround should be changed to include it. For now
we'll drop the patch to avoid shipping the regression in 1.16.0.
This reverts commit b207a932a2.
Reference: https://bugs.freedesktop.org/show_bug.cgi?id=97612
Fixes: https://gitlab.freedesktop.org/cairo/cairo/issues/156
Fix distcheck by dropping use of the now-obsolete gtkdoc-mktmpl.
In preparation for the upcoming 1.16 release, I've made a few changes to
get distcheck to pass. I also updated it to run on Ubuntu 18.04, but
found that on newer distros distcheck won't run due to missing
gtkdoc-mktmpl, which has been deprecated upstream for some time. The
patch below disables everything that references it, and enables
distcheck to finish successfully.
Unfortunately, this probably regresses portions of our document
generation, and thus will need some reimplementation work. Anyone got
time to investigate a better solution for this?
For me, with this fix, the base image test cases now pass 100%, when
running:
make test TARGETS=image FORMAT=rgba
Signed-off-by: Bryce Harrington <bryce@bryceharrington.org>
The discrepancies in these tests appear to all be font rendering /
antialiasing, probably due to algorithmic changes in Pixman.
Some of these reference images were updated in Federico's recent patch,
so the fact that they differ on my system may indicate there may be some
system dependencies beyond just pixman, that can cause test result
variation from person to person. Ideally, these would be isolated and
the tests modified to not have such dependencies.
Signed-off-by: Bryce Harrington <bryce@bryceharrington.org>
