And update user-font text_to_glyphs() method to match.
Currently disable the win32-font text_to_glyphs(), until that one
is updated. Or better yet, remove it and implement ucs4_to_index().
It's the toy font API afterall.
The init func does not actually need to draw anything, but having a cairo_t
similar to that passed to render_glyph is handy for computing font extents.
This is because cairo makes doing some things really hard (if not impossible)
without a cairo_t.
The user-font-proxy test case is a great example of how the added cairo_t
makes life much easier.
The PDF output no longer requires a PDF specific reference image. The
lastest poppler from git is required to get the fix for a bug in Type
3 font rendering.
This way the same callback code can be used to render multiple different
glyph arrays. Change done for education purposes, otherwise doesn't
make any difference in the test.
10000 that is. xlib fails now again. Not because of glyph size issues.
Because we skip rendering any glyphs with positions not in range -1024..15359.
Working on a fix.
test/invalid-matrix purposely feeds invalid numbers into cairo, in
order to check its detection of garbage values. In doing so, cairo
raises an Invalid exception, but as this is a direct result of an abuse
of the API we can treat it as expected behaviour and ignore the
exception.
Some platforms and applications enable floating point exceptions, so it
seems sensible to run the test-suite with the most serious exceptions
enabled - divide by zero, invalid result and overflow.
Franz Schmid reported on the mailing list,
http://lists.cairographics.org/archives/cairo/2008-April/013912.html,
an issue with drawing a dashed rubber band in Scribus. The problem
appears when segments of the dashed rectangle are outside the image,
with the errant dash connecting the ends of the visible segments.
The font_face created from cairo_ft_font_face_create_for_ft_face()
was being kept alive by a reference from the context beyond the
lifetime of the parent cairo_scaled_font_t (which owned the FT_Face).
Correct the example in the test code to remove this errant reference
before cleaning up the fonts. (To be fair, to actually trigger a bug
one has to evict the FT_Face from the cache before using the font_face
- merely creating a cairo_scaled_font_t for every font on the system is
enough.)
Check that when loading from index/gray/rgb PNGs, with and without
alpha/transparency, that the correct surface is generated by read_png(),
i.e. if the PNG contains an alpha channel then the image must be an
ARGB32 surface.
This bug first was fixed in 40558cb15e,
but then reintroduced in 9cfd82e87b, which
became part of the 1.6.2 quick release.
As penance to make sure I never repeat this same bug again, I offer this
test case which exercises the XSetClipMask(NULL) path and hopefully
simulates some 'typical' usage of cairo by GUI toolkits.
Convert the boilerplate specific flattened content value to the ordinary
CAIRO_CONTENT_COLOR_ALPHA for use with cairo_push_group_with_content() -
otherwise cairo rightfully flags an error and the test harness decides
that the similar surface is not available.
