summaryrefslogtreecommitdiff
path: root/BUGS
diff options
context:
space:
mode:
authorCarl Worth <cworth@cworth.org>2005-08-06 17:00:59 +0000
committerCarl Worth <cworth@cworth.org>2005-08-06 17:00:59 +0000
commit31ef9a80e95c5b84439b5d668d11ab3480d22a22 (patch)
treefb39d12b39ac91e020b3c4f36e1f814730370f0a /BUGS
parent1fadb8065600d5b9cbab9a14232e08daec450e4d (diff)
Remove several bugs that have been fixed.
Diffstat (limited to 'BUGS')
-rw-r--r--BUGS53
1 files changed, 0 insertions, 53 deletions
diff --git a/BUGS b/BUGS
index 1a0c3b09..43331d08 100644
--- a/BUGS
+++ b/BUGS
@@ -10,16 +10,6 @@ cairo_image_surface_create should return a blank image
--
-Scaling of surface patterns is all broken, (try xsvg
-gradPatt-pattern-BE-07.svg and zoom in and out).
-
---
-
-centi_unfinished.svg has big black portions when drawn with svg2png,
-(but not when drawn with xsvg).
-
---
-
The caches need to be invalidated at font destruction time.
--
@@ -67,24 +57,6 @@ confirmed on a quite default install of debian unstable.
--
-cairo_scale_font modifies objects that the user expects to not change. For example:
-
- cairo_font_t *font;
-
- cairo_select_font (cr, "fixed", 0, 0);
- font = cairo_current_font (cr);
- cairo_scale_font (cr, 10);
- cairo_show_text (cr, "all is good");
- cairo_set_font (cr, font);
- cairo_scale_font (cr, 10);
- cairo_show_text (cr, "WAY TOO BIG!!);
-
-We could fix this by not storing the scale in the font object. Or
-maybe we could just force the size to its default after set_font. Need
-to think about this in more detail.
-
---
-
cairo_show_text is not updating the current point by the string's advance values.
--
@@ -99,34 +71,9 @@ places.
--
-Patterns are broken in various ways. The SVG test case demonstrates
-some regressions, so something has changed in cairo. Also,
-transformation plus repeat doesn't work in either Xrender or
-libpixman, (nor in glitz?).
-
---
-
font-size="0" in an SVG file does very bad things.
--
-move_to_show_surface (see cairo/test):
-
- * 2004-10-25 Carl Worth <cworth@cworth.org>
- *
- * It looks like cairo_show_surface has no effect if it follows a
- * call to cairo_move_to to any coordinate other than 0,0. A little
- * bit of poking around suggests this isn't a regression, (at least
- * not since the last pixman snapshot).
-
---
-
cairo falls over with XFree86 4.2 (probably braindead depth handling
somewhere).
-
---
-
-The caches abort when asked for a too-large item, (should be possible
-to trigger by asking for a giant font, "cairo_scale_font (cr, 2000)"
-perhaps). Even if the caches don't want to hold them, we need to be
-able to allocate these objects.